ИМХО звучит многообещающе...
Но МАК все равно отстой

Вот наконец и долгожданный G5 Apple.
Теперь на 64bit-процессорах IBM с частотой 2ГГц.

Ура, господа! Ура.

Все прекрасно, но где официальные тесты на spec.org ?

Stranger_NN

Они их боятся по старой памяти. Фобия. Или не могут пришпандорить IBM-овский транслятор к своей системе ?

Кстати, что это, извините, за лажа кочует из новости в новость:

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

Какие "старшие биты в инструкциях" ? Инструкции в 64-битовой архитектуре PowerPC, насколько мне известно, имеют 32-битовую длину (а какую же еще ?). Да и "старшие биты в данных" игнорировать никак нельзя ...

Это действительно лажа?

Vogt

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

Допускаю, что имелось в виду что-то разумное - но в таком случае изложено косноязычно и запутанно ...

bess
Я не считаю, а спрашиваю на сколько это верно?

Vogt

На этот вопрос нет ответа. Поскольку исходная фраза, IMHO, написана несуразно. Собственно, я и задал вопрос в расчете на то, что кто-нибудь видел объяснение или хотя бы первоисточник (на языке оригинала)

bess
Здесь я не нашёл. Может, плохо смотрел?
Если нет, тогда здесь.

KBAKEP

То-то и оно. Зато здесь об этом говорится из раза в раз. Подозреваю, что они просто скопировали фрагмент из своей-же старой новости про PPC970. Значит, надо искать первоисточник того времени

Либо лыжи не едут, либо я.

Циферки из новости:

Dell Precision 650, SPEC FP base 646, SPEC Int base 836.

Теперь смотрим сюда - http://www.spec.org/cpu2000/results/res2003q2/

Хорошо Apple начинает, ничего не скажешь .

Itanium и все-все-все..., #1098
solyahoff
в тестах Apple/Veritest использованы полные настройки компиляции под П4 и Xeon: SSE2 включен опцией -march=Pentium4
Насчёт "-march=pentium4", эта опция реализована в gcc очень плохо, весь интернет заполнен сообщениями об глюках при её включении. Кроме того народ жалуется, что в отличие от icc особого прироста в скорости не получается в gcc при включении SSE2. То есть SSE2 у gcc очень хромает. Кстати, там был ключ "-mfpmath=sse"?

HyperThreading включен для однопроцессорного П4 3ГГц, выключен для двухпроцессорного Xeon за вредностью при изначальной многопоточности задач SPEC2000_rate.
Что, сама Apple решила, что вредно, а что полезно Intel-овским процессорам?
Тогда всё ясно...

А про ICC7 ж все сказано -- заточен именно под задачи СПЕК по самое нехочу.
То что он заточен под SPEC, повторюсь, это только хорошо, тут нет ничего противозаконного. Каждый производитель железа имеет право использовать все возможности этого железа на все 100%. Если это, конечно, не в ущерб качеству. Но тут об этом речи нет, тесты численные и проверки на правильность и точность имеются.

Никакие другие задачи он с таким отрывом, как отмечалось, не компилирует
Кем, когда и как отмечалось? Где доказательства? По моему опыту, на реальных задачах, он именно так и быстрее gcc.

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

Делайте выводы сами -- никаких спекуляций и инсинуаций.
Ню-ню...

Кстати, там был ключ "-mfpmath=sse"?

Избыточен. А то, что там в версии 3.3 все хромает при том, что в большей степени "оупен сорс комьюнити" занимается именно Интелем и на Интеле, верится с трудом. Сообщения о сплошных глюках явно тенденционзны.

Что, сама Apple решила, что вредно, а что полезно Intel-овским процессорам?

В данном случае, да, поскольку результат компиляции стал только медленнее от этого, о чем Джозвяк и сказал.

Кем, когда и как отмечалось? Где доказательства? По моему опыту, на реальных задачах, он именно так и быстрее gcc.

Смотрите на теме, с которой нас "выгнали", ссылки на сравнение компиляторов iXBT. По этому вопросу там кое-что есть.

Добавление от 26.06.2003 01:18:

Строго говоря, про заточенность ICC7 под SPEC итак все ясно: если гововые результаты и не записываются в скомпилированных код задач теста (нигде не доказано), то побайтовая, побитная ручная заточенность, которая в принципе невозможна при компиляции иных приложений -- самое то; именно это имеет ввиду эксперт из Microprocessor Report.

Вы, к тому же, явно переругали GCC (при том, что, повторюсь, обычно код его медленнее). Этот компилятор используется для реального применения много лет, и отставание его на компиляции обычных приложений, а не СПЕК, не велико, а в ряде случаев его нет вовсе.

solyahoff

> А про ICC7 ж все сказано -- заточен именно под задачи СПЕК по самое нехочу. Никакие другие задачи он с таким отрывом, как отмечалось, не компилирует, хотя и выпускает, по жизни, более быстрый код, чем GCC.

Опять у вас жуткая ересь. SPEC CPU - это ДЕСЯТКИ ТЫСЯЧ строк кода (могу привести разблюдовку или дать ссылку на статью). Все программы СОВЕРШЕННО разные. Все транслируются с ОДИНАКОВЫМИ опциями (SPEC_base). И, надо сказать, другие задачи по жизни с использованием их трансляторов считаются быстрее, чем с другими. В сравнении с Портландом - процентов на 5, с GCC/G77 - раза в полтора

В общем, КРУЧЕ теста вам не придумать (хотя это не гарантирует его абсолютную применимость, конечно).

> именно это имеет ввиду эксперт из Microprocessor Report

Пожалуйста, дайте ссылочку. А заодно разъясните вашу инсинуацию подетальнее

bess
http://zdnet.com.com/2100-1103_2-1020015.html
Очевидно этот кусочек:
Peter Glaskowsky, editor in chief of Microprocessor Report, said Apple's benchmarks appear to put it ahead of PC manufacturers for now.

"By August, there won't be anything on PC platforms that will be faster," Glaskowsky said, adding that he was particularly impressed with Apple's benchmarks for floating point performance, which measures how quickly a computer can calculate numbers with decimals.

solyahoff
А то, что там в версии 3.3 все хромает при том, что в большей степени "оупен сорс комьюнити" занимается именно Интелем и на Интеле, верится с трудом. Сообщения о сплошных глюках явно тенденционзны.
Может, конечно, и все комьюнити занимается "Интелем и на Интеле", и, может, конечно, факты и тенденциозны... Только вот реальные факты из жизни (так, для примера):

• xfree86 крайне не рекомендуется собирать с -march=pentium4 - шансы на получение неработоспособной софтины близки к 100%
  
• mozilla не собирается с -msse2, -march=pentium4 крайне не рекомендуется
  
• kde крайне не рекомендуется собирать с -march=pentium4
  
• glibc и самого gcc крайне не рекомендуется собирать с -march=pentium4
  

Это все по мнению девелоперов gentoo - source-based дистрибутива линукс. Они имеют весьма приличный собственный опыт, плюс очень немаленькую статистику от пользователей дистра. Делайте выводы....

solyahoff
Сообщения о сплошных глюках явно тенденционзны.
Да, конечно, а весь этот народ просто так жалуется:
http://www.google.com/search?sourceid=navclient&ie=U…%22+Pentium4+SSE2+

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

Смотрите на теме, с которой нас "выгнали", ссылки на сравнение компиляторов iXBT. По этому вопросу там кое-что есть.
Да, вот специальный обзор о компилировании SPEC в Linux:
http://www.ixbt.com/cpu/insidespeccpu2000-compilers-add2.shtml
Выводы:
- Включение P4 оптимизаций в gcc в лучшем случае ничего не меняет, только один тест ускоряется, а остальные даже замедляются!

- gcc намного уступает icc, во всех тестах, иногда в разы:

- SPEC под Windows быстрее, чем под Linux:

Наверное Вы какое то другое сравнение читали :lol.

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

Строго говоря, про заточенность ICC7 под SPEC итак все ясно: если гововые результаты и не записываются в скомпилированных код задач теста (нигде не доказано), то побайтовая, побитная ручная заточенность, которая в принципе невозможна при компиляции иных приложений -- самое то; именно это имеет ввиду эксперт из Microprocessor Report.
Ну ка, ну ка, про это поподробее, особенно про "побитная ручная заточенность"!

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

RedAndr Ufa HZTeam
Так что, опять повторюсь, Apple для сравнения взяла худший компилятор, у которого толком нет оптимизаций, с худшими настройками, без быстрых библиотек (про себя то они не забыли) и на худшей OC. Естественно, что результат предсказуем, конкурент "разбит в пух и прах".


solyahoff

Верно Вы заметели -- Хеоны то "новые", конечно они с HyperThreading.Учите мат часть. "Старые" на основе р4, тоже с HyperThreading

Это он про то, что СПЕК_рейт это многопоточный и многопроцессорный тест, и ГиперТрединг, как я и предполагал, только ухудшил результаты.
А Вы не верьте всему, что на заборах пишут, Вы сами проверьте, тем более что на этом сайте показано, что это не так. Скажите спасибо RedAndr Ufa HZTeam - он уже поиск для Вас сделал.

использованы полные настройки компиляции под П4 и Xeon: SSE2 включен опцией -march=Pentium4, HyperThreading включен для однопроцессорного П4 3ГГц
Вам же даже Ваш кумир сказал, что хоть SSE2 включен, но компилятор не умеет делать vectorised SSE2 instructions.

А про ICC7 ж все сказано -- заточен именно под задачи СПЕК по самое нехочу. Ну, приведите хоть раз ссылку, где и кем это сказано (кроме Вас). Буду очень Вам признателен. Хотя bess Вам уже также ответил…

Делайте выводы сами -- никаких спекуляций и инсинуаций.Ну, Вы и нахал Первая часть предложения строго противоположна второй

побитная ручная заточенность
А мы хоть надеялись, что Вы понимаете что пишите

RedAndr Ufa HZTeam
Если б этот компилер продавался, а не распространялся бесплатно в составе ОС, то он давно бы уже загнулся.

Ещё по поводу подтасовок Apple. На G5 они компилировали с ключём "-ffast-math", однако на Dell без него! Понятно, к чему это привело .
http://www.haxial.com/spls-soapbox/apple-powermac-G5/

Alek Zander

> Очевидно этот кусочек: ...

Да нет, Mr. solyahoff имел в виду какое-то "разоблачение" трансляторов фирмы Intel Довольно забавная у него манера - вместо того, чтобы предоставлять доводы, даются глубокомысленные намеки и туманные отсылки к чужому мнению

Для Бесс и Ко:
http://www.ixbt.com/video2/antidetect.shtml

не делайте вид, что вы не догадывались, как это делается. Только вот не надо писать про "десятки тысяч строк кода", про сверхгениальность компилятора Интеля. Кстати, я писал не про "туманные остылки", а совсем на конкретное мнение:

Peter Glaskowsky, editor-in-chief of Microprocessor Report, said a company could get better benchmark results using a Dell machine with Intel and Microsoft compilers than with a Linux machine and GCC compiler. However, he also noted that Intel's chips perform disproportionately well on SPEC's tests because Intel has optimized its compiler for such tests.

Знаю, знаю, сейчас вы напишите, что главный редактор МР ламер, и вообще был подкуплен Джобсом оклевать священную Интель, и не менее священный компилятор ICC7.

А сравнение ICCvsGCC, между прочим, устарело, равно как и нерекомендации поставщиков ПО относительно GCC к версии 3.3 не имеют никакого отношения, тем паче, что оптимизация компиляции именно П4 -- главные приоритет там. Ну нету ничего здесь сказать против этого, Бесс. Сорри.



ISA_User:
Старый Xeon БЫЛ без ГТ -- учите матчасть.

Добавление от 26.06.2003 23:59:

Сорри, не устпеваю; отвечу позже на все пункты, скучно не будет.

Исправлено: solyahoff, 27.06.2003 00:06

solyahoff
Может хватит уже одну и ту же цитату мусолить? У вас есть факты, подверждающие, что Intel делает что-то некорректное при компиляции тестов SPEC?
A вот примеры того, как icc дает значительно лучший код, чем gcc имеются.

А сравнение ICCvsGCC, между прочим, устарело, равно как и нерекомендации поставщиков ПО относительно GCC к версии 3.3 не имеют никакого отношения, тем паче, что оптимизация компиляции именно П4 -- главные приоритет там. Ну нету ничего здесь сказать против этого, Бесс. Сорри.

solyahoff

Похоже, вы опять судите о том, чего не знаете. Вы хоть щупали руками какие-нибудь из перечисленных трансляторов ? Вы хоть понимаете, что public domain трансляторы (в том виде, в каком они сейчас развиваются) не могут В ПРИНЦИПК генерить по-настоящему приличный код. Потому как приличный код можно генерить, лишь строя модель поведения процессора с потактовым расписанием.И вырабатывать инструкцию SSE2 вместо x87 для этого совершенно не достаточно. Само собой, я буду несказанно рад, если в один прекрасный момент обнаружится, что модель сменилась и теперь трансляторы GNU CC & Fortran заработают с правильной скоростью. Но пока этим не пахнет - особенно GNU Fortran.

BTW, вы не изволили прокомментировать мои ответы на ВАШИ вопросы. Впрочем, дело ваше

solyahoff
Сорри, не устпеваю; отвечу позже на все пункты, скучно не будет.
Давайте, ждём с нетерпением .
Пока же насчёт заточек от nVidia, то такие сравнения с ними некорректные. nVidia ускорила работу за счёт изменения результатов работы теста и, соответственно, ухудшения качества. В численных тестах, каким является SPEC, такое невозможно. Искажения результатов, потеря точности сразу станут видны, это Вам не картинка с кучей деталей, изменение которых можно заметить только при рассматривании увеличенной статической картинки. А все изменения, которые ведут только к ускорению при неизменности получаемых результатов, являются оптимизациями, которые допустимы и даже желательны. Например тут http://gcc.gnu.org/ml/gcc/2003-03/msg01674.html указано, что один из тестов SPEC2000 252.eon работает с ошибками при компиляции gcc 3.3 при включении оптимизаций ключём "-O3". Ещё про gcc и SPEC200: тут http://gcc.gnu.org/ml/gcc/2002-06/msg01272.html пишут, что новая версия gcc компилирует более медленные тесты, причём агрессивные оптимизации приводят к более медленному коду. Ну и так далее, проблем у gcc море, а производительность так себе.
Замедлить тест очень просто, ускорить же его работу несоизмеримо сложнее. Apple решила пойти по первому, простейшему пути, замедлила работу теста на конкурентной платформе, вместо того, чтобы работать над оптимизациями собственных программ, компиляторов и железа.

Исправлено: RedAndr Ufa HZTeam, 27.06.2003 00:31