Лучшие решения для оптимизации

Pavia
1) Сначала посмотри в таблицы, потом поговорим История с погоней за сверхчастотами в NetBurst это наглядно показала, и нет никакой гарантии, что это не повторится в будущем
2) Никак не мерить. Латентность измеряется в целых тактах и об этом уже все сказано. А мерить некую "среднюю температуру по больнице" - бессмысленно. У throughput есть несколько определений. В интеловском смысле это минимальное число тактов между запусками независимых инструкций на один и тот же исполнительный блок - и соотв-но никаких дробей тут быть не может (за искл. NetBurst, где все измеряется полутактами). В понимании А.Фога и АМД это обратная величина пропускной способности, т.е. числа независимых инструкций за такт - соотв-но тут могут быть и 0.33 и 0.25, но это уже совсем другая история
3) Мувы на современных процах от размера не зависят, т.к. все они расчитаны на передачу не менее 64 бит за такт, поэтому им пофиг сколько передавать - 1 байт или 4
4) Интересно знать какие такие "некоторые арифметические операции". Если самому мерить абы как, то всякое возможно. А планировщику при конвеерной обработке нужно точно знать, когда запускать следующую инструкцию на занятый блок, т.к. если ждать сигнала готовности с выхода блока, то за счет конвеера получим чистую потерю пары тактов. Именно поэтому для быстрых блоков\инструкций планировщик запускает следующую команду исходя только из табличной латентности (отсюда кстати и реплэй в NetBurst), а вот для тормозных делений и тем более сверхтормозных фпу-шных операций он может и подождать установки флага готовности, т.к. потеря пары тактов тут роли не играет
5) Во-первых, проц это тактируемая железяка и в одинаковых условиях он работает совершенно одинаково. Во-вторых, правильно надо мерить, тогда и расхождений не будет

PS: Не задумывался - почему в мануале АМД латентности всех операций (и даже их вариаций) четко расписаны ? Делать им что ли нечего, как задержки "мерить" ?! Да потому, что все эти латентности (или по кр.мере большинство) нужны самому процу и зашиты в его планировщике. И у интела наверняка полные таблицы есть, только они жмотятся или стесняются выставлять их на всеобщее обозрение

 

Быстрее железо.

 

leo

А как же задержка от обращения к полному регистру после частичного? а выравнивание на dword? - это всё уже не актуально?

 

Y_Mur
Не нужно все валить в одну кучу, как Pavia Иначе вообще не разберешься что к чему и придется все только "мерить" по факту. А если отделять "мух" (штрафы, пенальти, зависимости команд, конфликты портов и исп.блоков) от "котлет" (принципы работы, табличные латентности, проп.способности в нормальных=идеальных условиях), то можно достаточно точно спрогнозировать\сэмулировать (почти) любую последовательность (простых) команд, что собс-но и делает амд-шный CodeAnalyst и что можно сделать самому на бумажке, если разбираться в "мухах" и "котлетах".
Что касается твоего замечания, то "мувы от размера не зависят" - это вкусная котлета, которую можно проглотить одним махом независимо от размера. Но если не соблюдать правила гигиены и не мыть рук перед едой, то ее могут обгадить вредные мухи различных видов: partial register stall, store-to-load forwarding restriction, address generation interlock, cache line split, cache line miss и т.д. и т.п. - о всех "тварях" в одном кратком посте не раскажешь, нужно штудировать мануалы

Что касается вопроса 4), то нужно иметь в виду, что исполнение комплексных команд с операндами памяти (типа add reg,mem или add mem,reg) может вообще размазываться во времени в реальном потоке команд. Для них табличные латентности относятся к идеальному случаю, когда все регистры готовы, данные находятся в кэше и нет конфликта портов\исп.блоков. В реальных же ситуациях при плотном потоке регистровых команд или задержки готовности reg (например в рез-те умножения или деления), часть операции по загрузке операнда из памяти м.б. выполнена намного раньше, чем сама операция add. Поэтому в таких случаях говорить о задержке или изменении задержки такой операции вообще не имеет смысла и нужно анализировать поток микроопераций и смотреть общую задержку блока команд (как это делает CodeAnalyst)

 

leo
Про мух и котлеты - конечно здорово , но мне пока слабо удержать в голове все мушиные лапки (хотя с опытом их становится всё больше), поэтому предпочитаю подобно ТС коллекционировать/формулировать упрощённые правила, придерживаясь которых можно не отвлекаясь на оптимизацию писать нормально-быстрый код который есно не претендует ловлю блох, но и не содержит особо тормознутых конструкций

 

Y_Mur
Ну и правильно, я с блохами тоже не часто общаюсь
Вот только зачем тогда провокационные блошино-мушиные вопросы подкидывать и раздувать дискуссии, если ТС-у достаточно упрощенных ответов

 

leo
ну хотя бы потому, что одно из моих упрощённых правил - по возможности избегать word и byte, в пользу выравненных dword
или стоит это правило подкорректировать?