Алгоритм эфективного нагрева проца...

AndreyATC
Дык выравнивай код (сам цикл) NOP'ами (db 90h). А вообще, есть такая прога - TAT (Intel Thermal Analysis Tool), заточена под интеловские процессоры: hxxp://overclockers.ru/files/index.shtml?dir=33 - поищи на этой странице, там много чего другого полезного есть.

ЗЫ. Про S&M там написано "Эффективнее чем CPUBurn".

 

Atlantic

Во первых это не секрет, а реализация очевидного требования максимальной загрузки наибольшего числа блоков процессора, включая front-end (декодер, RAT,ROB). Во-вторых, достижение максимума пропускной способности в 3 инструкции за такт это не гарантия эффективного нагрева. Например, с точки зрения числа инструкций за такт fld [ebp] и fld [ebp+edi+0] эквивалентны, но вторая эффективнее, т.к. больше нагружает AGU. Далее почему fmul\fsub эффективнее простых ALU-операций, только потому, что они оперируют 64-битными мантиссами ? Не только, т.к. они еще выполняют ряд "скрытых" действий по нормализации операндов и т.п., поэтому латентность целочисленного сложения = 1 такт, а fadd - 4 такта. Но т.к. fmul\fsub конвееризованы, то их throughput составляет 1 такт и независимые fmul\fsub могут выполняться с перекрытием. За счет этого эффективная нагрузка возрастает, т.к. при перекрытии в каждом такте реально выполняется не 3 мопа, а значительно больше (до 6-9). Т.е. получается, что чем больше латентность конвееризованной операции, тем больше независимых мопов могут находиться в обработке в каждом такте. Аналогичная ситуация может быть и с подгрузкой данных из L2 в L1, т.к. всего один моп mov при кэш-промахе активизирует кучу скрытых действий по поиску и пересылке 64-байтной строки, причем при правильной организации эти действия не тормозят конвеер, а выполняются параллельно с alu\fpu. Речь ес-но не идет о том, чтобы использовать одни mov, а о том, чтобы к коду, эффективно использующему alu\fpu добавить дополнительную нагрузку на кэш. Чтобы при этом не нарваться на тормоза достаточно 1) не использовть результат mov, тогда большая латентность L2 (отрицательной) роли не играет, 2) не вытеснять из L1 адреса, используемые в alu\fpu вычислениях, 3) иметь в виду макс.число ожидающих промахов (outstanding misses) L1 = 4-6-8 в завис-ти от проца - произведение этого числа на число тактов на цикл должно быть меньше латентности L2 (для 3-4 тактов тактов на цикл это вроде бы выполняется для всех камней).

PS: в коде S&M инструкции xor и первый fxch являются сравнительно "бестолковыми" (выравнивающими), поэтому для P6, P4E и AMD64 одну из них лучше заменить на mul/imul. В К7 (атлон ХР) это не имеет смысла, т.к. у них mul\imul - vector path, а в первых P4 mul\imul реализованы на fp_mul

 

leo
Респект - как всегда, все разложил по полочкам. Надо будет посмотреть, что там в новой версии S&M изменилось на разных процах.

 

Atlantic
Ага, особенно, почему оно на Core 2 не пашет

 

Ustus
На Core2 пашет, только греет хуже, чем TAT. Похоже, у автора нет Core2, поэтому он не может написать соответствующий код.

 

Atlantic
у мну они одинаково греют! просто S&M тестит и еще кучу всего делает)
да и не в том дело чтоб потестить!
мне сам алгоритм прогрева интересный)

 

Хе... покрутил в руках Intel'овский TAT - оно тоже FPU гоняет