Оптимизированный доступ к памяти.

TermoSINteZ
Чем отличается запись упакованных\неупакованных и вещественных\невещественных? ^)

 

Потестил на коре и не обнаружил прироста в записи, ни в movntpd ни в movntq. Причём результаты очень противоречивые, лидирующие функции меняются от запуска к запуску с разбросом в 20%-30%. И что-то у меня сильно не дотягивает память до её теоретической пропускной способности. 50mb - (60msec - 80msec), при чтении в два раза выше. 1Гб как-то совсем не вяжется с теоретическими 10гб. Тестил и VTune-ом и собственным замером.

 

При чтении не выше, а быстрее. ^)

 

Че-то не правильно делаешь, учи матчасть - в частности замечание, т.к. это при обычной записи скорость более чем вдвое ниже скорости чтения, а при movntq д.б. по крайней мере не ниже

 

leo
Я в курсе, что должно быть наоборот. Но что поделать, если такой резалт. Я по-началу подумал может VTune шалит, но и мой замер показал те же результаты. И скорость жесть какая низкая.

 

leo
Вот например http://www.ixbt.com/mainboard/core2-fsb-ddr2-ddr3.shtml
Или они не знают что нужно писать movntq?

 

Не знаю я, что такое "реальная скорость записи в память" в RMMA - эта глюковина у меня на атлоне ваще запускаться не хочет

Посему, вот те для справочки мои резалты:
1) на "слабеньком" Core2 2600MHz/800MHz/2Gb + DDR2 800MHz

Код (Text):

1. CPU GenuineIntel @ 2610 MHz
2. ---------------------------
3. Test mode   Read only
4. Method      Size / Speed
5.         16,0 Mb
6.  
7. mov (4*bytes):  2310 Mb/sec
8. mov (4*words):  3738 Mb/sec
9. mov (4*dwords): 4544 Mb/sec
10. movsd:      -----------
11. mmx (8*qwords): 5013 Mb/sec
12. mmx (8*movntq): -----------
13.  
14. ---------------------------
15. Test mode   Write only
16. Method      Size / Speed
17.         16,0 Mb
18.  
19. mov (4*bytes):  1474 Mb/sec
20. mov (4*words):  1511 Mb/sec
21. mov (4*dwords): 1469 Mb/sec
22. movsd:      2273 Mb/sec
23. mmx (8*qwords): 1463 Mb/sec
24. mmx (8*movntq): 4147 Mb/sec

2) на еще более "слабеньком" Athlon 64 X2 4600 2400MHz/--/2*512Kb DDR2 800MHz

Код (Text):

1. CPU AuthenticAMD @ 2397 MHz
2. ---------------------------
3. Test mode   Read only
4. Method      Size / Speed
5.         16,0 Mb
6.  
7. mov (4*bytes):  2411 Mb/sec
8. mov (4*words):  2544 Mb/sec
9. mov (4*dwords): 3248 Mb/sec
10. movsd:      -----------
11. mmx (8*qwords): 3130 Mb/sec
12. mmx (8*movntq): -----------
13.  
14. ---------------------------
15. Test mode   Write only
16. Method      Size / Speed
17.         16,0 Mb
18.  
19. mov (4*bytes):  1475 Mb/sec
20. mov (4*words):  1614 Mb/sec
21. mov (4*dwords): 1773 Mb/sec
22. movsd:      1769 Mb/sec
23. mmx (8*qwords): 1908 Mb/sec
24. mmx (8*movntq): 5281 Mb/sec

Как видно у каждого свои причуды в абсолютных цифрах - кора читает через movq процентов на 20 быстрее, чем пишет через movntq, а из Атлона никак не удается выжать более половины проп.способности при чтении, хотя запись через movntq дает более 80% от теретического максимума (6.4Gb/sec).
Но относительные тенденции одинаковые:
1) обычная запись сущ-но отстает от чтения,
2) запись через movntq более чем в 2.5 раза быстрее обычной записи

 

Ну да, точно - под "реальной записью" подразумевается обычная, не nt-запись. Запустил RMMA на Core2 и получил примерно то же соотношение, что и в статье. Но если ставишь опцию Non-temporal store = enabled, то скорость записи лишь на те же процентов 20 ниже скорости чтения

 

leo
Не подскажешь небольшую тулзу для теста памяти под Vista 64? Rmma под ней не запускается. Запустил PC Wizard, эта прога выдала что результаты тестов на этой ОС будут не существенны. ^)

И выдала:
С префетчем:
Bandwidth (Чтение Float - Prefetch) : 1557.59 Mb/s
Bandwidth (Запись Float - Prefetch) : 855.56 Mb/s
Bandwidth (Чтение Int. - Prefetch) : 1384.01 Mb/s
Bandwidth (Запись Int. - Prefetch) : 870.34 Mb/s
Latency : 257 ns (208 cycles)

Без:
Bandwidth (Чтение Float) : 1818.39 Mb/s
Bandwidth (Запись Float) : 1755.15 Mb/s
Bandwidth (Чтение Int.) : 1928.18 Mb/s
Bandwidth (Запись Int.) : 740.94 Mb/s
Latency : 256 ns (207 cycles)


Хз. что за прога, как она мерит, что подразумевается под float, как она читает без префетча и что значит - "Результаты тестов будут не действительны". Но в каком-то смысле этот тест с подтверждает мой. Не понимаю почему такая низкая пропускная способность, это с теоретической то пропускной способностью 10Гб/сек.

У меня на P4 с DDR400 в тесте RMMA так:
Чтение - 2000 mb/sec.
Запись - 1500 mb/sec.
Запись movntq - 2500 mb/sec.

P4 c DDR1 400Mhz уделывает кору с DDR3 1333Mhz. Резалты очень странные.

Ещё потестирую movntq на коре, чтобы уж точно удостовериться в том о чём я писал ранее.

 

Интересно, что это за циклы с частотой ~800МГц ?

 

Ну я и ламерюга. Прошу не кидаться тухлыми помидорами, но повод есть. Тестил я вначале примерно таким образом:

Код (Text):

1. char *p1 = (char*)malloc(count);
2. TestWrite(p1, count);
3. char *p2 = (char*)malloc(count);
4. TestWrite2(p2, count);

И получал не корректные тесты.

А сейчас сделал так:

Код (Text):

1. char *p1 = (char*)malloc(count);
2. memset(p1, 0, count);
3. TestWrite(p1, count);
4. TestWrite2(p1, count);

У Криса конечно написано, что выделение страниц по требованию очень тормозная операция, но я не придал этому значения. ^)

Теперь резалты на 50mb блоке:
Чтение:
byte = 48 ms.
dword = 22 ms.
movq = 20 ms.
movapd = 17 ms.

Запись:
byte = 51 ms.
dword = 45 ms.
movq = 45 ms.
movntq = 22 ms.
movntpd = 19 ms.

И чтение запись по 2500 mb/sec. Однако всё равно маловато будет.

leo

Почему 800? По-моему 4 мгц, латентность.
Ещё мне интересно как они сделали чтение без префетча? И имеет ли смысл на современных процах инструкция prefetchnta? Как понимаю это нужно только на процах которые не делают сами аппаратный префетч, по-этому пишем её чтобы была.
И кстати запись быстрее чтения на P4, это нормально?

 

Крутилась у меня эта мыслЯ, что возможно ты страницы не инициализируешь...
И кстати memset для инициализации это лишняя трата времени, лучше пробежаться в цикле и прочитать по одному char-у из каждой 4К страницы

Не понятно чем ты ms измеряешь - QueryPerformanceXXX ?
И задаешь ли реал-тайм приоритет процессу и потоку, т.к. время измерения явно превышает квант потока и соотв-но он может прерываться виндой. Да и sleep(0) перед тестом не помешает

Потому, что 257 ns = 208 cycles, откуда частота = 208/257 ГГц

Имеет в спец.случаях при непоследовательном доступе (всякие там матрицы и т.п.)

Для movnt нормально. В принципе в разных архитектурах могут быть отклонения как в одну так и в другую сторону - все это специфика реализации WC-буферов и чтения данных в кэш. Например, в NetBurst данные всегда читаются из памяти сначала в L2 и затем в L1, а в атлонах всегда сразу в L1 и т.п.

 

Точно.

Понятно, заранее префетчим следующий блок памяти, работаем с текущим уже загруженным. А какие матрицы имеются ввиду?

timeGetTime.

Это да. Но вроде ничего особенного тут нет, скорее всего просто так получилось из параметров памяти и других узлов.

Что-то мне не верится что это сильно изменит ситуацию. Разброс есть, но не значительный - 2ms-3ms максимум.

Что интересно на P4 нету такого разброса значений при неинициализированных страницах,
movntq стабильно была впереди на 60%-70%. На коре же полнейший разброд, от запуска к запуску результаты менялись кaрдинально.

По-идее на такой коре и памяти как у меня, практическая пропускная способность должна быть не ниже 6Гб/ceк. Именно так в статье на ixbt.

 

Угу, так я и предполагал - небось выставил timeBeginPeriod(1), не думая о том, что это влияет на всю систему в т.ч. и на частоту переключения потоков

Юзай QueryPerformanceXXX - они специально предназначены для измерения времени и к тому намного более точные

Ну-ну. Инициализации страниц ты тоже не придал значения и в итоге сам себя окрестил "ламерюгой" Или ты хочешь оценить пропускную способность CPU+RAM и тогда должен приложить все усилия для предотвращения "тлетворного влияния" ОС, или ты оцениваешь "реальную" проп.способность с учетом пакостей ОС - но тогда и не удивляйся заниженным в несколько раз значениям и не сравнивай их с тестами ixbt и т.п.

Поэтому для оценки максимума нужно обязательно задавать реал-тайм приоритет и к тому же не гонять 50Мб за один раз, а взять скажем 16Мб, прогнать тест 4-8 раз и взять минимальное из полученных значений, отбросив таким образом возможные выбросы за счет вмешательства ОС.
И кстати, если у тебя P4 с Hyper-Threading, то для оценки макс.проп.способности его следовало бы отключить в биосе (т.к. 2.0-2.5Гб/с при номинале 6.4Гб/с тоже не ахти какая скорость)

 

leo

Нет, точности хватает и без этого.

А что это даст? Увеличит точность на 2 msec?

Я вроде написал почему так вышло, на P4 результаты были вполне приемлемы.

Ну что же посмотрим.

Об этом в курсе, но у меня не HT.

 

Ну значит у тебя на компе какая-нить звуковая служба рулит и юзает период 1 мсек и соотв-но reduce overall system performance, т.к. в нормальной ситуации сис.таймер тикает раз в ~15мсек

1) главное - позволит отказаться от timeBeginPeriod(1) и использовать нормальный квант времени по умолчанию (если ты сам не уменьшаешь интервал и за тебя это делают какие-то "звуковухи", то их можно и поутрубать на время)
2) позволит измерять меньшие интервалы и юзать меньшие размеры буферов

PS: чуйствую у меня начинают зреть тухлые помидоры

 

leo

http://www.wasm.ru/forum/viewtopic.php?pid=287414#p287414
rdtsc - единственный достойный инструмент измерения - всё остальное от лукавого m$ )