Сколько стоит беспокоиться о том, что компилятор Intel C ++ генерирует неоптимальный код для AMD?

Question

Мы всегда были в магазине Intel. Все разработчики используют машины Intel, рекомендуемой платформой для конечных пользователей является Intel, и если конечные пользователи хотят работать на AMD, это их забота. Возможно, в тестовом отделе где-то была машина AMD, чтобы проверить, что мы не отправили ничего полностью сломанного, но это было все.

До тех пор, пока несколько лет назад мы только использовали компилятор MSVC, и, поскольку он на самом деле не предлагает много опций настройки процессора сверх уровня SSE, никто не слишком беспокоился о том, может ли код отдать предпочтение одному поставщику x86 над другим. Однако в последнее время мы часто используем компилятор Intel. Наш материал определенно получает от этого значительные преимущества в производительности (на нашем оборудовании Intel), а его возможности векторизации означают, что меньше нужно переходить на asm / intrinsics. Однако люди начинают немного нервничать из-за того, что компилятор Intel на самом деле не очень хорошо справляется с аппаратным обеспечением AMD. Конечно, если вы войдете в библиотеки Intel CRT или IPP, вы увидите множество запросов cpuid, по-видимому, для установки таблиц переходов для оптимизированных функций. Похоже, вряд ли Intel пойдет на все, чтобы сделать что-то хорошее для чипов AMD.

Может ли кто-нибудь с каким-либо опытом в этой области прокомментировать, имеет ли это большое значение или нет на практике? (На самом деле нам еще не приходилось тестировать производительность на AMD).

Обновление 2010-01-04 : Что ж, необходимость поддержки AMD никогда не становилась настолько конкретной, чтобы я сам мог провести какое-либо тестирование. Есть несколько интересных материалов по этому вопросу здесь , здесь и здесь хотя.

Обновление 2010-08-09 : Похоже, в соглашении Intel-FTC есть, что сказать по этому вопросу - см. Раздел «Компиляторы и грязные уловки» этой статьи .

Answer 1

Купите коробку AMD и запустите ее на этом. Это кажется единственной ответственной вещью, а не доверять незнакомцам в Интернете;)

Кроме того, я полагаю, что часть иска AMD против Intel основана на утверждении, что компилятор Intel специально создает код, который неэффективно работает на процессорах AMD. Я не знаю, правда это или нет, но AMD, похоже, верит в это.

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

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

Answer 2

Что мы видели, так это то, что где компилятор Intel должен выбирать во время выполнения доступный набор команд, если он не распознает ЦП Intel, он идет в их «стандартном» коде (который, как вы можете ожидать, может не быть оптимальным).

Обратите внимание, что даже если я использовал слово «компилятор» выше, это в основном происходит в их поставляемых (предварительно скомпилированных) библиотеках и встроенных функциях, которые проверяют набор команд и вызывают лучший код.

Answer 3

Я, конечно, констатирую очевидное: если производительность имеет решающее значение для вашего приложения, то вам лучше провести некоторое тестирование - на всех комбинациях аппаратного обеспечения / компилятора. Там нет никаких гарантий. Как посторонние, мы можем дать вам только наши догадки / предубеждения. Ваше программное обеспечение может иметь уникальные характеристики, которые отличаются от того, что мы видели.

Мой опыт:

Раньше я работал в Intel и разрабатывал собственное (C ++) приложение, где производительность была критической. Мы попытались использовать компилятор Intel C ++, и он всегда при выполнении gcc - даже после запуска профиля, перекомпиляции с использованием профилированной информации (которую якобы использует icc для оптимизации) и повторного запуска на том же наборе данных ( это было в 2005-2007 годах, сейчас все может быть иначе). Итак, исходя из моего опыта, вы можете попробовать gcc (в дополнение к icc и MSVC), возможно, вы получите лучшую производительность таким образом и обойдете вопрос. Переключать компиляторы не должно быть слишком сложно (если ваш процесс сборки оправдан).

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

Но вернемся к вопросу о том, предназначен ли компилятор Intel специально для оборудования AMD, чтобы он работал медленно. Я сомневаюсь, что Intel беспокоится об этом. Вполне возможно, что некоторые оптимизации, использующие знания внутренних компонентов архитектуры процессоров Intel или наборов микросхем, могут работать медленнее на оборудовании AMD, но я сомневаюсь, что они специально нацелены на оборудование AMD.

Answer 4

В то время, когда этот поток был запущен, Microsoft C ++ по умолчанию генерировал код, который в некоторых случаях был хорош для AMD, а для Intel - плохим. Их более поздние компиляторы по умолчанию используют опцию смешивания, которая подходит для обоих, особенно после того, как процессоры обеих марок исправили свои специфические ошибки производительности. Когда я впервые работал в Intel, их компиляторы зарезервировали некоторые оптимизации для настроек архитектуры, специфичных для Intel. Я полагаю, что это могло быть темой некоторых заявлений FTC, хотя это не подошло мне за 10 часов свидетельских показаний, и практика уже выходила из-за сближения требований оптимизации между современными моделями ЦП и необходимость более продуктивного использования времени разработки компилятора. Если вы использовали один из этих устаревших компиляторов на новейшем процессоре Intel, вы можете увидеть некоторые из тех же недостатков производительности.

Answer 5

Извините, если вы нажали мою общую кнопку.

Это относится к теме низкоуровневой оптимизации, поэтому это имеет значение только для кода, в котором 1) счетчик программы тратит много времени и 2) фактически видит компилятор. Например, если компьютер проводит большую часть своего времени в библиотечных подпрограммах, которые вы не компилируете, это не должно иметь большого значения.

Независимо от того, выполнены ли условия 1 и 2, вот мой опыт оптимизации:

Выполнено несколько итераций выборки и исправления. В каждом из них выявляется проблема, и чаще всего речь идет не о том, где находится счетчик программ. Скорее, на средних уровнях стека вызовов существуют вызовы функций, которые, поскольку производительность имеет первостепенное значение, могут быть заменены. Чтобы быстро их найти, я делаю это.

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

Программа теперь может быть во много раз быстрее, чем это было с самого начала. Я никогда не видел ни одной программы хорошего размера, какой бы тщательной она ни была написана, которая не смогла бы извлечь выгоду из этого процесса. Если процесс еще не завершен, не следует предполагать, что низкоуровневая оптимизация - единственный способ ускорить выполнение программы.

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

Answer 6

Я непосредственно столкнулся с целенаправленным падением технологий, когда поставщик пытался помешать продукту Lotus выйти на рынок до его предложения. Работающая технология была доступна, но Lotus было запрещено ее использовать. Ах, хорошо ...

Несколько лет назад появились блоги, в которых показывалось, что исправление одного байта в компиляторе Intel приводит к тому, что он генерирует «оптимальный» код, который не был поврежден при использовании в AMD. Я не искал эти записи в блогах годами.

Я склонен полагать, что такое конкурентное поведение продолжается. У меня нет других доказательств, чтобы предложить.

Answer 7

Бесполезно волноваться, если ты не можешь действовать. Возможные действия: не покупать AMD или использовать другой компилятор. Итак, очевидные вещи, которые нужно сделать:

(1) Купите одну коробку AMD и измерьте скорость кода, скомпилированного с помощью компилятора Intel. Это достаточно быстро? Если да, то все готово, вы можете купить AMD, не волнуйтесь.

(2) Если нет: скомпилируйте код с другим компилятором и запустите его на коробке AMD. Это достаточно быстро? Если нет, все готово, вы не можете купить AMD, не волнуйтесь.

(3) Если да: запустите тот же код на коробке Intel. Это достаточно быстро? Если да, то все готово, вы можете купить AMD, но вам придется переключать компиляторы, не волнуйтесь.

(4) Если нет: Возможны следующие варианты: не покупать AMD, выбрасывать все компьютеры Intel или компилировать с двумя разными компиляторами. Выбери один.