попались

[avva]

Любопытная новость: в Америке агентство по защите окружающей среды поймало "Фольксваген" на том, что они ставили в дизельные машины специальную программу. Эта программа определяла, когда машина проходит тест выхлопа (следила за работой двигателя, положением руля, итд.), и тогда включала режим очистки на максимум. А при обычной езде режим другой, и уровень загрязнения превышает разрешенный в 40 раз.

Теперь их обязали заменить 500 тысяч проданных за последние 7 лет автомобилей нескольких марок, и еще видимо оштрафуют на какие-то миллиарды.

Подробности напр. в: "Репутация Volkswagen задымилась".

ygam напомнил в одном из обсуждений, что это похоже на историю пятилетней давности уже из компьютерной индустрии. Тогда Интел поймали на том, что их компилятор выдает особо оптимизированный код, только когда его запускают на процессоре Интела, а на AMD генерирует код помедленней. То есть так: он смотрит на прошитое в процессоре имя вендора, и если это GenuineIntel, то делает всякие разные оптимизации в зависимости от того, что CPU реально поддерживает. А если нет, он никаких оптимизаций не делает, и для нового AMD выдает такой же код, как для древнего Pentium III.

Причем любопытно, что это так и не изменилось с тех пор. Вроде бы Интел заставили заплатить штраф и документировать это поведение компилятора, но он продолжает так себя вести. Год назад в реддите было обсуждение, и кто-то залез в свежую версию компилятора и проверил:



(это код, который ищет фразу GenuineIntel, и в зависимости от того, находит или нет, продолжает запускать разные процедуры оптимизации; если не находит, то оптимизации реально никакой нет)

Comments

Про Интел.

[sergey kuksenko (from livejournal.com)]

Вопрос оптимизации кода под процессор, это даже не вопрос выбора Instruction Set. Это больше вопрос лежащей ниже микроархитектуры.
Например, широко известно, что у всех интеловских процессоров есть некторые проблемы в декодере инструкций, одна из этих проблем размер immediate значения. 8-битные и 32-битные immediate интеловский декодер разбирает хорошо и быстро, а вот с 16-битными у него затык, медленный декодинг и т.д. Поэтому icc насколько можно (скорее всего на 100% - точно не знаю) избегает 16-битных immediate.
У AMD таких проблем в декодинге нет, и 8-16-32-битные immediate декодируются с одинаковой скоростью.
И таких микроархитектурных различий влияющих на производительность между Intel & AMD даже для общего Instruction Set вагон и маленькая тележка, и счет идет не на сотни, а на тысячи.
И естественно Intel не хочет разбираться во всех этих нюансах и генерить хороший код под AMD. И даже не сколько не хочет, а сколько не может. Внутренее устройство микроархитектуры у обоих компаний на 80% информация уровня супер-пурер-топ-сикрет, а по 20% публичной информации много не наделаешь.
Все вышесказанное не отменяет факт, что уж просто SSE без учета микроархитектуры для AMD можно было бы и сделать. Но сразу возникнет вопрос - где и как провести ту грань, что тут делаем, тут не делаем, а тут рыбу заворачиваем.

Re: Про Интел.

[krakenrus.livejournal.com]

> Но сразу возникнет вопрос - где и как провести ту грань
Это смотря кто проводит.
Если тот, кто решает, была ли подобная "отмена оптимизации для AMD" правомерна, то наверное лучше всего по-старинке - вызвать разработчиков, которые и расскажут под присягой, зачем так сделали. Потому что сложно технически или потому, что начальник приказал. :)

Re: Про Интел.

[sergey kuksenko (from livejournal.com)]

Конечно сложно технически. ;)
У нас есть код (X человеко лет) написанный Y лет назад и он работает. Чтобы сделать такую оптимизацию нужно Z (много больше X) человеко лет. Кто платит? ;) Вот пусть AMD и платит.