Привет Хабр! После прочтения недавней статьи Придётся ли Intel убрать из компилятора функцию, намеренно выдающую плохой код для процессоров AMD? и всех комментариев к ней, как ни странно не увидел главного: тестов “живых” приложений до применения патча, блокирующего диспетчер процессора в коде компилятора Intel и после.
Имея в запасе выходные дни и являясь тем самымнесчастливым обладателем процессора от компании AMD решил более детально изучить вопрос. А именно выяснить, действительно ли видна значительная разница в производительности реальных приложений, скомпилированных компилятором от Intel?
Начать я решил с прочтения оригинала статьи на английском, а так же прочтения всех дискуссий на эту тему на различных форумах. Удивительно, но и там я не обнаружил ответа на свой вопрос – каков же реальный прирост в реальных приложениях. Зато обнаружил информацию о том, что в зависимости от версий компилятора, регистры в коде диспетчера процессора могут быть разными, а не только eax, ebx, ecx, edx и ebp, как например реализовано в патче intel_patch-ppro.pl. Могут так же применяться регистры esi и edi. Не являясь знатоком Perl и не имея его интерпритатора на компьютере, было решено набросать “на коленке” новый патч на Pascal’е (Virtual Pascal, но может быть запросто скомпилирован и Free Pascal). Сам патч и его исходный код можно найти здесь: icc_patch.rar
Вторая задача которая встала передо мной – а как собственно определить, скомпилирована ли та или иная программа с помощью Intel Compiler? Казалось бы, на помощь должны прийти программы типа PEiD. Что творится у них с сигнатурами я не знаю, но они выдают среднее расстояние от ларька с пивом до луны. PEiD меня заверяла, что тут же скомпилированная программа на Delphi с пустой формой и отрезанной Reallocation Table — написана на Borland C++ compiler, ну и тому подобные вещи. Конечно от этого варианта пришлось отказаться. Второе очевидное решение — перелопачивать все EXE-файлы на компьютере и искать в них то самое сравнение cmp eax, ‘Genu’ и тд. Но, такие проверки есть во многих программах, не имеющих отношение к компилятору Intel. По-этому пришлось набраться терпения и поискать в имеющихся на компьютере “тяжеловесных” программах приблизительный код, который уже показывали в комментариях к прошлой статье:
В итоге из всего набора софта, установленного на компьютере такая программа нашлось только одна, и о чудо – она оказалась бенчмарком! Ею оказалась CineBench R10 от Maxon
В ней прекрасно находятся вышеописанные участки кода. Без лишних слов пользуемся патчером на главном EXE программы, а также не забываем пропатчить все остальные библиотеки программы, которые к слову, имеют нестандартное расширение .CDL. Сам тест производит оценку скорости рендера картинки и, как итог, выдает некие “попугаи”. Теперь самое время взглянуть на график:
Было произведено по три запуска программы с патчем и без патча. Как видно на графике, результаты различаются. Но на самом деле, различаются весьма и весьма не значительно, график немного искажает представление. Например если брать время рендера, то на пропатченной программе оно составляет приблизительно 7 минут и 30-40 секунд, а на бенчмарке без патча 7 минут 50 секунд – 8 минут. Средняя разница составляет не больше 15-20 секунд.
Что же мы видим в итоге? Да, некоторая разница есть, но она столь ничтожна, что ей можно смело пренебречь. Если на больших (долгих по времени) задачах разница не превышает 20 секунд, то на простых (офисных) задачах ее не будет видно совсем.
С другой стороны важно не обманутся – ведь никто не мешал разработчикам данной программы все критические циклы написать на чистом ассемблере, тем самым оказаться независимыми от компилятора. И я подозреваю, что так оно и есть, поэтому полной картины с этой программой увидеть к сожалению не удалось.
Что же я выяснил за это время для себя? Первое – что программ, используемых повседневно на компьютере рядового пользователя и скомпилируемых с помощью Intel Compiler не много. Если быть точнее – мизирно мало. Второе – на чужих программах очень трудно оценивать прирост производительности, потому что не известно, как они устроены изнутри. В настоящее время идет медленное скачивание триальной версии компилятора, для проведения эксперимента непосредственно на собственных программах. Уже тогда можно будет делать хоть какие-то более-менее достоверные выводы.
Цель данной статьи не разжигание холиваров на тему Intel vs AMD, или подобных. Цель выяснить и понять, так ли уж сильно влияет тот самый пресловутый диспетчер процессора на время выполнения программ, как нам приподносится в оригинальной статье. И я хотел бы это сделать с твоей помощью, %username%.
Имея в запасе выходные дни и являясь тем самым
Начать я решил с прочтения оригинала статьи на английском, а так же прочтения всех дискуссий на эту тему на различных форумах. Удивительно, но и там я не обнаружил ответа на свой вопрос – каков же реальный прирост в реальных приложениях. Зато обнаружил информацию о том, что в зависимости от версий компилятора, регистры в коде диспетчера процессора могут быть разными, а не только eax, ebx, ecx, edx и ebp, как например реализовано в патче intel_patch-ppro.pl. Могут так же применяться регистры esi и edi. Не являясь знатоком Perl и не имея его интерпритатора на компьютере, было решено набросать “на коленке” новый патч на Pascal’е (Virtual Pascal, но может быть запросто скомпилирован и Free Pascal). Сам патч и его исходный код можно найти здесь: icc_patch.rar
Вторая задача которая встала передо мной – а как собственно определить, скомпилирована ли та или иная программа с помощью Intel Compiler? Казалось бы, на помощь должны прийти программы типа PEiD. Что творится у них с сигнатурами я не знаю, но они выдают среднее расстояние от ларька с пивом до луны. PEiD меня заверяла, что тут же скомпилированная программа на Delphi с пустой формой и отрезанной Reallocation Table — написана на Borland C++ compiler, ну и тому подобные вещи. Конечно от этого варианта пришлось отказаться. Второе очевидное решение — перелопачивать все EXE-файлы на компьютере и искать в них то самое сравнение cmp eax, ‘Genu’ и тд. Но, такие проверки есть во многих программах, не имеющих отношение к компилятору Intel. По-этому пришлось набраться терпения и поискать в имеющихся на компьютере “тяжеловесных” программах приблизительный код, который уже показывали в комментариях к прошлой статье:
mov eax,[ebp][-0008]
cmp eax,0756E6547 ;"uneG" ; Проверка на "Genu"
jne not_intel ; если не равно, уходим на not_intel
mov eax,[ebp][-0010]
cmp eax,049656E69 ;"Ieni" ; Проверка на "ineI"
jne not_intel ; не равно - not_intel
mov eax,[ebp][-0014]
cmp eax,06C65746E ;"letn" ; Проверка на "ntel"
jne not_intel ; не равно - not_intel
mov edx,000000001 ; тот самый секретный байт
jmps next
not_intel:
xor edx,edx ; а здесь 0, для всех не-интел процов
next:
В итоге из всего набора софта, установленного на компьютере такая программа нашлось только одна, и о чудо – она оказалась бенчмарком! Ею оказалась CineBench R10 от Maxon
В ней прекрасно находятся вышеописанные участки кода. Без лишних слов пользуемся патчером на главном EXE программы, а также не забываем пропатчить все остальные библиотеки программы, которые к слову, имеют нестандартное расширение .CDL. Сам тест производит оценку скорости рендера картинки и, как итог, выдает некие “попугаи”. Теперь самое время взглянуть на график:
Было произведено по три запуска программы с патчем и без патча. Как видно на графике, результаты различаются. Но на самом деле, различаются весьма и весьма не значительно, график немного искажает представление. Например если брать время рендера, то на пропатченной программе оно составляет приблизительно 7 минут и 30-40 секунд, а на бенчмарке без патча 7 минут 50 секунд – 8 минут. Средняя разница составляет не больше 15-20 секунд.
Что же мы видим в итоге? Да, некоторая разница есть, но она столь ничтожна, что ей можно смело пренебречь. Если на больших (долгих по времени) задачах разница не превышает 20 секунд, то на простых (офисных) задачах ее не будет видно совсем.
С другой стороны важно не обманутся – ведь никто не мешал разработчикам данной программы все критические циклы написать на чистом ассемблере, тем самым оказаться независимыми от компилятора. И я подозреваю, что так оно и есть, поэтому полной картины с этой программой увидеть к сожалению не удалось.
Что же я выяснил за это время для себя? Первое – что программ, используемых повседневно на компьютере рядового пользователя и скомпилируемых с помощью Intel Compiler не много. Если быть точнее – мизирно мало. Второе – на чужих программах очень трудно оценивать прирост производительности, потому что не известно, как они устроены изнутри. В настоящее время идет медленное скачивание триальной версии компилятора, для проведения эксперимента непосредственно на собственных программах. Уже тогда можно будет делать хоть какие-то более-менее достоверные выводы.
Цель данной статьи не разжигание холиваров на тему Intel vs AMD, или подобных. Цель выяснить и понять, так ли уж сильно влияет тот самый пресловутый диспетчер процессора на время выполнения программ, как нам приподносится в оригинальной статье. И я хотел бы это сделать с твоей помощью, %username%.
