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

Мы всегда были магазином 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 есть что сказать об этой проблеме - см. раздел "Компиляторы и грязные трюки" в этой статье.

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

Мой опыт:

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

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

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

Ответ 4

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

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

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

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

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

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

Ответ 7

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

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

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