(mov al, byte [esi] + add esi, 1) vs lodsb

Что быстрее и почему?

 

спецификацию на instruction set нужного процессора не судьба скачать и сравнить самому?

 

скачал, курил...
Делал замеры тиков ...
неоднозначные результаты

Примерно в 2/3 случаев быстрее mov + add
Почему - пока непонятно.

 

Вообще говоря, не нужно ничего ни замерять, ни понимать Достаточно прочитать в оптим.мануалах общее правило - avoid complex instructions, поскольку на современных компах все бестолковые фишки времен 8086 типа lods, loop, jecxz и т.п. выполняются дольше, чем соотв-й набор отдельных команд

PS: Первая причина по счету (но не по тормознутости) - это то, что сложные команды декодируются через MicrocodeROM, который занимает целое число слотов\тактов времени, но при этом выдает не макс.возможное число микроопов. В частности lods состоит из 2 мопов, которые генерятся за 1 такт, хотя за это же время декодер мог бы выдать не менее 3х (или 4х в Core 2) мопов на простых командах. Но основной "тупизм" команд типа lods и loop состоит в том, что они не должны изменять регистр флагов, а современные компы этого "ужасно не любят" и соотв-но притормаживают даже на простых inc\dec

 

работают они быстрее, но и размер команды увеличивается. и к набору команд не применить rep, для цикла, что оптимальнее и короче. каждый выбирает свой путь. экономить место или ускорять работу. хотя второе на новых компах уже не приносит заметный прирост скорости как в старых.

 

разве раскодирование дольшего потока комманд не влияет?

 

И что ? Оперативы не хватает, как на 8086 ?!

Первое тем более ничего не дает на современных компах. У тебя что, вся прога из одних lods и loop состоит ?!

Rep считается префиксом чисто условно, а на самом деле в современных компах movs и rep movs это совершенно разные команды - без rep только тупит\тормозит, а c rep достаточно оптимизирована и выполняется довольно шустро - на уровне развернутого цикла. И ваще не нужно "открывать Америк", т.к. все это давным давно расписано\разжевано во всем мануалах по оптимизации

 

а ты не заметил что в мануалах по интел и амд пишут по разному.
да и еще интел просто накручивает. я читал интересную статью, где via подменила cpuid на соответствующие интел, и прикол, производительность в тестах выросла в несколько раз. вот те и оптимизация.
писать надо коротко и ясно. а внутри процессора команда все равно быстрее выполнитца, чем ты ее сам рампишешь.
оптимизировать можно только битовыми командами, а остальное бред. иначе зачем их придумали.

 

Я уже сказал, что все эти lods, loop и т.п. - пережитки древних компов, когда каждый байт был на счету. И уже с десяток лет Intel с AMD талдычут, что лучше их не использовать - нужно просто забыть об их существовании и не забивать ими мосК, тогда и вопросов не будет возникать насчет "коротко и ясно", т.к. проще написать стандартные mov+add, чем помнить о какой-то lods и какой регистр она юзает. К тому же юзать edi не всегда удобно - например, нафига его пушить\попить\мувить, если скажем есть свободный регистр edx ? Ан нет - мы же начитались всяких там древних Зубковых и Ко и думаем, что каждый крутой асм-кодер должен непременно юзать lods и loop, ну как же без них !

 

Что это было?

 

Это с бодуна

 

Нефиг тесты Intel С++ Compiler компилировать (точнее его патчить надо)
Он умеет генерировать несколько веток кода для разных CPU - например с SSE2 и generic без.
Но прикол в том что скомпилированное приложение при старте проверяет CPUID - и если проц не Intel, наличие SSE2 даже не смотрит, работает generic код (естественно медленнее).
Это известный фокус интеловцев, где-то в сети даже целые петиции им писали.
Так что тут дело не в оптимизации.

Для тех кто на бронепоезде - процессоры сейчас суперскалярные, быстрее выполнится аналогичная последовательность простых команд, а не одна сложная.

Вот не надо на Зубкова гнать Он в своих книжках такого не советует, а его книга по ассемблеру одна из лучших.
А по оптимизации лучше Optimization Manuals читать.

 

Да это я так - образно. Хотя в каждой шутке есть доля шутки. Например, уроки Iczelion'а в целом тоже весьма полезны, но с его бездумной\легкой подачи у ньюбов частенько складывается дурное пристрастие к безнадежно устаревшей и бестолковой GlobalAlloc с флагом GMEM_MOVEABLE - помнится даже пришлось настрочить "наболевший" коммент к уроку 12

 

Меня очень удивило ОЧЕНЬ много команд вроде lods,stos,movs,(loop (даже, вроде)) в коде фасма. А Томас говорит, что это упрощает код, то есть его легче понять. Не могу сказать, что в этом нет смысла вообще.

И пожалуйста, ответьте мне на вопрос, вот в 32-битных машинах загрузка (mov eax, [mem])дворда быстрее ворда или байта (выравнивание, кеш и тд не учитываем). А вот на 64-битных процах будет ли загрузка 64-битного числа быстее, чем 32??? Проц 32 и проверить возможности нет...

 

Сама по себе команда mov выполняется одинаково быстро независимо от размера операнда 8, 16 или 32 бита (а на x64 и 64 бита). Другое дело, что при обработке массивов данных, чем больше мы берем размер операнда, тем меньше получается общее число загрузок и соотв-но выше общая скорость

 

leo
А разве нет пенальти при частичном заполнении регистра? Ведь поэтому в 64 и обнуляют остальную часть регистра при загрузке части (насколько я понимаю, чтобы не возникало ложных зависимостей)? Хотя вы, скорее всего правы, потому, что в любом случае подгружается всё равно вся линия кеша.

 

cppasm
Не надо там ничего патчить.
Просто не стоит использовать ключ /Qax, который генерит разные ветки.
Собираю всегда с /Qx, собранный код работает на amd процах.

 

Патчить - это как раз в данном случае человеческое решение.
Потому что CPUID проверяться не будет, а наличие расширений и выбор оптимальной ветки кода - будет.
А с твоим подходом скомпилируй код с SSE3, запусти на любом 32-битном Athlon'e и посмотри что будет.
Если собрать с Qax и патченной RTL - будет generic x86 ветка работать, а если с Qx - приложение упадёт с исключением.
Что лучше - каждый сам выбирает.
Лично я выбираю чтоб работало, пусть и медленнее.

Если патчить не хочется, есть более "законное" решение от Агнера Фога:
http://www.agner.org/optimize/optimizing_cpp.pdf
Стр. 129, CPU dispatching in Intel compiler.
Вот обсуждение: http://www.agner.org/optimize/blog/read.php?i=49

Я предпочитаю один раз RTL пропатчить и забыть.

На ассемблере пишут чтоб жизнь процу упростить, а не себе.
Желающие упростить код могут смело на Си переходить

 

Z3N

Эти пенальти из разряда implementation specific. В Pentium 4 и AMD K7 (Athlon XP) вообще таких проблем нет. В семействе P6 (включая Core2) тоже нет проблемы с записью в частичные регистры - есть только проблема использования целого регистра после частичной записи, но эта "проблема" хорошо и давно известна и => является скорее фичей (характерной особенностью) P6, нежели каким-то недостатком. Поэтому общую "идиллию" портит только линейка AMD 64, в которой чтение mem8 и mem16 выполняется на 1 такт дольше, чем 32\64. Хотя в потоке команд за счет конвееризации разница между 3 и 4 тактами на чтение практически не сказывается.

 

Я не понимаю, что мешало им заоптимизировать комманды с префиксами rep

ведь понятно, что код

Код (Text):

1. mov ecx,0x00400000
2. rep movsd

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