собственно сабж ... в ntdll их такое количество, что страшно подумать как он похудеет, если их убрать ... так вот вопрос, они действительно нужны или не более чем прихоть кодеров из мелкософта ... зы. слышал про бесполезные циклы в hal.dll, это случайно не из той же серии ?
либо align, либо hot patching (скорее первое, особенно если перед\после функции в количестве до 16\32 нопов)
el- Если ООООчень нужно, чтобы похудело, то можно, но как пишет Касперски: т.е. скорость заметно упадёт...
А вообще интересно - Касперски приводит пример где невыровненный цикл съедает ~30% скорости, а leo пишет: Так на что ориентироватья? Выравнивать циклы или нет? Или на разных камнях по разному?
Касперски, если я правильно помню приводит пример для PIII/Athlon. Так и есть, и не только это, к сожалению
Y_Mur Хоть бы ссылку привел - самому интересно чего это я пишу )) Приведенная фраза относится только к NetBurst (P4 и Ко) Но где-то и вроде не раз, я брал смелость утверждать, что и для P6\AMD требование выравнивания само по себе не обязательно и не может давать полной гарантии максимума скорости. На самом деле важны 3 вещи: 1) от метки цикла до конца 16-байтного блока должно быть достаточно мопов, чтобы "максимально" загрузить декодер хотя бы на 1 такт (т.е. либо как минимум 3 мопа direct path, либо 1 vector path), иначе декодер будет в первом такте работать с недогрузкой 2) не должно быть разбивки "критических" инструкций границей 16-байтного блока 3) желательно, чтобы условный переход не вываливался в гордом одиночестве в отдельный 16-байтный блок (иначе загрузка декодера в начале цикла, компенсируется недогрузкой в конце) Выравнивание цикла на 16 решает первую проблему, т.к. при выравнивании мы имеем максимум возможных мопов от метки начала цикла до конца блока. Но вот вторую проблему таким универсальным методом не решишь, поэтому в ответ на пример Касперски можно привести другие примеры, когда искусственный сбой выравнивания цикла дает выигрыш в скорости. Поэтому при ловле блох, если возникают ситуации 2 и 3, то приходится экспериментировать со смещением метки цикла и\или с перестановками и искуственным изменением длины инструкций
В P6 и AMD код грузится 16-байтными блоками с макс.скоростью 1 блок за такт. Если в этом блоке достаточно инструкций, чтобы загрузить декодер, то фетчер за время декодирования блока успевает загрузить следующий блок. Если же в блоке всего одна полезная инструкция, то соответственно декодер вместо 3-х возможных инструкций декодирует за такт только одну. Такая ситуация может возникать как при невыравненной метке цикла (первый блок содержит всего одну инструкцию или еще хуже ни одной, если первая инструкция разбивается границей 16 байт), так и в последнем блоке цикла, если он содержит только jcc да еще не дай бог разбитый по границе блока. Но следует иметь в виду, что все эти "штучки" не приводят к 100% потерям - они лишь образуют дырки (пузыри) в потоке мопов с декодера. Реальные потери будут в том случае, когда исполнение мопов идет со скоростью декодирования или быстрее, а если медленее, то очереди планировщиков сглаживают эти дырки и на итоговой скорости исполнения все эти невыравненности могут никак не отразиться
