Многие программисты считают компилятор Intel лучшим оптимизирующим компилятором из имеющихся на рынке, и предпочитают использовать именно его для наиболее требовательных к производительности программ. Кроме того, Intel поставляет много сильно оптимизированных библиотек для различных технических и научных целей. Во многих случаях достойных альтернатив библиотекам Intel не существует.
К сожалению, программы, скомпилированные с помощью компилятора или библиотек Intel, работают значительно хуже на процессорах AMD и VIA. Причина в том, что для программного кода компилятор (или библиотека) может выдать несколько версий машинного кода, каждая из которых оптимизирована для определённого процессора и набора инструкций, например, SSE2, SSE3, и т.д. Система включает в себя функцию, которая определяет, на каком типе процессора она запущена и выбирает самую подходящую версию. Эта функция называется диспетчером процессора. Диспетчер процессора Intel проверяет не только набор инструкций, поддерживаемый процессором, но также идентификатор производителя процессора. Если идентификатор — строка «GenuineIntel», то выбирается наиболее оптимальный вариант кода. Но если процессор не от Intel, то в большинстве случаев будет выбран самый медленный из возможных вариантов, даже если процессор полностью совместим с лучшей версией.
Я, как и многие другие люди, жаловался на это поведение в течение многих лет, но Intel отказалась изменить свой диспетчер. Если бы Intel декларировала свой компилятор как совместимый только с процессорами Intel, то никаких жалоб, скорее всего, не было бы. Проблема в том, что они пытаются скрыть то, что они делают. Многие программисты считают, что компилятор Intel совместим с процессорами AMD. Это так, но в тайне от программиста он включает в программу предвзятый диспетчер процессора, который выбирает худший вариант кода при работе на процессорах всех компаний, кроме Intel. Если бы программисты знали этот факт, они скорее всего использовали бы другой компилятор. Кто хочет продавать программы, которые плохо работают на процессорах AMD?
Благодаря своему размеру, Intel может позволить себе вложить больше денег в свой компилятор, чем другие производители процессоров. Компилятор Intel продаётся относительно дёшево, даёт отличную производительность и имеет замечательную поддержку. Продажа такого компилятора, безусловно, сама по себе не является прибыльным бизнесом. Напротив, она очевидно является способом поддержки продаж процессоров Intel. Не было бы никакого смысла в добавлении в микропроцессоры новых наборов инструкций, если бы не было инструментов, позволяющих их использовать. AMD тоже производит компилятор, но текущая версия работает только под Linux, а версии под Windows пока нет.
Многие люди высказывали подозрение, что этот предвзятый диспетчер используется в распространённых программах для оценки производительности (ссылка ссылка). Это весьма серьёзный вопрос. Нам известно, что многие клиенты принимают решение о покупке на основе опубликованных результатов тестов, и предвзятые тесты дают несправедливое рыночное преимущество ценой в миллиарды долларов.
AMD неоднократно подавала в суд на Intel за недобросовестную конкуренцию, начиная по крайней мере с 2005 года, и в ноябре 2009 года было достигнуто мировое соглашение. Оно касается многих вопросов недобросовестной конкуренции, видимо, в том числе и компилятора Intel. Приведём цитату из него:
Это похоже на победу AMD. Если мы считаем, что «любой продукт Intel» это компиляторы и библиотеки Intel, «какая-либо третья сторона» это программисты, использующие эти компиляторы и библиотеки, а «искусственные нарушения производительности» это проверка идентификатора производителя диспетчером процессора, то эта договорённость обязывает Intel изменить диспетчер. Я обязательно проверю следующую версию компилятора и библиотек Intel, чтобы увидеть, сделают они это или же найдут лазейку в этом соглашении.
Интересно то, что история на этом не закончилась. Всего через месяц после соглашения между AMD и Intel, Федеральная Торговая Комиссия США (FTC) подала антимонопольную жалобу против Intel. Обвинения в жалобе FTC необычайно сильны:
Санкции, которых требует FTC, тоже заходят очень далеко:
Возможно, FTC решила, что договорённость между AMD и Intel не является справедливым и достаточным средством защиты против монопольного поведения корпорации Intel. Она возмещает убытки AMD, но ничего не делает для VIA, других производителей микропроцессоров, и клиентов, которые пострадали от недостаточной конкуренции и от «ущербного» программного обеспечения, произведённого с помощью компилятора Intel.
Когда я начал тестирование компилятора Intel несколько лет назад, я вскоре выяснил, что его диспетчер процессора предвзят. Ещё в январе 2007 года я пожаловался Intel на несправедливый диспетчер процессора. Я долго переписывался с инженерами Intel по этому вопросу. Они постоянно отрицали проблему, а я приводил всё больше доказательств. Они утверждали, что:
Звучит хорошо, но на самом деле диспетчер процессора не поддерживал в процессорах AMD даже SSE и SSE2, не говоря уж о более новых версиях, и не поддерживает их до сих пор (компилятор Intel версии 11.1.054). Позже я узнал, что и другие обратились в Intel с аналогичными жалобами и получили такие же бесполезные отговорки (ссылка ссылка).
Диспетчер процессоров Intel проверяет не только идентификатор производителя процессора и поддерживаемые наборы инструкций. Он проверяет и конкретные модели процессоров. Он не сможет распознать будущие процессоры Intel, номер семейства которых отличается от 6. Когда я спросил об этом инженеров Intel они ответили:
Иными словами, они утверждают, что они оптимизируют для конкретных моделей процессоров, а не для конкретных наборов инструкций. Если это правда, то это предоставляет Intel аргумент в защиту неполноценной поддержки процессоров AMD. Но отсюда также следует, что все разработчики программного обеспечения, использующие компилятор Intel, должны перекомпилировать свой код и распространять новые версии среди своих клиентов каждый раз, как на рынке появится новый процессор Intel. Это было три года назад. Что произойдёт, если я попытаюсь запустить программу, скомпилированную старой версией компилятора Intel, на новейшем процессоре Intel? Угадали: она по-прежнему выберет лучшую ветвь кода. О причине догадаться труднее: Intel манипулирует номерами семейств CPUID в новых процессорах так, чтобы старые компиляторы Intel считали их известными моделями. Я описал технические детали в другой статье.
Возможно, что сначала диспетчер процессора Intel был действительно призван оптимизировать только для известных моделей процессоров, без учёта будущих моделей. Если бы кто-то из моих студентов сдал такое решение, я бы счёл это серьёзным недостатком. Возможно, инженеры Intel обнаружили отсутствие поддержки для будущих процессоров слишком поздно, чтобы его исправить, и были вынуждены разработать следующее поколение процессоров таким образом, чтобы существующее программное обеспечение Intel принимало их за известные модели.
После того, как Intel наотрез отказалась изменить свой диспетчер, я решил, что самым действенным способом заставить их передумать будет распространение информации об этой проблеме. Я связался с несколькими журналами, но никто не хотел писать о ней. Жаль, но не удивительно, учитывая, что все они зависят от размещения рекламы Intel. Единственным местом, где это удалось осветить, было моё собственное руководство по оптимизации программ, где я подробно описал ситуацию и указал способ замены несправедливого диспетчера. Я не знаю, почему AMD не распространило эту информацию. Возможно, они были обязаны хранить молчание о ходе судебного разбирательства? А как насчёт VIA и Centaur?
На данный момент мы не знаем, выпустит ли Intel новый компилятор и новые библиотеки, которые не проверяют идентификатор производителя, а если выпустит, то когда. Но вот что мы можем сделать до этого времени:
Моё обсуждение на форуме Aceshardware, 2007.
Обсуждение на Форуме разработчиков
AMD, 2008.
Моё обсуждение на AMDzone 2009.
Обсуждение в группе
comp.arch, 2004.
Жалоба в Intel, обсуждение в slashdot.org, 2004.
Жалоба Mark Mackey в Intel, 2005.
Доказана несправедливость теста PCMark 2005, Arstechnica.
Свидетельские показания
John Oram относительно тестирующей организации BAPCo.
Комментарий на AMD Developer Central, 2005.
AMD подаёт иск, 2005.
Антимонопольная жалоба AMD, 2005.
Мировое соглашение между AMD и Intel, 2009.
Жалоба FTC, 2009.
Технические подробности в моём руководстве по оптимизации C++.
Обсуждение на форуме XtremeSystems.
К сожалению, программы, скомпилированные с помощью компилятора или библиотек Intel, работают значительно хуже на процессорах AMD и VIA. Причина в том, что для программного кода компилятор (или библиотека) может выдать несколько версий машинного кода, каждая из которых оптимизирована для определённого процессора и набора инструкций, например, SSE2, SSE3, и т.д. Система включает в себя функцию, которая определяет, на каком типе процессора она запущена и выбирает самую подходящую версию. Эта функция называется диспетчером процессора. Диспетчер процессора Intel проверяет не только набор инструкций, поддерживаемый процессором, но также идентификатор производителя процессора. Если идентификатор — строка «GenuineIntel», то выбирается наиболее оптимальный вариант кода. Но если процессор не от Intel, то в большинстве случаев будет выбран самый медленный из возможных вариантов, даже если процессор полностью совместим с лучшей версией.
Я, как и многие другие люди, жаловался на это поведение в течение многих лет, но Intel отказалась изменить свой диспетчер. Если бы Intel декларировала свой компилятор как совместимый только с процессорами Intel, то никаких жалоб, скорее всего, не было бы. Проблема в том, что они пытаются скрыть то, что они делают. Многие программисты считают, что компилятор Intel совместим с процессорами AMD. Это так, но в тайне от программиста он включает в программу предвзятый диспетчер процессора, который выбирает худший вариант кода при работе на процессорах всех компаний, кроме Intel. Если бы программисты знали этот факт, они скорее всего использовали бы другой компилятор. Кто хочет продавать программы, которые плохо работают на процессорах AMD?
Благодаря своему размеру, Intel может позволить себе вложить больше денег в свой компилятор, чем другие производители процессоров. Компилятор Intel продаётся относительно дёшево, даёт отличную производительность и имеет замечательную поддержку. Продажа такого компилятора, безусловно, сама по себе не является прибыльным бизнесом. Напротив, она очевидно является способом поддержки продаж процессоров Intel. Не было бы никакого смысла в добавлении в микропроцессоры новых наборов инструкций, если бы не было инструментов, позволяющих их использовать. AMD тоже производит компилятор, но текущая версия работает только под Linux, а версии под Windows пока нет.
Многие люди высказывали подозрение, что этот предвзятый диспетчер используется в распространённых программах для оценки производительности (ссылка ссылка). Это весьма серьёзный вопрос. Нам известно, что многие клиенты принимают решение о покупке на основе опубликованных результатов тестов, и предвзятые тесты дают несправедливое рыночное преимущество ценой в миллиарды долларов.
Правовая битва
AMD неоднократно подавала в суд на Intel за недобросовестную конкуренцию, начиная по крайней мере с 2005 года, и в ноябре 2009 года было достигнуто мировое соглашение. Оно касается многих вопросов недобросовестной конкуренции, видимо, в том числе и компилятора Intel. Приведём цитату из него:
2.3 Технические практики
Intel не имеет права включать какие-либо Искусственные Нарушения Производительности в любые продукты Intel или требовать от какой-либо третьей стороны включать Искусственные Нарушения Производительности в продукт этой третьей стороны. В этом разделе 2.3 «Искусственным Нарушением Производительности» называется позитивное инженерное действие Intel или действие Intel в сфере дизайна (но не бездействие), которое (i) ухудшает производительность или работу Указанного Продукта AMD, (ii) не является следствием Улучшения Продукта Intel и (iii) произведено намеренно с целью ухудшить производительность или работу Указанного Продукта AMD. Для целей настоящего раздела 2.3, «Улучшение Продукта» означает любую выгоду, преимущество или улучшение в плане производительности, эксплуатации, цены, себестоимости, технологичности, надёжности, совместимости или способности работать или улучшать работу другого продукта.
Ни при каких обстоятельствах этот раздел 2.3 не налагает, и не может быть истолкован, как налагающий, на Intel никаких обязательств (i) предпринимать любые действия, которые произведут Улучшение Продукта для какого-либо продукта AMD или третьих сторон, независимо от того, используется ли этот продукт AMD или третьих сторон отдельно или в комбинации с любым другим продуктом, (ii) оптимизировать любые продукты для Указанных Продуктов AMD или (iii) предоставить AMD любую техническую информацию, документы или ноу-хау.
Это похоже на победу AMD. Если мы считаем, что «любой продукт Intel» это компиляторы и библиотеки Intel, «какая-либо третья сторона» это программисты, использующие эти компиляторы и библиотеки, а «искусственные нарушения производительности» это проверка идентификатора производителя диспетчером процессора, то эта договорённость обязывает Intel изменить диспетчер. Я обязательно проверю следующую версию компилятора и библиотек Intel, чтобы увидеть, сделают они это или же найдут лазейку в этом соглашении.
Интересно то, что история на этом не закончилась. Всего через месяц после соглашения между AMD и Intel, Федеральная Торговая Комиссия США (FTC) подала антимонопольную жалобу против Intel. Обвинения в жалобе FTC необычайно сильны:
Intel попыталась подорвать преимущество x86-процессоров других компаний в производительности по сравнению с x86-процессорами Intel, когда она переработала и распространила такие программные продукты, как компиляторы и библиотеки.
[...] [...]
У общественности, OEM-производителей, независимых поставщиков ПО, и тестирующих организаций создалось впечатление, что меньшая производительность процессоров других компаний на приложениях, скомпилированных с использованием продуктов Intel, была вызвана процессором, а не программным обеспечением Intel. Intel не раскрыла последствия изменений, которые она производила в своём программном обеспечении, начиная с или около 2003, своим клиентам и общественности. Intel также распространяла ложную или вводящую в заблуждение документацию о своих компиляторах и библиотеках. Intel заверяла независимых поставщиков ПО, OEM-производителей, тестирующие организации и общественность, что программы изначально работают на процессорах Intel быстрее, чем на процессорах конкурентов. На самом же деле, многие различия обусловлены в основном или полностью программным обеспечением Intel. Вводящие в заблуждение или ложные заявления и умолчания Intel о работе их программного обеспечения учитывались независимыми поставщиками ПО, OEM-производителями, тестирующими организациями и общественностью при приобретении и использовании ими процессоров. Таким образом, заверения корпорации Intel, что программы изначально показывают лучшие результаты на процессорах Intel, чем на процессорах конкурентов были и являются ложными или вводящими в заблуждение. Отказ Intel раскрыть, что эти различия обусловлены главным образом программным обеспечением Intel, учитывая сделанные заверения, было и является мошеннической практикой. Кроме того, эти искажения и упущения могли нанести вред репутации других производителей x86-процессоров, и нанесли вред конкуренции.
[...] [...]
Некоторые независимые поставщики ПО запрашивали у Intel информацию относительно видимого различия в быстродействии одинаковых программ при запуске на процессорах Intel и других компаний. В ответ на такие просьбы, неоднократно, Intel представляла в ложном свете, прямо или косвенно, источник этой проблемы и возможность её разрешения.
[...] [...]
Изменения программного обеспечения Intel замедлило быстродействие x86-процессоров других производителей без всякой достаточно оправданной технологической выгоды. Обманчивое поведение Intel лишило потребителей возможности осознанного выбора между чипами Intel и конкурентов, а также между программным обеспечением Intel Software и конкурентов, и привело к повышению стоимости конкуренции на соответствующих рынках процессоров. Потери производительности из-за компилятора и библиотек Intel также причинили непосредственный вред тем потребителям, которые использовали x86-процессоры других компаний, кроме Intel.
Санкции, которых требует FTC, тоже заходят очень далеко:
В отношении тех клиентов Intel, которые, как указано в жалобе, приобрели у Intel компилятор, который наносил или наносит ущерб фактической или кажущейся производительности микропроцессоров, произведённых не компанией Intel («Ущербный Компилятор»), требуется, чтобы:
- Intel предоставила им, без дополнительной оплаты, замену компилятора, которая не является Ущербным Компилятором;
- Intel возместила им расходы на перекомпиляцию программного обеспечения, которое они скомпилировали с использованием Ущербного Компилятора и замены, а также распространения среди их клиентов, перекомпилированного программного обеспечения; и
- Intel сделала публичное уведомление и предупреждение, таким образом, чтобы обеспечить вероятность передачи лицам, которые приобрели программное обеспечение, скомпилированное на Ущербных Компиляторах, приобретённых у Intel, о возможной необходимости замены этого программного обеспечения.
Возможно, FTC решила, что договорённость между AMD и Intel не является справедливым и достаточным средством защиты против монопольного поведения корпорации Intel. Она возмещает убытки AMD, но ничего не делает для VIA, других производителей микропроцессоров, и клиентов, которые пострадали от недостаточной конкуренции и от «ущербного» программного обеспечения, произведённого с помощью компилятора Intel.
Мои собственные выводы
Когда я начал тестирование компилятора Intel несколько лет назад, я вскоре выяснил, что его диспетчер процессора предвзят. Ещё в январе 2007 года я пожаловался Intel на несправедливый диспетчер процессора. Я долго переписывался с инженерами Intel по этому вопросу. Они постоянно отрицали проблему, а я приводил всё больше доказательств. Они утверждали, что:
Диспетчер процессора, в сочетании с оптимизациями, предназначен для оптимизации работы на всех процессорах Intel и AMD, чтобы дать лучшие возможные результаты. Это наша цель и мы считаем, что мы её достигли, за одним исключением. Это исключение — отсутствие поддержки SSE3 на процессорах AMD в версиях 9.x нашего компилятора, связанное со сроками выпуска (наш компилятор был разработан до того, как AMD сделала поддержку SSE3). Следующая версия компилятора 10.x, бета-тест которой начнётся в этом квартале, а окончательная версия будет выпущена примерно в середине этого года, позволит решить эту проблему, поскольку у нас хватило времени приспособиться к новым процессорам AMD.
Звучит хорошо, но на самом деле диспетчер процессора не поддерживал в процессорах AMD даже SSE и SSE2, не говоря уж о более новых версиях, и не поддерживает их до сих пор (компилятор Intel версии 11.1.054). Позже я узнал, что и другие обратились в Intel с аналогичными жалобами и получили такие же бесполезные отговорки (ссылка ссылка).
Диспетчер процессоров Intel проверяет не только идентификатор производителя процессора и поддерживаемые наборы инструкций. Он проверяет и конкретные модели процессоров. Он не сможет распознать будущие процессоры Intel, номер семейства которых отличается от 6. Когда я спросил об этом инженеров Intel они ответили:
Вы упомянули, что мы не может поддерживать будущие процессоры Intel с обозначениями семейства, отличными от '6', без обновления компилятора. Да, это верно и преднамеренно. Нам необходима высокая степень уверенности, что программа, выданная нашим компилятором, не перестанет работать в будущем. Таким образом, мы не можем предполагать чего-либо о будущих процессорах Intel, AMD или других производителей. Вы заметили, что мы могли бы действовать более агрессивно. Мы считаем, что это было бы неразумно по отношению к нашим клиентам, которые хотят быть уверены, что их код (скомпилированный с нашим компилятором) продолжит работать в далёком будущем. Предложенные Вами методы, хотя они и выглядят разумными, недостаточно консервативны для нашего чрезвычайно оптимизирующего компилятора. Наш опыт приводит к консервативной выдаче кода. После того, как мы проверим функциональность с новыми процессорами Intel и AMD, мы обновляем компилятор. Это означает, что существует некоторое отставание с поддержкой новых процессоров в официальной версии компилятора.
Иными словами, они утверждают, что они оптимизируют для конкретных моделей процессоров, а не для конкретных наборов инструкций. Если это правда, то это предоставляет Intel аргумент в защиту неполноценной поддержки процессоров AMD. Но отсюда также следует, что все разработчики программного обеспечения, использующие компилятор Intel, должны перекомпилировать свой код и распространять новые версии среди своих клиентов каждый раз, как на рынке появится новый процессор Intel. Это было три года назад. Что произойдёт, если я попытаюсь запустить программу, скомпилированную старой версией компилятора Intel, на новейшем процессоре Intel? Угадали: она по-прежнему выберет лучшую ветвь кода. О причине догадаться труднее: Intel манипулирует номерами семейств CPUID в новых процессорах так, чтобы старые компиляторы Intel считали их известными моделями. Я описал технические детали в другой статье.
Возможно, что сначала диспетчер процессора Intel был действительно призван оптимизировать только для известных моделей процессоров, без учёта будущих моделей. Если бы кто-то из моих студентов сдал такое решение, я бы счёл это серьёзным недостатком. Возможно, инженеры Intel обнаружили отсутствие поддержки для будущих процессоров слишком поздно, чтобы его исправить, и были вынуждены разработать следующее поколение процессоров таким образом, чтобы существующее программное обеспечение Intel принимало их за известные модели.
После того, как Intel наотрез отказалась изменить свой диспетчер, я решил, что самым действенным способом заставить их передумать будет распространение информации об этой проблеме. Я связался с несколькими журналами, но никто не хотел писать о ней. Жаль, но не удивительно, учитывая, что все они зависят от размещения рекламы Intel. Единственным местом, где это удалось осветить, было моё собственное руководство по оптимизации программ, где я подробно описал ситуацию и указал способ замены несправедливого диспетчера. Я не знаю, почему AMD не распространило эту информацию. Возможно, они были обязаны хранить молчание о ходе судебного разбирательства? А как насчёт VIA и Centaur?
Временные решения
На данный момент мы не знаем, выпустит ли Intel новый компилятор и новые библиотеки, которые не проверяют идентификатор производителя, а если выпустит, то когда. Но вот что мы можем сделать до этого времени:
- Используйте другой компилятор. Согласно моим тестам, компилятор Gnu для Linux оптимизирует производительность на уровне, аналогичном компилятору Intel, но библиотека функций Gnu (Glibc) хуже, чем у Intel. Все остальные компиляторы показывают более низкую производительность. Под Windows компиляторов с производительностью, близкой к компилятору Intel, не существует.
- Используйте компилятор Intel и замените диспетчер. В моём руководстве по C++ я опубликовал код для альтернативных диспетчеров процессора для компиляторов и библиотек функций Intel и инструкции, как их встроить. Конечно, они используют недокументированные подробности об устройстве программного обеспечения Intel. Это изменение может во многих случаях значительно повысить производительность на не-Intel процессорах.
- Не доверяйте ни одному тесту производительности, если его исходный код закрыт или не использует нейтральный компилятор, например Gnu или Microsoft.
- Инструкции виртуализации AMD позволяют изменить CPUID процессоров AMD. Я надеюсь, что кто-то сделает программу для этого. Это позволит легко проверить, справедлив ли любой данный тест, и улучшить производительность программного обеспечения, скомпилированного компилятором Intel, на процессорах AMD.
Ссылки
Моё обсуждение на форуме Aceshardware, 2007.
Обсуждение на Форуме разработчиков
AMD, 2008.
Моё обсуждение на AMDzone 2009.
Обсуждение в группе
comp.arch, 2004.
Жалоба в Intel, обсуждение в slashdot.org, 2004.
Жалоба Mark Mackey в Intel, 2005.
Доказана несправедливость теста PCMark 2005, Arstechnica.
Свидетельские показания
John Oram относительно тестирующей организации BAPCo.
Комментарий на AMD Developer Central, 2005.
AMD подаёт иск, 2005.
Антимонопольная жалоба AMD, 2005.
Мировое соглашение между AMD и Intel, 2009.
Жалоба FTC, 2009.
Технические подробности в моём руководстве по оптимизации C++.
Обсуждение на форуме XtremeSystems.
