Недобросовестная конкуренция Intel

Жили-были две компании. Т. е. их, конкурентов, конечно, больше, но заклятые — именно Intel и AMD. Причём, так уж получилось: Intel, как правило, что-то новое придумывает и внедряет первой, а AMD внедряет второй, но дешевле, отбивая кусок рынка.

Intel это не нравится, и она начинает действовать против конкурента не только обычными способами (выпуская очередной новый чип или снижая цены в свою очередь), но и другими, из-за которых потом AMD подаёт на Intel в суд по обвинению в нечестной конкуренции и нарушении антимонопольных законов. Нет необходимости описывать все перипетии этих дел, длящихся с переменным успехом для обеих сторон с середины 80-х (считая также и встречные иски). Однако среди арсенала Intel есть один приём, который нам особенно интересен.

Компилятор Intel

Многие программисты считают компиляторы Intel лучшими в т.ч. за оптимизацию кода, используя их для требовательных к скорости программ. Intel также поставляет множество оптимизированных функциональных библиотек для различных профессиональных применений. Во многих случаях никаких сходных по скорости альтернатив им нет. Но те же программисты заметили, что компиляторы и библиотеки Intel работают зачастую подозрительно медленно на ЦП производства других компаний. Всё дело в том, что в генерируемом коде (в случае библиотек — в написанном вручную) есть несколько версий наиболее критичных участков, оптимизированных для конкретной архитектуры или набора команд (чаще всего из линейки SSEx). Также в коде есть функция определения типа ЦП (на котором запущен код), чтобы выбрать верную ветвь — диспетчер ЦП (не путать с планировщиком — частью конвейера, которую также иногда называют диспетчером). Суть проблемы в том, что интеловский диспетчер проверяет не только поддержку наборов команд, но и строку с названием процессора. И в случае, если производитель указан не как Intel, диспетчер выбирает код, обеспечивающий максимальную совместимость в ущерб скорости — даже если конкретный ЦП поддерживает все нужные команды.

Ситуация не нова и продолжается годами, но Intel ничего не меняет, хотя компиляторы фирмы не рекламируются как оптимально работающие только для её собственных ЦП. В результате программист и не подозревает, что зачастую пользователь «неправильных процессоров» недополучает производительности, но стоит только тому пересесть на одобренные свыше ЦП — как всё сразу ускоряется. Если бы об этом знали все программисты — возможно, некоторые из них стали бы оптимизировать свои программы вручную или перешли бы на использование других компиляторов и библиотек. Более того, Intel открыто пишет в документации, что если процессор возвращает название, не совпадающее с «Intel», то «не стоит полагаться на данную [в тексте] интерпретацию остальных полей», включая список поддерживаемых наборов команд. В выпущенной в январе 2010 г. официальной статье об использовании библиотеки Intel Performance Primitives для ЦП AMD отмечено, что последняя версия IPP честно оптимизирует код и тут — но не указано, что в нескольких других библиотеках это не происходит.

Intel специально ставит низкие (иногда даже нулевые) цены на свои инструменты для программирования, а поддержку им даёт на высоком уровне. Т. е. сама по себе продажа компиляторов, скорее всего, убыточна, но она улучшает продажи ЦП. Добавлять новые команды в процессор без поддержки на уровне компиляторов почти бессмысленно — кодируют на ассемблере сегодня крайне редко. Что касается AMD — она также делает свой компилятор Open64, но только для Linux.

У всех на слуху «полюбовное» соглашение между Intel и AMD в ноябре 2009 г., улаживающее иск последней, за что Intel выплатила круглую сумму. Менее известно, что AMD также потребовала подписать соглашение об урегулировании, где перечислены многие нечестные приёмы конкуренции, которые Intel обещает более не применять — среди них и «подмена ЦП». Документ обязывает Intel сменить код диспетчера на нейтральный — надо полагать, со следующей версии компилятора… Через месяц Федеральная Торговая Комиссия США (FTC) подала антимонопольную жалобу против Intel с резкими обвинениями на той же почве подмены путей кода, даже введя собственный термин «Defective compiler» для описания творения Intel. FTC требует, чтобы Intel бесплатно выпустила замену текущему компилятору или заплатку к его «дефектам», скомпенсировала стоимость перекомпиляции и распространения исправленных новым инструментом версий программ и объявила потребителям о замене старых версий на новые.

Пока шли прения, прошёл год, Intel выпустила новую версию своей популярной библиотеки MKL (Math Kernel Library) v10.3 — а диспетчер ЦП практически не поменялся. Скалярные, векторные и 64-битные версии функций всё ещё используют неоптимизированные пути на «некошерных» ЦП. Более того, многие функции теперь имеют новую ветку для грядущего набора AVX — и тоже только для Intel. Т. е. в процессорах Sandy Bridge такой код работать будет, а в AMD Bulldozer, выходящих в это же время и также готовых исполнять AVX, — нет. Впрочем, появилась новая ветвь специально для не-интеловских ЦП с SSE2 — и для многих функций она работает медленнее, чем SSE2-код для Intel. Причём эта ветвь существует лишь в 32-битных версиях MKL.
Смелый рыцарь

Читатель спросит — а откуда всё это известно? Тут на сцену выходит опытный программист и исследователь Агнер Фог (Agner Fog), известный в Сети своими учебниками по оптимизации и микроархитектурам, бесплатно выложенными на его сайте. В 2007 г. Фог ознакомил Intel с результатами своих исследований компиляторов с вышеуказанными выводами. Последовала долгая переписка, в которой компания отрицала наличие проблемы, хотя Фог продолжал аргументированно подтверждать её наличие. Другие специалисты также жаловались на те же проблемы и получили похожие ответы. Ситуация с компилятором не изменилась даже в версии 11.1.054, вышедшей сразу после подписания соглашения с AMD.

Как ни странно, Intel заявила в переписке, что намеренно оптимизирует не под наборы команд, а под конкретные архитектуры ЦП, чтобы оптимизация была лучше, что якобы отклоняет обвинения в нечестности (глупо требовать оптимизации под чужие ЦП). Но это также означает, что выход очередного нового ЦП самой Intel, даже если он поддерживает те же команды, что и старый, потребует перекомпиляции программ новой версией компилятора, иначе старый диспетчер, запущенный на новом ЦП, не узнает даже родного производителя. Это если Intel не лукавит… Фог решил проверить и запустил программу, сделанную старой версией компилятора Intel, на новом, якобы неизвестном тому ЦП той же Intel. Как и следовало ожидать, всё заработало идеально. Причина — Intel хитро манипулирует цифрами «семейства» на новых ЦП так, чтобы они выглядели знакомо для старых программ, в частности, добавив «расширенное семейство» и «расширенную модель».

После того, как Intel отказалась как-либо решать проблему, Фог решил, что лучшая тактика — публичность. Но связавшись с несколькими IT-журналами, он никого не заинтересовал. Любители конспирологии, конечно, немедленно построят стройную теорию о том, как сами знаете кто подкупил сами знаете кого — но истина, возможно, куда банальнее: слишком уж узкоспециальная тема для среднестатистического читателя. Но то читатели, а вот почему AMD, коммерчески страдающая от этой ситуации больше всего, до сих пор молчит даже у себя на сайте? Может быть, она решила, что это как-то повредит утряске иска против Intel? А VIA/Centaur?..

Тем временем, Фог продолжал бомбить фактами (ссылки есть в его блоге). Например, согласно сайту CNET, Skype на некоторое время договорился с Intel ограничить функциональность своей программы на компьютерах с альтернативными ЦП, но позже ограничение было снято…

Не используйте компиляторы Intel

В общем, кто виноват — ясно, теперь — что делать? Фог предлагает три варианта:

• Не использовать компилятор Intel. Компилятор GNU под Linux оптимизирует не хуже, чем Intel, но функциональная библиотека glibc несколько недоработана. Что касается инструментов для Windows — тут никаких альтернатив нет.
• Использовать компилятор Intel, вручную редактируя диспетчер. В учебнике по C++ Фог предоставил «честный» код и инструкции по встраиванию его в программы — однако данный способ завязан на недокументированных особенностях компиляторов Intel, которые меняются от версии к версии.
• Сменить в процессоре возвращаемую строку производителя с помощью команд виртуализации. Известно, что версия AMD этой технологии имеет такую возможность, что было продемонстрировано на небольшом примере — но до сих пор никто не взялся сделать полноценную программу для подмены. Этот способ хорош тем, что его могут использовать в т. ч. и конечные пользователи, не имеющие доступа к исходным кодам — а также журналисты, страстно желающие написать сенсационно-разгромную статью.