Недобросовестная конкуренция 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 этой технологии имеет такую возможность, что было продемонстрировано на небольшом примере — но до сих пор никто не взялся сделать полноценную программу для подмены. Этот способ хорош тем, что его могут использовать в т. ч. и конечные пользователи, не имеющие доступа к исходным кодам — а также журналисты, страстно желающие написать сенсационно-разгромную статью.
Ваша оценка: Нет Средняя оценка: 5 (2 votes)
9
comrade

Меня лично в этой ситуации радует то, что по хорошим ли, плохим ли соображениям, но ведущие корпорации делают свои лучшие компилляторы для линукса бесплатными!
При том, что и GCC, и, например, GFortran - отличные и постоянно прогрессирующие средства разработки!

Правда раздолбаи - АМД - свой компилятор выложили только в виде гигабайта исходных кодов.
Его приведение в чувство должно быть первым упражнением для программиста низкой или средней квалификации?:))
И почему это он так мало распространён! ;-)
"Сделали бы нам красиво", и интел со своим компилятором тоже бы так не резвилось, если бы АМД'шный всем показал, что "у него больше"!

_______________

И да, по справедливости нужен какой-то патчик, чтобы интела накалывать! :-)

А то я то радуюсь, что они такие добрые ((-;

Ваша оценка: Нет
11
pomodor

А зачем он нужен этот интеловский компилятор, если им все равно мало что собирается из того, что есть под Linux? Кстати интересен момент, что самой сильной стороной icc — оптимизацией — занимались, кажется, наши программеры из Питера.

Ваша оценка: Нет
9
comrade

А вычисления? Он самый быстрый код делает, обычно!
Да и хорошо, когда есть хотя бы пара компиляторов, чтобы программу проверить и там, и там...
__________________

В данный момент всё-таки АМДшный пытаюсь завести (компилируется...:-)
Для тупых убунтоидов, вроде меня, они отдельную пошаговую инструкцию сделали! :-)))))

________________
Не, даже с инструкцией не осилил! :((
Что-то пошло не так...

Видимо до другого раза...
Сидел бы на АМД, стал бы разбираться, но у меня интеловский процессор, и так что пока не судьба АМД Опен64 попользоваться.

Ваша оценка: Нет
11
pomodor

Там, где нужны быстрые вычисления все равно ручная оптимизация на ассемблере проводится. Имхо, больше игрушка, нежели что-то полезное. Разве что пригодится в каких-нибудь очень специализированных проектах. Ученым какую-нибудь орбиту астероида вычислять, например. :) В видеокодеках может быть пару процентов прироста производительности будет.

Ваша оценка: Нет
9
comrade

Ручная оптимизация на ассемблере несколько снижает переносимость программ "в пространстве и времени";-)

И это ещё уметь надо... Си с фортраном, как инструменты, попроще всё-же.

Ну да, именно для научных расчётов, и исследований по шифрованию, например.

Хотя у меня интеловский компилятор был основным много лет, когда я в виндовсе жил. Но теперь, при разработке, GCC и GFortran, а интеловский в самом конце использую, для проверки, и посмотреть - насколько более быстрый код он сделает.

Ваша оценка: Нет
11
pomodor

А узкоспециализированным высокопроизводительным приложениям особая кросс-платформенность и не требуется.

посмотреть - насколько более быстрый код он сделает

Где-то видел сравнение двух bzip2, откомпилированных gcc и icc. Что-то около 20% самый хороший результат.

Ваша оценка: Нет
9
comrade

Ну, приложение, заточенное под конкретную задачу и платформу - это одно, а специализированный алгоритм, который однако, как инструмент, может быть использован много где - это другое.

Как раз для "только здесь и сейчас" можно сделать "как-нибудь", а много где используемый инструмент должен быть и универсальным, и быстрым.

Ваша оценка: Нет
11
pomodor

Вот тут народ бьется над задачей сборки ядра Intel-компилятором. Страшно представить с какой скоростью будет летать Linux, когда все получится. Пользователь еще не успел ввести данные, а результаты вычислений уже готовы.

Ваша оценка: Нет
9
comrade

"Ага! Сказали суровые сибирские лесорубы." ;-)))

Ваша оценка: Нет
11
Беляев_Николай

хорошая статейка. спасибо.

Ваша оценка: Нет Средняя оценка: 5 (3 votes)
Отправить комментарий
КАПЧА
Вы человек? Подсказка: зарегистрируйтесь, чтобы этот вопрос больше никогда не возникал. Кстати, анонимные ссылки запрещены.
CAPTCHA на основе изображений
Enter the characters shown in the image.
Linux I класса
Linux II класса
Linux III класса
Счетчики
  • Самый популярный сайт о Linux и Windows 10
О Либератуме

Liberatum — это новости мира дистрибутивов Linux, обзоры, сборки, блоги, а также лучший сайт об Ubuntu*.