Истина где-то рядом. Эксперимент от SASecurity group

Гуляя по просторам сети Интернет в поисках интересной информации, Дмитрий Оношко наткнулся на интересную статью на портале govnokod.ru, автор которой утверждал, что код, генерируемый Delphi для округления вещественных чисел, дает резкое падение скорости выполнения программы. Delphi для округления создает функцию-обертку Round() над инструкцией сопроцессора FRNDINT. По сути, претензия автора обращена к тому, что лишний CALL-RET при выполнении этой операции недопустим и расточителен. Предлагаемый автором вариант - подстановка инструкции FRNDINT на место каждого из этих вызовов. Сгенерированный компилятором код согласован, Delphi 7.

Интересное утверждение, не правда ли? Однако на основании чего автор делает такой вывод? Дмитрий решил устроить небольшой тест, который покажет ситуацию в реальном свете. То ли случайно так оказалось, то ли нет, но Дима – член независимой группы SASecurity gr., и после изложения им своей идеи мы приняли решение сделать хороший тест, который выяснит все до конца. Не сказать, что проблема критически важная :), однако интерес к вопросу оказался больше рационального распределения времени. Именно поэтому в данный момент все члены группы SASecurity gr. ждут дальнейших инструкций для начала тестирования. Я же обладаю некоторыми сведениями, которые приподнимут немного занавес и позволят всем поучаствовать в обсуждении результатов тестирования.

Для тестирования написано минимальное Win32-приложение на FASM: окно, обработка сообщений через GetMessage(), однопоточное. Код Delphi'йской функции Round() извлечен дизассемблером и помещен без изменений в программу. Результат округления помещается в память. Delphi'йская версия алгоритма, таким образом, заведомо ставится в невыгодное положение, поскольку, по своей реализации, сначала извлекает результат округления в стек, после чего возвращает копию результата в регистрах EDX:EAX. В реальной программе такое применение маловероятно, поскольку результат округления в большинстве случаев идет на дальнейшую обработку и закономерным образом попадает именно в регистры. То есть условия несколько синтетичны в пользу не-Delphi'йского варианта, при прочих равных.

. Рассматривается 2 реализации альтернативного алгоритма: с WAIT и без WAIT перед FRNDINT.

. 3 способа измерения времени выполнения: API-функция GetTickCount(), инструкция RDTSC и пара инструкций CPUID-RDTSC.

. 2 варианта: с привязкой потока к одному ядру и без привязки (потенциально многоядерная версия).

Получаем 12 версий программы для тестирования. По каждому варианту предполагаю получить не менее 10 измерений на каждый компьютер. В тестировании будет участвовать около 10 компьютеров - получим около полутора тысяч измерений на различных конфигурациях.

О тест-машинах будет собираться следующая информация:

1. Процессор: производитель, модель, тактовая частота, количество ядер, поддержка технологии HyperThreading.

2. RAM: объем.

3. Тип компьютера: стационарный/нетбук/ноутбук, если портативный – то наличие/отсутствие питания от сети, режим энергопотребления.

4. Операционная система: версия, сервис-паки.

5. Установленное ПО: антивирус (включая режим работы при тестировании), пакеты 3D-моделирования, видеомонтажа и др. "тяжелое" ПО.

К тому времени как вы прочтете этот текст, тестирование уже начнется, и все результаты по мере их появления будут доступны на специальной странице и отдельном топике SASecurity Forum’а. Линк на топик форума прилагается: http://forum.sa-sec.org/index.php?showtopic=2761. Ждем ваших комментариев – они важны! По всем вопросам можно обращаться на q@sa-sec.org, в теме письма укажите название статьи — «Истина где-то рядом. Эксперимент от SASecurity group».

Евгений Кучук