Какие команды нагревают CPU?

locki

Надо не просто смешивать, а так чтобы максимальное спаривание получалось. По возможности надо заставить тяжелые команды обращаться к обоим кэшам (непрерывное чтение блока памяти размером = L2.Size). И желательно каждые инструкции выполнять группами (размер группы подбери экспериментально), чтобы осуществлялся прогрев всех ИУ.

 

locki

Начать дано бы с того какой проц? И что мешает все же по S&M vtune пройтись?

 

Вот нашёл у себя какой-то бюрнер с исходниками, может поможет.



burnP5 is optimized for Intel Pentium w&w/o MMX processors

P6 is for Intel PentiumPro, PentiumII&III and Celeron CPUs

K6 is for AMD K6 processors

K7 is for AMD Athlon/Duron processors

MMX is to test cache/memory interfaces on all CPUs with MMX

BX is an alternate cache/memory test for Intel CPUs



1250080086__CPUBURN4.ZIP

 

alpet смешивал не просто а примерами из Фога по спариванию команд. АЛУ ММХ и ФПУ.semen



semen Проц Нортвуд,

С ВТюном , что-то разобраться не могу.

 

locki

Ну допустим, что у Фога теория хорошая. На практике лучше посмотреть на пайп-симуляторе (AMD CodeAnalyst, pipeline-simulation работает только с процами AMD), но у тебя к сожеланию проц интеловский. Во всяком случае я не раз убеждался что иногда и векторные чижелые операции частично спариваются с простыми.



Команды лучше располагать группами - ALU, FPU, MMX по отдельности, порядка по 100 операций из каждый, причем каждая пускай читает одну кэш-линию (32, 64, или 128 байтную).

 

locki

С втюном: создаешь проект - кажишь ему экзешник, проверяешь что включен event based sampling(должен быть по дефолту) - запускаешь. Останавливаешь и смотришь какие участки кода больше всего времени ели - смотришь на них и усе.

 

alpet

> "Команды лучше располагать группами - ALU, FPU, MMX по отдельности, порядка по 100 операций из каждый"

А ты хорошо подумал, прежде чем такое предлагать ...



Задача в том, чтобы получить максимальную пропускную способность CPU, т.е. максимум различных операций выполняемых одновременно. Поэтому во-первых одновременно должно быть задействовано максимум исполнительных устройств и во-вторых, все стадии конвейера должны работать согласованно. Что будет если мы в P4 запустим подряд 100 операций FPU ? А то что в ROB максимум помещается 128 мопов, поэтому никакого переупорядочивания и распараллеливания не будет - будут работать подблоки FPU, а ALU и MMX будут в это время простаивать. Даже не сотня, а каких-то 3-4 FDIV\DIV\IDIV подряд приведут к приостановке конвеера, т.к. дивы не буферируются (throghput = latency) и выполняются по ~50 тактов и даже если параллельно с ними выполнится сотня следующих за ними мопов ALU\MMХ, они не смогут уйти в отставку пока не завершаться все предшествующие дивы, ROB переполнится и конвейер приостановится.



Вывод простой: нужно открыть табличку таймингов А.Фога и подобрать последовательность "простых" инструкций ALU, MMX, FPU согласованных по исполнительным блокам, latency и troughput чтобы достичь максимума пропускной способности 3 мопа за такт. "Простых" означает с минимальным числом мопов, иначе будет тормозить трэйс-кэш или ретайрмент (по этой же причине не имеет смысла на P4 "выжимать" максимальную нагрузку в 6 мопов за такт за счет fast ALU).

Ну например, на вскидку для P4 может подойти что-то типа последовательности пачек FMUL,MOV(m,r),SHL(r,i),ADD(r,r),MOV(r,m) - это должно быть около 2 тактов по 3 мопа (если fmul и shl в соседних пачках независимы по данным). Поэтому через ~ 25 таких пачек можно вставлять одну FDIV - пущай подогревает в фоновом режиме

 

leo

Где-то я видел в мануалах по AMD утверждение, что смешивать разнородный код, по возможности не стоит.

Потом в S&M - все тесты жестко разделены, и я смотрю - ее показатели во всех тестах очень хорошие (на FPU - лучшие, а вот MMX у меня почему-то не показался) - напряжение 12в провисает с 11,8 до 11,67в, что свидетельствует от большом потреблении тока преобразователем (vcore провисает с 1,6в до 1,55в). Впрочем надо для сравнения что-нить самому написать.

[edited]

Максимальный результат S&M = 55 гр. Цельсия.

 

alpet

> "утверждение, что смешивать разнородный код, по возможности не стоит"

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



Может имеются в виду "квазиразнородные". Например в P4 моделей 1-2 все умножения выполняются на fp_mul, а все деления на fp_div - и вещественные, и целые и SIMD. А целочисленные сдвиги на mmx_shift, поэтому и тормозные. Конечно в такой ситуации расчитывать на параллельное выполнение например fdiv и idiv не приходится и "смешивать по возможности не стоит"

 

leo

Во всяком случае когда я наблюдаю выполнение смеси ALU и MMX кода на AMD Athlon (под CodeAnalyst), DPI MMX инструкции возрастает, после ALU. Впрочем насколько я смог разобраться - на производительность это влияния не оказывает.



Выглядит это примерно так:

<font face="fixedsys]

<font size=1>

mmx *******e***r

alu *e*********r ;; dpi = 5

mmx ********e**r ;; dpi = 0

alu *e**********r ;; dpi = 5

mmx ********e***r

</font><!--size-->

</font><!--face-->

Повидимому это результат оценки DPI используемый в CodeAnalyst для всех инструкций. Возможно лучше было бы иметь несколько счетчиков DPI (ALU/FPU/MMX), дабы не наблюдать слишком большие значения, которых вобщем-то нет.

 

alpet

Ну что ты со своим АМД и код аналистом пристал? Не поможет он - сказали же - проц пень, норсвуд - и для эффективного нагрева нужен разный код - Лео все верно объяснил, применительно к нужному процу. Задача какая? Задействовать как можно больше блоков одновременно. Т.е. подобрать последовательность независимую по блокам и пихать в каждый блок не раньше истечения throghput`а предидущего предидущего запихнуто мопа в этот блок. Приоритет отдавать греющимся блокам для данного камня и способам максимально нагреть данный блок. И нюансов все равно много - и дока интела и амд код аналист для амд помогут тока отчасти. Тут эксперементировать надо. Вообще простейший способ - это поджарить кэш - но это не предел... А лучше все же взглянуть на плоды трудов других людей и взглянуть в S&M.

 

alpet

Дык а чего ты хотел, я тебе о том же и говорю - "смешивать" нужно с умом, т.к. дело не в смеси, а в согласованности throughput и латентностей. Ретайрмент все равно не выпустит завершенную инструкцию ALU пока не завершаться все предудущие тормозные MMX и FPU. Именно поэтому не нужно пускать подряд несколько тормозов (особенно с большими throughput), а наоборот после каждого тормоза запускать кучку быстрых операций которые успеют выполнится к моменту завершения этого тормоза и все дружно пойдут в отставку.

 

leo

Что-ж будем экспериментировать. Я пока написал раздельные тесты - эффекта такого потребления тока как в S&M пока не удалось добиться, температуры тоже.

[edited]

Хм. Забавно, после запуска моего теста на Атлоне - температура упала с 50C до 43C. Как оказалось - в фоновом режиме работала забытая программа ms-rem для рассчета хэшей MD5, и ее вытеснила моя прога. Мельком глянул ее - вроде нет тяжелых инструкций, все вроде ALU.



Наткнулся таки на самые тепловые инструкцию в коде hashgen - ими оказались... push and pop.



После проверки оказалось, что pushad и popad тоже неплохо греют. Какая же полезная оказывается для отладки штука - мультиметр, а я то думал они только в релейных компах нужны



На Атлоне ситуация такая: при запуске разогревающего приложения напряжение на шине 12в возрастает с 12.28 до 12.42 вольт (12.44 в случае hashgen) - сказывается реакция БП PowerMan. Интересное наблюдение - по мере разогрева процессора, растет и ток, и соотвественно напряжение. На моем тесте достигаются уже не худшие значения чем у hashgen.



Инструкции idiv и imul оказались холодными, равно как обращение к памяти (L1/L2).

 

Ну у меня такие результы: тест памяти запись, чтение, сравнение с эталоном на 5.5% отстает от S&M

это самый горячий вариант.

 

alpet

гг - действительно, как ты кэш греешь? не может он не греца - и push\pop из-за него греются сто пудов...

 

semen

Нет - только добавляю операцию чтения (или записи) - почему то сразу снижается. Да и так пока не сравнивал (с S&M), едва достиг только результатов hashgen (который и память трогает, и много Alu операций выполняет). Кстати - для превышения его результата, пришлось добавить две простых FPU операции (fadd).

 

Ну а дебаггером каким S&M глянуть никто не может, че у него там за наборчик

 

alpet

Тока что попробовал атлон - греет еще как - тока низя, чтоб к реальной памяти обращения были - иначе все стынет =)

 

semen

Я и не говорю что не греет. Просто просадка напряжения ядра спадает (хоть и чуть-чуть), при добавлении операций с доступом к памяти (L1/L2 без разницы).

Вот код подобранный в последний раз:

Код (Text):

1.  
2. lea  esi, test_buff
3. mov  ebx, L2Size
4. finit
5. fld1
6. fld1
7. fld1
8. lp:
9. call xp
10. sub  ebx, 32
11. jnz  lp
12. ret
13.  
14. xp:
15. fadd  ST(1),ST(0)
16. fsub  ST(2),ST(0)
17. push   edx
18. pop   ecx
19. xor   eax, 101010101h   ; in eax must be initial value
20. xadd  ecx, edx
21. lea   edx, [eax + ecx]
22. rcl   eax, 15
23. xor   edx, ecx
24. rcr   ecx, 17
25. xadd  ecx, eax
26. xor   eax, edx
27. ret
28.  

Приведи свой код, я его хоть сравню



З.Ы. Получается кстати своеобразный генератор псевдо-случайных чисел.

 

alpet

Вот код:

Код (Text):

1. #include <windows.h>
2.  
3. #define size 1024*1024*2
4.  
5. DWORD WINAPI burn(void *param)
6. {
7.     DWORD *pData = (DWORD *)VirtualAlloc(0, size*2, MEM_COMMIT, PAGE_READWRITE);
8.     pData = (DWORD *)((DWORD)pData & ~((1 << 16)-1));
9.     for(;;)
10.         for(int i = 0; i < size/8; i++)
11.             pData[i]++;
12.     return 0;
13. }
14.  
15. extern "C" {
16.  
17. int mainCRTStartup()
18. {
19.     DWORD id;
20.     CreateThread(0, 0, burn, 0, 0, &id);
21.     burn(0);
22.     return 0;
23. }
24.  
25. }

Размер кэша только подставь - годится как для атлонов так и для пней с ХТ. По желанию запись\чтение можно попробовать делать XMM регистрами - я не пробовал и так жарится дай боже.