Пользователь
0,0
рейтинг
5 января 2010 в 20:28

Придётся ли Intel убрать из компилятора функцию, намеренно выдающую плохой код для процессоров AMD? перевод

Многие программисты считают компилятор 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. Приведём цитату из него:
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 («Ущербный Компилятор»), требуется, чтобы:
  1. Intel предоставила им, без дополнительной оплаты, замену компилятора, которая не является Ущербным Компилятором;
  2. Intel возместила им расходы на перекомпиляцию программного обеспечения, которое они скомпилировали с использованием Ущербного Компилятора и замены, а также распространения среди их клиентов, перекомпилированного программного обеспечения; и
  3. 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 новый компилятор и новые библиотеки, которые не проверяют идентификатор производителя, а если выпустит, то когда. Но вот что мы можем сделать до этого времени:
  1. Используйте другой компилятор. Согласно моим тестам, компилятор Gnu для Linux оптимизирует производительность на уровне, аналогичном компилятору Intel, но библиотека функций Gnu (Glibc) хуже, чем у Intel. Все остальные компиляторы показывают более низкую производительность. Под Windows компиляторов с производительностью, близкой к компилятору Intel, не существует.
  2. Используйте компилятор Intel и замените диспетчер. В моём руководстве по C++ я опубликовал код для альтернативных диспетчеров процессора для компиляторов и библиотек функций Intel и инструкции, как их встроить. Конечно, они используют недокументированные подробности об устройстве программного обеспечения Intel. Это изменение может во многих случаях значительно повысить производительность на не-Intel процессорах.
  3. Не доверяйте ни одному тесту производительности, если его исходный код закрыт или не использует нейтральный компилятор, например Gnu или Microsoft.
  4. Инструкции виртуализации 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.
Перевод: Agner Fog
Алексей Романов @alexeyrom
карма
131,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (213)

  • +2
    gcc -03
    • 0
      В статье про это написано.
    • +5
      Лучше gcc -O2 -march=native для личного использования и gcc -O2 -march=i686 для всех.
      Тогда ваши волосы будут гладкими и шелковистыми :) -O3 не всегда включает безопасные оптимизации это раз, а два он увеличивает размер кода, причем на процессорах с маленьким кешем это наоборот приведёт к падению производительности.
      Ещё, если в приложении не требуется высокая математическая точность, ну например в играх, то можно -ffast-math воткнуть, соответственно снижает точность, но повышает скорость математики.
      • +1
        «Опасные» оптимизации — это валидные оптимизации, которые могут сломать невалидный код (язык-то надо знать, на котором код пишется).
        • 0
          Не всегда, бывает, что компилятор банально глупости делает, например, берёт и выкидывает ненужные, с его точки зрения блоки, которые на деле использовались для получения хорошей энтропии. То есть из за оптимизации берёт и портится весь алгоритм шифрования. Или банально использует недокументированые возможности / отход от стандартов. Правда такие флаги даже в -O3 не включаются.
          • 0
            компилятор банально глупости делает, например, берёт и выкидывает ненужные, с его точки зрения блоки, которые на деле использовались для получения хорошей энтропии

            prooflink е?
          • 0
            например, берёт и выкидывает ненужные, с его точки зрения блоки, которые на деле использовались для получения хорошей энтропии.

            Это опять же незнание языка, вероятно где то не использовали модификатор volatile, и поддержу stepancheg нужны пруфы, обязательно с примерами кода.

            p.s: реинкарнировал топик
  • +13
    я всегда подозревал их…
  • 0
    Мне кажется, что выгода, полученная путем подобных подтасовок, существенно меньше, чем потери репутации от таких скандалов.

    Даже странно как-то читать про такую «конкуренцию».
    • +20
      Выгода, полученная за 6 лет? Думаю, больше. Даже если указанное в статье «несправедливое рыночное преимущество ценой в миллиарды долларов» преувеличено, сомневаюсь, что потеря в репутации потянет хотя бы на миллион.

      Тем более, что из ссылок видно, что информация несколько раз уже выходила, а вот Вы об этом слышали? Я услышал вчера в первый раз…
      • –15
        Скажу сразу: до прочтения топика мне про эти махинации известно не было.

        Но в моих глазах репутация Intel упала ниже плинтуса => при прочих равных я возьму другой процессор, и, мне кажется, не только я.
        • –8
          я тоже не знал об этом до прочтения, однако я считаю, что интел ничего страшного не сделал. они выпустили хороший компилятор под процессоры интел, это все равно что audi сделала коробку s-tronic и ставит ее в свои машины. не нравится — не пользуйтесь. кто мешал амд сделать аналогичный продукт?
          • –1
            Вот хорошо написано, что именно мне в этом не нравится.
          • +1
            Есть такие слова: архитектура, стандарты, честность. Но вам и интелу, видимо, об этом ничего не известно.
            • +2
              В многомиллиардном бизнесе чесность не к месту)
          • +3
            Глупость ведь говорите. Если бы Интел изначально позиционировал продукт, как продукт только для Интоел, не было бы и претензий. Но в данном случае продукт позиционируется, как продукт для всех процессоров. И более того, он работает медленнее на других процессорах не по объективным причинам. Это сделано намеренно.
            Если обратиться к вашему примеру с Ауди, то вы представьте теперь, что ауди ставит свою КПП не только на машины ауди, а продаёт её и для других марок, но при этом для других покручивает шестерёнки так, чтобы на любой другой машине, кроме ауди, КПП работала хуже.
  • +5
    Как там было, Wintel? С кем поведешься, от того и наберешься…
    • +1
      Это ещё вопрос, кто от кого набрался…
  • +2
    странно, не правда ли?
    • +2
      У Интел уже были соглашения с производителями компьютеров, чтобы процент конкурирующей продукции был ниже указанного порога. Чего удивляться?
      • +2
        А с эпл они вообще этот порог ниже плинтуса опустили :)
        • 0
          Intel only :)
        • +2
          Ну с Apple там своя ситуация — Apple сама выбрала Intel так как это единственный производитель способный отгружать огромные партии процессоров с гибкостью нужной Apple.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Пруфлинк интересно было бы почитать.
      • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    пошел патчить icc…
    • +5
      video.bnx.homelinux.net/intel_patch-ppro.pl — патчилка сгенерированных бинарников.
      • –1
        У меня как-то тоже сразу возникла мысль патчить бинарники после компиляции…
      • 0
        и вы собираетесь патчить каждую новую сборку вашей програмы?

        надо «рубить под корень» — патчить компилятор.

        кстати пока дело не очень перелопатил масу кода и ничего…
        когда найду — напишу патч, тка что ждите…
        • +1
          Так Agner Fog описал же как «пропатчить» компилятор.
          • 0
            где?
            • 0
              В своём руководстве по оптимизации программ (см. пункт 2 раздела «Временные решения»).
  • +2
    Согласно моим тестам, компилятор Gnu для Linux оптимизирует производительность на уровне, аналогичном компилятору Intel, но библиотека функций Gnu (Glibc) хуже, чем у Intel. Все остальные компиляторы показывают более низкую производительность. Под Windows компиляторов с производительностью, близкой к компилятору Intel, не существует.
    — э… gcc под windows оптимизирует хуже чем под линукс, или intel под linux оптимизириует хуже чем под windows?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        а что, чистые obj-ы gcc под win не может рожать? чтобы, скажем, в msvc-ными lib-ами их линковать?
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            > gcc делает либо *.o несовместимые с msvc
            Ну как это: я собирал GMP (GNU Multiprecision Library) Mingw и линковал программы, её использующие, в MSVC++.
            • 0
              GMP же вроде бы Си. Проблема в том, что у Си ABI стандартизирован, а у Си++ нет, поэтому можно линковать сишные либы, собранные разными компиляторами, но с++нутые либы, скорее всего, не выйдет.
              • 0
                Во-первых, zlogic ни про какие плюсы не говорил, я специально заквотировал фразу, на которую отреагировал. Во-вторых, сейчас GMP идёт с C++-привязками и собирается это всё вместе.
                • 0
                  Забавно, но вот я помню сталкивался с проблемой, когда ломалась бинарная совместимость между приложением и плагинами от того, что они были собраны разными компиляторами.
                  • 0
                    Я тоже такое слышал, на самом деле, но видел и ряд положительных примеров, так что тут сложно сказать что-то однозначно. Потому мне и не понравилась безапелляционность в цитате выше.
                    • 0
                      Положительные примеры обычно делаются при помощи
                      extern «C»

                      #define DLLEXPORT extern «C» __declspec(dllexport)
                      // extern «C» обозначает использование простой генерации
                      // сигнатуры функции (в стиле языка С) при получении объектных
                      // файлов. В частности, это запрещает компилятору C++
                      // производить «декорацию» (или «украшение») имени функции
                      // дополнительными символами при экспорте в DLL

                      • 0
                        Вспомните, что изначально речь шла про объектники, а не про dll. Про dll я специально ничего не говорил, потому что опыта с ними у меня меньше.

                        То, что манглирование часто непереносимо между компиляторами это да, я в курсе.
                        • 0
                          Ну я и не видел примеров, когда обьектники от разных компиляторов смешивали. Они даже в рамках одного компилера могут быть несовместимы, даже в рамках флагов. Это внутренности, тут компилятор волен с ними поступать как хочет лишь бы линковщик потом смог это всё собрать.
                          • 0
                            Господа обратите внимание на линкер — UniLink — он знает толк в извращениях (кросплаиформенной линковке)
                            • +1
                              Спасибо, запомню на будущее. Но не уверен, что в опенсорсных проектах он нужен. А если уж припрёт, то я видел в составе minGW конвертилку, которая спокойно превращала собранную msvs либу в понятную для gcc
          • +2
            Всё там нормально, просто под Вин долгое время не было gcc4, а была только древняя третья версия, которую всерьез никто и не принимает уже.
            И gcc под Вин вполне себе полноценные *.obj рожает, только вот по ABI они несовместимы с MSVS.
            Но в целом всё нативненько получается, даже mingw10.dll не нужна, если флаги правильные поставить. А нужна она не для i/o запросов, а для потокобезопасной обработки исключений, выключаем исключения, врят-ли ими кто-то пользуется, и спокойно собираем без зависимости от mingw10.dll
            Но вообще третья версия местами существенно проигрывала даже MSVS, не говоря уж об ICC, 4ая официально появилась пару месяцев назад, и тестов я пока не видел.
            Для тех, кто хочет пощупать minGW на gcc 4.4.0 ссылка
  • +6
    Вот уроды (с)
  • +8
    Не зря я люблю АМД.
    • +1
      я кстати тоже. например за бесплатный и довольно навороченный codeanalyzer.
      а вконтексте статьи за что его любить? за иски? или за роль обиженного?
      • +11
        Хотя бы за то, что не обманывает людей как Интел.
        • +4
          Ну… этого мы пока возможно просто не знаем =)
        • 0
          А как же вписывание в название процессора 3500+, 5000+? В первый раз когда увидел, подумал что это частота проца, а оказалось, что она ниже и эта цифра фальшивка… не обман ли это?
          • –1
            В первый раз когда увидел, подумал что это частота проца
            Мало ли кто чего когда подумал. Нигде ни в какой документации не сказано, что это частота, это часть названия. Видимо, тогда AMD была первая, кто ввел маркировку процессора по сериям, а не по тактовой частоте, вы с непривычки напутали. Теперь же это у всех процессоров так, никто не путает.
            • +1
              Вы видимо забыли маркетинговые ходы AMD в прошлом… они этими 3500+ прикрывались, что бы показывать сравнение между Intel, т.е. они имели ввиду, что:
              AMD (номинал 2GHz) 3500+ = Intel 3.5GHz
              И никакого обмана! :))

              К маркировке по сериям эти цифры не имеют никакого отношения.
    • +1
      Ну люди всегда будут любить ущемленных и обиженных. Я почему-то уверен, что если бы корпорация AMD была на месте Intel, политику она вела бы не сильно отличную от последних.

      P.S. Оказывается, что прирост производительности в Core2Duo по большей части сделан за счет оптимизации библиотек под него? Эх, как я мог так купиться ((. Маркетинг — зло.
  • –11
    Вот я не понимаю — компилятор вставляет какие-то незапланированные куски кода в ваши программы чтоб они работали медленнее на АМД? Даже у параноиков есть враги, ога. Поиск очередной империи зла. Не нравится компилятор — не используйте его, делов то.

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

    Или я завтра напишу программу и скажу — ничего не знаю — для запуска надо проц от Интел и только. В своем праве. Можете запустить на АМД/ВИА и т.п., но быстрой работы не гарантирую — и опять прав. Ибо предупреждал
    • +20
      Интел выдает лицензии на свою архитектуру. Код, созданный их компилятором ОБЯЗАН работать на любом процессоре данной архитектуры.
      Однако, исходя из статьи, компилятор создает код, который предвзято относится к процессорам, отключая огромный потенциал не-интеловских процессоров. Обещая выдавать i686 код, выдает i386.

      Это как будто вы заехали на заправку, заплатили за 98ой, а вам влили 95, потому что вы не на хаммере.
      • –4
        Ну, во первых, никому он не «обязан». Уверен, что в лицензии про intel C++ compiler ничего нет.

        А во-вторых — он же работает, но не так быстро.

        В третьих, за что заплатили — то и влили:

        " ...compiler delivers advanced capabilities for development of application parallelism and
        winning performance for the full range of Intel® processor-based platforms. "

        (из описания компилятора на сайте интела)
        • 0
          Такое поведение у нас называлось капитализм по русски?
          • 0
            Ето называется «свобода предпринимательства», если быть точнее. Я вот, например, под макось плохо умею программы писать, значит ли это что эппл должен подать на меня в суд?
          • 0
            Может быть, даже правосудием.
            Из дебрей словесной логики вроде выдавливается, что интел прав (да уж наверняка они поднапряглись для этого). Ну подумаешь, распеарили компилятор, да забыли указать, что для конкурентного железа он черепаший код готовит, это же любому первоклашке понятно (особенно после массы грязных историй о сговорах с различными вендорами). А те из «непонятливых» разработчиков, что не имеют привычки дизассемблировать свой собственный код (да еще и в рантайме!) — так они же дураки, пусть вымрут, естественный отбор.

            Но вот обычная, пока еще не вытравленная человеческая мораль сигналит — наебывают!
            • +3
              Я тоже сначала подумал где-то наебывают, но представьте себя на месте разработчиков интела.

              У вас есть функция инвертирования матриц, например. Потом вы решаете написать версию, оптимизированую для SSE5, тщательно гоняете ее на тестовых машинах (с процессорами интел, естественно). Потом, поскольку вы не уверены в том, как оно будет себя вести на других процессорах, пишете код

              if (cpuid() == 'genuineintel') sse5_version(); else generic_version();


              Конечно, можно потратить еще изрядно времени, и написать еще версию под амд, но если она вдруг окажется медленнее чем могла бы быть, вам точно голову оторвут в суде.
              • +3
                Такие вещи описываются в документации… Ткните мне пальцем, где это написано.
                Во вторых, для любителей странного следовало бы добавить флаг, который снимает проверки по cpuid()
                В третьих же в статье показывали, что код работал нормально, когда ему другой cpuid подставляли
                • +5
                  Пожалста, вот здесь написано — при использовании описаной фичи, компилятор «генерирует инструкции SSE для процессоров Intel».

                  То что в статье код работает нормально это хорошо, но на месте разработчика компилятора я б хотел быть в этом на 100% уверенным — а для этого надо провести изрядное количество тестов специально для AMD.

                  А флаг согласен, стоило бы иметь, но это на преступление не тянет.
                  • 0
                    Ну то есть поймите меня правильно — конечно, интел мог бы вести себя лучше в этой ситуации, но на мой взгляд, нисколько не обязан (даже с моральной точки зрения), и реализовать это не так просто, как кажется на первый взгляд.
                    • –2
                      Опросить процессор на предмет поддерживаемых инструкций это ведь так сложно?
                      • +2
                        Можно представить ситуации, когда SSE код будет быстрее/медленнее не-SSE, в зависимости от процессора.
                      • 0
                        Кстати, принудительно указать компилятору с каким набором инструкций генерировать код (в обход «осторожному» деспетчеру) тоже совсем несложно.
              • +5
                «Звучит хорошо, но на самом деле диспетчер процессора не поддерживал в процессорах AMD даже SSE и SSE2, не говоря уж о более новых версиях, и не поддерживает их до сих пор (компилятор Intel версии 11.1.054)»

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

                Это ведь такая невыполнимая работа для честнейшей компании интел — построить табличку возможностей процессоров AMD и скормить ее диспетчеру.
              • +2
                Хорошо, мы не уверены в том, нет ли каких-то багов в поддержке SSE5 у AMD. Но для этого как раз и должна служить та задержка, о которой они говорят:

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


                Автор статьи как раз считает это вполне допустимым («звучит хорошо»).

                И если они действительно обещали ещё три года назад включить поддержку для SSE3 у AMD в 10-й версии (то есть проверили и убедились, что багов нет), а до сих пор не включили даже поддержку SSE, то ситуация уже несколько другая.
                • +2
                  Не, я не имею ввиду что у АМД там гипотетические баги, просто нельзя быть уверенным, что если оптимизированный под SSE код работает быстрее на intel, то он на других процессорах будет тоже более шустрым. У всех процессоров есть свои особенности.

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


                  Есть простейший, старинный пример — на ранних intel инструкция
                  inc a
                  

                  быстрее чем
                  add a, 1
                  


                  На новых ровно наоборот. Естественно, если производительность очень критична, надо перекомпилировать.
        • +2
          У них также сказано

          Intel® Professional Edition Compilers include advanced optimization features, multithreading capabilities, and support for Intel® processors and compatible processors.
          • –1
            Ну да, совместимые процессоры поддерживаются… примерно на уровне устаревших интеловских ;).
          • +1
            Ну так «support for Intel® processors and compatible processors» присутствует, никакого обмана
            • 0
              а где же advanced optimization features?
              • +1
                Я ету фразу понимаю как
                Intel® Professional Edition Compilers include (advanced optimization features) and (multithreading capabilities) and (support for Intel® processors and compatible processors).


                Потому что если ее понимать как
                Intel® Professional Edition Compilers include (advanced optimization features and multithreading capabilities and support) for Intel® processors and compatible processors.

                то слово support становится бессмысленным.

                Впрочем, я не лингвист :)

                • 0
                  А мне кажется, что в первом варианте теряется связь между advanced optimization features и Intel® processors. Так что я мимо него проскочил, увидел, что "(advanced optimization features and multithreading capabilities and support for Intel® processors) and compatible processors" — бессмыслица и понял её как второй вариант.

                  Я, впрочем, тоже не лингвист :)
                • 0
                  Я тоже не лингвист, но тем не менее мне кажется, что вырывать половину фразы из целого предложения — не дело. Если бы Intel хотела обособить поддержку advanced optimization features и поддержку Intel® processors and compatible processors, придумали бы формулировку, в которой это было бы явно.
      • +2
        Это как будто вы заехали на заправку, заплатили за 98ой, а вам влили 95, потому что вы не на хаммере.

        Вот-вот. Первая ассоциация была именно такой.
      • 0
        Имхо, это скорее как будто вам — владельцу автосервиса дали оттюнить машины для гонки ваш сын и другие дети. Вы добротно потюнили остальные машины(лучше чем любой другой мастер в городе), но машину ребенка довели до идеального состояния. Да, это не совсем честно по отношению к другим, но насколько будет честно обмануть ожидания своего ребенка, что уж ему-то вы сделаете идеально?
        • 0
          Заранее уточню, что результат гонки процентов на 90% зависит от того, кто за рулем.
        • +3
          Процессоры и компиляторы для Интел — это бизнес.

          Если руководство интел излишне отождествляют их с детьми, им требуется помощь квалифицированная психоаналитиков.
          • 0
            xtender — руководство интел? О.о ух, какие люди.
          • 0
            Бизнес бизнесу — рознь. Если я что-то делаю с душой, то созданное считаю своим родным. Другое дело, если вы не любите свою работу.
            • 0
              Ну, это ваше личное право.

              Просто в случае реальных детей, пострадавшие вероятно отнесутся к ситуации с пониманием.
              В случае бизнеса — вполне резонно назовут ситуацию нечестной конкуренцией.
              Для невовлеченного человека очень заметна разница между ребенком и продуктом.
        • 0
          Не согласен с примером.
          Это как если своему ребенку поставить турбированный мотор, а другим упорно говорить, что таких не существует.
          Он не просто что-то не так оптимизирует:
          диспетчер процессора не поддерживал в процессорах AMD даже SSE и SSE2, не говоря уж о более новых версиях, и не поддерживает их до сих пор (компилятор Intel версии 11.1.054).
    • +1
      в статье отмечено, что если Интел захочет, то тебе прийдется искать/покупать новую версию компилятора под конкретную модель их же процессора

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

      интел слишком агрессивно ведет борьбу за рынок, чего только стоит скандал с субсидирование производителей ноутов для вытеснения АМД
    • +4
      Цитата из статьи:
      Если бы Intel декларировала свой компилятор как совместимый только с процессорами Intel, то никаких жалоб, скорее всего, не было бы.
    • 0
      Они постоянно отрицали проблему, а я приводил всё больше доказательств. Они утверждали, что:
      Диспетчер процессора, в сочетании с оптимизациями, предназначен для оптимизации работы на всех процессорах Intel и AMD, чтобы дать лучшие возможные результаты. Это наша цель и мы считаем, что мы её достигли, за одним исключением. Это исключение — отсутствие поддержки SSE3 на процессорах AMD в версиях 9.x нашего компилятора, связанное со сроками выпуска (наш компилятор был разработан до того, как AMD сделала поддержку SSE3). Следующая версия компилятора 10.x, бета-тест которой начнётся в этом квартале, а окончательная версия будет выпущена примерно в середине этого года, позволит решить эту проблему, поскольку у нас хватило времени приспособиться к новым процессорам AMD.
      Звучит хорошо, но на самом деле диспетчер процессора не поддерживал в процессорах AMD даже SSE и SSE2, не говоря уж о более новых версиях, и не поддерживает их до сих пор (компилятор Intel версии 11.1.054).
      А как быть с этим?
      • +1
        Ну для этого нужно, хотя бы, статью целиком прочитать, что наверное не все сделали
    • 0
      Основной момент в том, что Intel как раз таки заявляет, что ICC выдает одинаково оптимальный код для любого процессора, таким образом вводя в заблуждение разработчиков… Из-за этого разработчики используют ICC, который, однако, на деле совсем не так беспристрастен к процессорам, как обещано.

      Таким образом, обманом Intel переводит разработчиков на свой компилятор, выставляя процессоры конкурентов в невыгодном свете, т.к. скомпилированные его компилятором программы заведомо быстрее работают на Intel.
    • +9
      Всё немного сложнее. Например, многие пользователи принимают решение о приобретении процессора на основе мнений независимых экспертов (вроде thg). Те тестируют процессоры программами независимых разработчиков (играми, кодерами, архиваторами и т.п.). В результате мы имеем вроде-бы объективное сравнение. Но т.к. многие из этих программ компилируются интеловским компилятором, интел имеет возможность повлиять на результаты тестов. И этой возможностью беззастенчиво пользуется. В результате пользователи покупают не те процессоры, что быстрее, а те, на которых компилятор Интел работает быстрее. Выбирать же компилятор пользователи не могут — это делают разработчики ПО.
      Т.е. Интел подставляет АМД на рынке процессоров, пользуясь своим монопольным положением на рынке компиляторов. Компилятор Интел специально тормозит программы на АМД, а для пользователя это выглядит как торможение из-за процессора АМД.
      По сути, Интел создала зависимость пользователей от процессора Интел, аналогичную зависимости пользователей от Windows.
      Можете сменить ОС/ЦП, но тогда ваши программы перестанут/будут_медленнее работать.
      Очень умно, но точно не идет на пользу рынку и конкуренции.
      • +1
        Стоп. Я запутался.

        Программы/игры скомпилированы на компьютерах с Интел процессорами и отправлены в печать. Эти игры/программы купили и тестируют на АМД процессорах.

        Я правильно понимаю, что компилятор интел встраивает в код инструкции вида
        if(not_intel()) go_bad_way()
        И этих инструкций никто никогда не видел в асемблерном коде при выпуске игры/программы?
        • 0
          Увидел пример таких инструкций ниже :)
        • +3
          Компилятор Интел дает лучшую из всех компиляторов производительность для процессоров Интел (что не удивительно). Но намеренно уменьшает производительность скомпилированных программ на АМД.

          Процессоры Интел более популярны -> Производители ПО выбирают тот компилятор, который делает лучший код для более популярных процессоров -> Большинство программ откомпилированы Интелом и поэтому тормозят на АМД -> Пользователи видят, что на АМД всё тормозит -> Процессоры Интел более популярны

          У АМД практически нет шансов разорвать этот круг просто улучшая свою продукцию, т.к. какие бы ни были хорошие у них процессоры, получается они будут тормозить на большинстве программ только от того, что в них нет строчки «GenuineIntel».

          Инструкции эти не секрет и вы можете тоже на них посмотреть.

          В теории: «пусть АМД сделает свой крутой компилятор, который будет круче интел». Но на практике АМД скорее надорвется и сдохнет и останемся мы вообще без конкуренции, которая двигала этот рынок многие годы бешенными темпами.
          • 0
            Пусть помогают эпл LLVM и Clang писать, и поддерживают виндозную реализацию.

            Как говорят генетики: «Одна голова хорошо, а две — лучше». :)
          • 0
            Для того, что бы не сдохнуть в гонке надо купить команду разработчиков, как это делают другие.

            Из всего этого видно только одно… AMD пиарится таким образом, как раньше своими 3500+, мол их обделили, а вот они такие хорошие. Мне, как пользователю AMD это не важно, не мне с Intelом конкурировать… это Ваша (AMD) работа.

            Плохо только то, что они сравнивают свой продукт с тем, что делает конкурент, а это маркетинг из серии стиральных порошков… типа есть «просто процессор», а есть AMD… а надо показывать свои реальные достонинства.
      • 0
        Забавно, что эпл пользуется только интеловскими процессорами, и при этом только опен-сорсными компиляторами (которые, фактически сам и пишет).
        • +2
          llwm+clang не только они пишут, да и пока он ещё далек от совершенства. Оптимизирует он пока хуже, чем gcc, хотя потенциал у него хороший.
          А в gcc они только свои патчи отправляют.
          • 0
            Они, какбэ, руководят (лидер LLWM в эпл работает) :)
            Да и в барсике уже на них перешли по-умолчанию.
            • 0
              Барсика у меня вот нету((( Знаю ещё во FreeBSD на него перешли. А как там с С++? clang его держит? А то Леопард для С++ предлагал только llvm+gcc
              • 0
                Пока не работает C++, еще доделывают.

                Вот 8 страница из арстехниковского обзора барсика. Рекомендую, конечно, весь обзор, очень увлекательный.
  • +11
    Ну да, чуваки из интел не особо парятся с производительностью кода их библиотек на AMD, что тут криминального? AMD можно только посоветовать развивать свой компилятор или, еще лучше, всячески содействовать развитию gcc.
    • –2
      Вот именно, самое странное, что их лого нет на сайте GCC. Я думаю, что им просто это не надо и не интересно. Только бы воду поварить и пальцем по-тыкать :)
  • +2
    дворник подмёл свой двор и соседний. свой подмёл хорошо, соседний на скорую руку, чтобы просто было чисто. и жители соседнего двора его ещё и засудить пытаются.
    • +8
      Все-таки договор со скайпом — очень грязно, равносильно если бы дворник сметал мусор в соседний двор.
    • +6
      Я понимаю, если бы компилятор был бесплатным, а так получается, что соседи вызвали дворника, а он бы прибрался в лучших традициях школьных уборок.
      И еще, что веселее, страдает ведь не тот, кто купил компилятор, а простые ни в чём не повинные пользователи amd процессоров, у которых эти бинарники внезапно стали работать медленнее.
      • +5
        Точнее, у которых они не стали работать быстрее, несмотря на улучшение процессора.
      • +1
        на самом деле, не знаю, как там умные интеловцы написали про поддержку амд процов. может быть, там много мелкого шрифта и сносок )
        • +2
          Да там нет мелкого шрифта, там в первом же предложении написано «генерирует очень клевый и быстрый код для процессоров Intel». пруфлинк
    • 0
      или ещё пример — жена соседа любит соседа больше чем тебя. обииидно )
      • +5
        или другой пример: вы и ваш сосед решили приударить за одной и той-же девицей. Сосед, пользуясь тем, что подрабатывает в столовой, где вы оба питаетесь, подсыпает бром вам в компот. И вот вы уже ему и не конкурент.
        • –1
          В случае с бромом — очевидно умышленное деструктивное действие. Разработчики icc скорее бездействуют, намеренно не оптимизируя свои библиотеки под AMD. Вообще, я далёк от темы сравнения производительности, но тот факт, что AMD не предоставляет к своему процессору компилятор, довольно странно смотрится. Как можно такой важный аспект отдавать на откуп Интелу, прямому конкуренту?
          • +2
            Сравнение вполне корректное, здесь есть деструктивное действие. Вообще-то Intel не «не оптимизируют», а намеренно ухудшают работу программ на процессорах AMD.
            • 0
              что значит намеренно ухудшают? они не используют все их возможности, это да. Но они и не обязаны вкладывать дополнительные усилия в тестирование процессоров AMD. Вот если бы они при распознавании чужих процессоров алгоритм быстрой сортировки заменяли бы на «пузырёк» — тогда намеренное ухудшение было бы очевидно. А так оно недоказуемо.
              • 0
                1. В Inte; указывают, что поддерживают AMD в полной мере, так же как и родные процессоры.
                2. Если бы они действительно просто не вкладывали дополнительные усилия, то был бы дополнительный флаг, который отключал бы данную проверку (GenuineIntel). Также это было бы указано в документации.
    • 0
      Жилищная контора наняла этого дворника потому, что он обязался подмести оба двора одинаково качественно за время, которое требовалось обычному дворнику для подметания одного.
      На деле же получила халтуру вместо работы в чужом дворе, т.к. дворник просто захотел заработать побольше бабла)
    • +1
      А если так.
      В данном случае дворник — это программист, а метла — это программа. Дворник хорошо подметает свой двор, потому что метла легко скользит по асфальту от завода Интел :), но соседний двор, метла, как ни крути, подметает плохо, вроде и асфальт не плохой, но он от завода АМД. Так люди жалуясь, узнают от разных дворников, что лучше стелить асфальт от Интел. %)
  • –1
    Мне одному кажется, что «Мировой Договор» в том виде, в каком он сейчас есть, позволяет Intel не особо расстраиваясь делать следующее:

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

    Это явно «бездействие по отношению к другим производителям»+«улучшение по сравнению к себе», а, следовательно, вполне укладывается в термины договора.
    • +2
      Ну, у такого продукта тоже есть своя серьезная ниша.
      Главное, чтобы побольше разработчиков узнали об этой истории.
      Чтобы те, кому нужна такая глупость, как максимальная средняя скорость на всех платформах, совершенно случайно не ошиблись в выборе инструмента.
  • +15
    нашёл: из проекта компилиного интеллвским компилятором

    XOR EAX,EAX
    CPUID
    MOV DWORD PTR SS:[EBP-20],EAX
    MOV DWORD PTR SS:[EBP-1C],EBX
    MOV DWORD PTR SS:[EBP-18],ECX
    MOV DWORD PTR SS:[EBP-14],EDX
    MOV EAX,1
    CPUID
    MOV DWORD PTR SS:[EBP-10],EAX
    MOV DWORD PTR SS:[EBP-C],EBX
    MOV DWORD PTR SS:[EBP-8],ECX
    MOV DWORD PTR SS:[EBP-4],EDX
    JMP 0045DF7D; sse.0045DF7D
    XOR EAX,EAX
    MOV DWORD PTR SS:[EBP-20],EAX
    MOV DWORD PTR SS:[EBP-1C],EAX
    MOV DWORD PTR SS:[EBP-18],EAX
    MOV DWORD PTR SS:[EBP-14],EAX
    MOV DWORD PTR SS:[EBP-10],EAX
    MOV DWORD PTR SS:[EBP-C],EAX
    MOV DWORD PTR SS:[EBP-8],EAX
    MOV DWORD PTR SS:[EBP-4],EAX
    MOV EAX,DWORD PTR SS:[EBP-1C]
    CMP EAX,756E6547; сравнивание с «Genuine»
    JNZ SHORT 0045DFA2; прыгать не надо
    MOV EAX,DWORD PTR SS:[EBP-14]
    CMP EAX,49656E69; сравнивание с «Genuine»
    JNZ SHORT 0045DFA2; прыгать не надо
    MOV EAX,DWORD PTR SS:[EBP-18]
    CMP EAX,6C65746E; сравнивание с «Genuine»
    JNZ SHORT 0045DFA2; прыгать не надо
    MOV EDX,1; в edx флаг «силы»!!!
    JMP SHORT 0045DFA4; всё нормально
    XOR EDX,EDX; а сюда прыгаем если не Genuine)))
    MOV EAX,DWORD PTR SS:[EBP-20]
    • +5
      video.bnx.homelinux.net/intel_patch-ppro.pl — патчилка сгенерированных бинарников. Убирает проверку наличия «GenuineIntel».
      • 0
        Там написано что оно для фортрана. Не?
        И вообще, какие бинарники оно патчит? Win32 или Linux?
        • 0
          Проверял. работает и на ICL тоже. Патчит win32. Линуксовые не проверял, но должно работать.
  • –15
    Отличная статья, жаль что плюсовать пока не могу :)

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Вы не понимаете пользы конкуренции?
      • НЛО прилетело и опубликовало эту надпись здесь
        • +3
          Серьезно хотите разные версии программ под разные процессоры?
        • +1
          Я веду речь о конкуренции между процессорами.
          Если Intel обманным путем (создание компилятора, якобы генерирующего оптимизированный код для любого процессора, чтобы вынудить разработчиков применять его и таким образом пополнять парк программ, которые искуственно оптимизированы под Intel) выдавит AMD с рынка, это убьет конкуренцию на рынке процессоров, что очень негативно отразится на простых пользователях.
  • +3
    Приведите, пожалуйста конкретные цифры (время выполнения), для конкретных процессоров!
    Ибо, слово «медленнее» само по себе в данном случае ничего не значит.
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    это из той же песни, когда MS запретили IE c Windows поставлять)))

    > Хотя бы за то, что не обманывает людей как Интел.
    где обман?
    • –1
      Обман в том, что Intel обещает одинаковую оптимизацию независимо от производителя процессора.
      Чем и соблазняет разработчиков на переход на ICC.
      На деле же все совсем иначе, что выливается в проблемы для пользователей других процессоров и неверные результаты тестов.
  • –4
    то есть вы хотите чтобы интел разрабатывала компилятор для АМД? Может интель и процессоры для АМД и прочих должна начать разрабатывать? Может и с рынка интелю уйти надо?
    • –1
      А за что вы минусите челвоека?

      Нет, ну вот правда, это все равно что говорить «что-то на моём Мерседесе коробка передач от форд мустанг херново пашет, во всем виноваты конструкторы Мерседеса».

      Почему АМД не делает свой компилятор?
      • –4
        Нет, ситуация другая. Человек говорит:
        Что-то на моём Мерседесе коробка передач от Запорожца, хотя можно было поставить и от Форд Мустанга
        • НЛО прилетело и опубликовало эту надпись здесь
    • +6
      Нет, мы хотим чтобы Intel честно заявляла — наш компилятор оптимизирует код только для процессоров Intel.
      После этого боюсь немногие разработчики станут им пользоваться.
      • +1
        А ещё лучше пусть выделяет программистов компилятора в независимое подразделение и пусть пишут хороший компилятор а не инструмент подавления конкурентов
    • +5
      ЧИТАЙТЕ ВНИМАТЕЛЬНО СТАТЬЮ!
      Компилятор Intel заведомо использует ДРУГОЙ, ЗАВЕДОМО ХУДШИЙ метод для процессоров AMD. И заявляет, что поддерживает процессор AMD ПОЛНОСТЬЮ, т.е. так же как и Intel.
      • +2
        А можно цитаты из заявлений Intel об этом?

        Я вот читал, ничего подобного не нашёл.
        • +1
          Не из статьи, я прямо из материалов Intel.
      • НЛО прилетело и опубликовало эту надпись здесь
        • –2
          Вы умеете читать? Intel специально использует ДРУГИЕ инструкции для процессоров AMD, хотя AMD спокойно может работать с ОРИГИНАЛЬНЫЕ инструкции
          • –1
            А что вы хотите? Больно надо Интел помогать своим конкурентам.
            • 0
              Вы хотите дикого капитализма или капитализма по Русски?
              • 0
                по-русски — это с убийствами конкурентов?
      • –1
        если бы интел компилятор втыкал пустое место вместо функции «мызапустилинаAMD» — то это было бы не поддерживает, а так формально работает и ладно, никто не обещал оптимизацию под AMD
  • +2
    Ещё один повод сидеть на моём старом добром freepascal.
  • +2
    А может, кто-нибудь тестирование устроит?
    Сначала на обычном скомпилировать, потом на пропатченном компиляторе?
    Готов выступать в роли кролика, но у меня компилятора нет :)
    • 0
      Готов для тестов предоставить Core2Quad q9550 и 4 гиг рамки >.< Пусть победит самый быстрый. Или самый наглый :)
      • 0
        Я имел в виду, что на одной машине запустить ехе-шник, собранный на обычном компиляторе и на пропатченном. Результат даст сравнение результатов.
        Померяться — это святое. Написал в личку.
        • 0
          Угу, а потом сравнить те же ехешники на интеле :)
          Нифига в личку не пришло
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Угу, наверное по этой причине трехядерники АМД сливают двухъядерникам интел на одинаковой памяти и в одном ценовом диапазоне?
          • –2
            Вот, она, правильная подача материала. Как бы тот факт, что трехядерники АМД сливают двухядерникам АМД в том же ценовом диапазоне совсем не причем.

            Не смотря на впариваемую производителями процессоров гонку ядерности, обычным приложениям, как и 20 лет назад, намного важнее мегагерцы.
            • 0
              Ну как бы те же двухъядерники АМД сольют тем же от интел чисто из-за того, что у интел сейчас более производительная архитектура.

              Никак не могу понять тех, кто минусит только за то, что любимую амд/нвидию/интел/ати осветили не в лучшем свете. Факты есть факты, и проц с 4 универсальными операциями за такт (на 1 ядро) на равной частоте выигрывает у проца с 3, да еще и универсальная у него только одна. Имхо это основной фактор отставания АМД, а вот со встроенными контроллерами памяти они интел в своё время обошли, да.
              • +4
                Факты есть факты
                О том факте, что передовые процессоры интела быстрее оных у АМД, я и не собирался опровергать. Речь о том, что за один и те же деньги (в ценовом диапазоне, где обоим фирмам есть что предложить) чаще выигрывает АМД.

                Простой пример: когда я покупал свой атлон 5200+ за 2500 рублей, не было ни одного Core Duo за ту же стоимость. Все, что могла предложить интел — Pentium D, которые технологически еще более отсталые, чем Атлоны.
              • +3
                Пример более современный:
                Самый быстрый двуядерник, который продается в соседнем магазине:
                CPU ATHLON64 II X2 250 Socket AM3 2500р.
                По стоимости ему соответствует интеловский:
                CPU INTEL Core 2 Duo E6300 2690р

                Запрашиваем у яндекса тест ATHLON64 II X2 250 Core 2 Duo E6300 и первый же результат:
                iXBT: Intel Core 2 Duo E6300 — шустрый «малыш», приятно удививший…
                И снова Core 2 Duo E6300 идёт практически вровень с Athlon 64 X2 4800+
                Процессор за чуть большую стоимость от интела почти догоняет! устаревшее говно от АМД! Как вы думаете, на сколько ATHLON64 II X2 250 быстрее Athlon 64 X2 4800+? Думаю, раза в 2 :)

                Возьмем другое предложение от интела чуть большей стоимости:
                CPU INTEL PENTIUM E5400 2720р

                Снова смотрим в яндексе, находим такую статью, где более слабая модель 245 всетаки опережает E5400 в большинстве тестов. Понятно, что 250 будет опережать еще сильнее. Добавим еще разницу в стоимости, и что получается? Опять AMD выигрывает всухую.
                • 0
                  Я предлагаю сравнивать что-нить типа е7300 или е6600, а не обрезанные процы трехлетней давности :)
                  • 0
                    Ну сравните, я не против. В моем магазине их нет, цены я не знаю.

                    Вы, кстати, какие е6600 имеете ввиду?

                    CPU INTEL Core 2 Duo E6300 2x1860MHz-1066 2048Kb LGA775 2690р
                    CPU INTEL PENTIUM E6300 2x2800MHz-1066 2048Kb LGA775 (Ядро Core) 2790р

                    Интересно, как интелы сами не путаются в такой классификации :)
                    • 0
                      Я думаю тут в прайсе накосячили. Я имею ввиду Core2Duo e6600 @ 2.4gHz (Conroe)
          • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
          • +2
            чем ati stream не угодил? оно ведёт себя гораздо лучше чем cuda — thg.ru/graphic/ati_stream/
            • +2
              Тогда уж сразу лучше на openCL переходить, эти знания точно пригодятся, чтобы не случилось ни с Нвидией ни с АТИ, ибо это стандарт
            • 0
              Вы на нем работали? )
              • 0
                не на том не на другом, но очень собираюсь, вот и хотел услышать от товарища конструктив. судя по обзорам и архетектура и скорость на стороне ati\amd.
        • –2
          за теже деньги конфа Intel/ATI будет быстрее AMD/nVidia.
        • НЛО прилетело и опубликовало эту надпись здесь
    • –2
      А по мне так AMD
  • +7
    Названия Из Нескольких Слов В Русском Языке Пишутся С Маленькой Буквы.
  • 0
    Обьясните плиз идиоту. Вот я компилю на своём intel-проце с поддержкой sse4, и он мне выдает код с использованием тех самых sse4. А этот самый экзешник на Pentium4 / PentiumD уже не станет работать? Или что? Те же камни не понимают 4ый набор инструкций.
    • 0
      Если вы поставите флаг «компилировать c поддержкой sse4», то да — не будет. Поэтому та же винда xp собиралась всегда под generic i386. По этой же причине пользователи Линукс утверждают, что пересобранное под их архитектуру ядро (i586, i686 и выше) работает быстрее.
      • 0
        Спасибо, просветили :) А подо что скомпилено ядро Win? >.<
        • 0
          Ну были же умельцы, которые на P2 запустили Win7, значит оно как минимум i686
      • +1
        Быстрее, стопроцентно. А ещё x86-64 код быстрее работает в том числе и от того, что его собирают с заведомо более выгодными флагами, ибо нет процессоров x86-64 без sse и т.п.
        • 0
          Сам не мерял, врать не буду. А где можно заценить результаты, не подскажете?
          • +1
            ну например на phoronix много всяких тестов, но там любят тёплое с мягким сравнивать.
            Или сами сформируйте архив и на время распакуйте на 32битной и 64битной системе, причем на IA-32 не забудьте собрать вначале с i386, а потом с native для сравнения.
            Ессна в качестве компилятора нужно gcc взять
  • +1
    Ммм. Можно сколь угодно пытаться «упросить» компанию интел изменить поведение их компилятора. Меня удивляют слова автора, когда он писал, что общался с тех.поддержкой интел. Врядли компания с многомиллиардным доходом будет рушить свои планы из-за писем со стороны программистов и пр.
    По-хорошему, надо самому проверять возможности процессора и в своем коде приводить указатель на функцию к различным функциям, написанным отдельно для каждой технологии.
    Изучайте SIMD инструкции, пишите свои оптимизированные модули на asm и подключайте их в свои проекты на том же С++ и все будет гуд.
    А так время теряете. Бороться с таким гигантом, у которого сумма бабок за спиной некислая.

    Кстати, мне больше нравится Intel. Конечно, на их камни наценка под 20-30% только за марку, но оно того стоит.
    • +1
      >Изучайте SIMD инструкции, пишите свои оптимизированные модули на asm и подключайте их в свои проекты на том же С++ и все будет гуд.

      Проще уж на gcc перейти или на llvm+clang, правда последний пока отстаёт. Всё же рынок x86 совместимыми процессорами не ограничивается, а писать модули на asm для всех архитектур это тяжело
      • 0
        Мы сейчас говорим о дополнительных инструкциях. Интересно услышать мнение по поводу многоядерности.
        В целях совместимости опкоды SIMD инструкций как у АМД так и у Интел одинаковые. Что же относительно архитектуры параллелизма и компилятора от Интел — Parallel Studio?
      • 0
        Вы говорите, что LLVM+Clang отстает, а вот эпл в Барсике на него уже перешли с GCC. И под айфон им же компилируют, и OpenGL под Леопардом уже два года.
        • 0
          www.phoronix.com/scan.php?page=article&item=apple_llvm_gcc&num=1
          Вот, хотя здесь анализатор кода использовался тот же самый gccшный, но оптимизиуер всёравно бекенд, поэтому тест более менее объективен. Видно, что незначительно, но gcc отстает. В Леопарде, кстати, тоже я видел именно связку llvm+gcc при выборе компилятора.
          Было бы у меня многа времени, я бы попробовал для сравнения clang, благо в Линуксе он тоже работает, но пока просто не хватает свободного времени на его установку и настройку.
    • +3
      Программисты — это не бесправное инертное быдло. Достаточно какому-нибудь кадру уровня Джоэля толкнуть в бложике гневную статью с обоснованием, как это полмира айтишного на уши поставит. А там и журнашлюшки подтянутся, когда поймут, что новость настолько серьёзная, что можно публиковать, не боясь за рекламные бюджеты, ибо все вообще это опубликуют.
  • 0
    А нет никакой программки, чтобы скормить ей экзешник, а она сказала чем он был скомпилирован?
    • +4
      С этим должен справляться PeID. Можно также использовать сборку от cracklab
      • 0
        Интересующее приложение показало «Microsoft Visual C++ 8.0 DLL Method2 [Overlay]». Но доказывает ли это, что не использовался интеловский компилятор? Помоему нет.
        • 0
          dependency walker тоже много интересно может рассказать.
          • 0
            А как Dependency Walker может выявить ICC?
            • 0
              Надо смотреть, какие либы он прилинковывает, msvs обычно какой-нить C++ redist прилинковывает (что в Си делается не в курсе). Ну и minGW любит прилинковывать mingw10.dll
              На Линуксе icc свою тоже любит свои либы прилинковывать, в Виндовсе им не пользовался, нет бесплатной версии.
        • 0
          Ничего не доказывает, абсолютно. Public базы PEiD'а достаточно «шальны» и много фальшдетектов, если вам нужна хоть какая-то гарантия, лучше посидеть со штаммами самому (см. ниже).
        • 0
          Ничего не доказывает, абсолютно. Public базы PEiD'а достаточно «шальны» и много фальшдетектов, если вам нужна хоть какая-то гарантия, лучше посидеть со штаммами самому (см. ниже).
      • 0
        Прошу прощение за дубль ниже, опоздал, забыл обновить страничку. Целиком с вами согласен, более того сборка от cracklab'a будет оптимальнее в силу наличия там пользовательской базы сигнатур. * По памяти * определяет gcc (mingw), bcc, msvc.
      • 0
        На сборку от Cracklab жуутко ругается MSE.
    • 0
      PEiD + Extended signatures, либо TRiD + много/много поиска. А если не найдете что нужно — собираем несколько штаммом, компарируем, извлекаем маску отличий и добавляем в базу сигнатур для указанных выше программ.

      Ну и я, допустим, на глаз могу отличить gcc (mingw) от ms :)
  • 0
    Я например считаю, что Intel для Mac пошел на пользу. gcc генерировал для функций вида void foo(long long bar) что-то вроде:

    pop ax
    pop dx
    xor ax, ax!!!

    И еще было много приколов с прямым порядком байтов в слове. Хотя не могу сказать, что архитектура IBM была плохая.
    А по поводу почему амд не спешит писать компилятор — потому, что это сложно и не особо нужно. Тренд таков, что производители девайсов сами компилируют имидж ОС, а современный софт — это байткод под управляемый рантайм.
    • 0
      > а современный софт — это байткод под управляемый рантайм
      А как раз последнего меньшинство, всё ещё. Да и не редки случаи, когда ядро с обычным рантаймом, а модули и внешнаяя оболочка уже управляемые
    • 0
      xor ax, ax — это способ быстрого обнуления.
      Рекомендуется именно он, т.к. отрабатывает быстрее, чем mov ax, 0
      Может, конечно, на современных уже поменяли что-то, но я в этом сомневаюсь. mov ax, 0 — сама команда длиннее получается.
      • 0
        поинт в том, что это ошибка. из стека получил аргумент типа двойного лонга и тут же перетер половину, превратив его в обычный лонг
        • 0
          Не обратил внимание, думал наоборот в стек засовывает…
          В итоге коммент получился хотя и верным, но к делу не относящимся ;)
  • +1
    А как насчет CC?
    Лично я на платформах с AMDшными процессорами использую сановский компилятор.
    • 0
      А с ним как дела? Мне одни утверждали, что он лучше gcc, а другие, что наоборот, да и вроде открытую Солярку таки gcc собирают
      • 0
        Ну как с ним сейчас дела — я утверждать не могу (уже не слежу за этим), но на тот момент (2007 год) я прочитал кучу результатов тестирования — сановский был весьма показателен в плане производительности, в особенности если компилить с опциями под текущую платформу. Во всяком случае под оптероны — это лучшее на тот момент решение нежели GCC.
        C «cc» — конечно, ни все было гладко, например, ни все получалось им откомпилить. Тот же постгрис (8.1) «сс» ни в какую не хотел собирать…

        Если же говорить по теме, то вот статейка 2009 года
        blogs.sun.com/BestPerf/entry/free_compiler_wins_nehalem_race
        в которой аналогичная тема подымается.
  • 0
    Столько трёпа, а ни одна сволось не сравнила на AMD производительность известного (или неизвестного) приложения, скомпиленного под ICC в оригинале и пропатченного варианта с отключенной проверкой на Intel.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.