>Он итак там работает.

Его оттуда выгнали ссаными тряпками.

Даже они поняли, что Itanium не нужен!!

cetjs2 (22.12.2009 21:11:01)

а зачем это ГМ на армах?

cetjs2 (22.12.2009 21:57:49)

> в мидлсегменте ща тоже любят разные 64бит юзать а-ля оптероны (дешево и быстрее итаниумов)

Естественно, сейчас, когда любой бич может позволить себе трехгигарцеовый четырёхпроцессорный четырёхядерник по два потока на ядро, да на QPI, Itanium максимум двухядерный максимум 1.6 Ghz на FSB, выглядит неконкурентно. Однако, Itanium всегда был и остаётся абсолюным лидером по производительности одного ядра на гигагерц, даже с учётом плохих компиляторов (о них ниже). Дело ещё в том, что последняя реинкарнаяция Итаниума датируется 2006-м годом, считайте, 4 года не было обновления. Выход Туквиллы слишком затянулся. Дать бы Итаниуму QPI, 4 ядра, HT, хотябы 2.4 Ghz, это был бы абсолютный лидер по производительности. Но сейчас что есть, то есть.

>Дать бы Итаниуму QPI, 4 ядра, HT, хотябы 2.4 Ghz, это был бы абсолютный лидер по производительности.

Если бы у бабушки были яйца она была бы дедушкой.
IBM уже Power7 практически родила. У итаниума нет шансов, никаких. Хотя жалко конечно поделия, мне нравилась всегда продукция DEC и ее альфа %) У меня первый компьютер с юникс был таким (на учебе/работе, с ультриксом)

anonizmus (22.12.2009 23:04:59)

> К примеру: http://www.amd64.ru/index.php?link=2&addr=2&page=9&bench=850

Ты, мил-человек, Itanium с Xeon-ом перепутал, да ещё с таким старым...

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

Это неверно. Я приведу очень простой пример, настолько упрощённый, что он неверный, но смысл, надеюсь, будет понятен. Допустим, надо сложить А+В, и в зависимости от результата, вывести сумму A+C или B+C. Так вот, для Итаниума выгоднее будет cделать так : A+B; A+C; B+C; анализ результата; джамп в зависимости от результата. Итого : код уже на таком простом примере нечитаем (алгоритм просматривается не чётко), в любом более-менее сложном проекте человек со своим ассемблером запутается в соплях и не поймёт, что сам же нагородил уже через месяц.

> Да что Вы говорите?.. А кто это Вам сказал? А Вы им пользовались? И в чем же его ненормальность заключается, по сравнению скажем с ICC-32?

Тут дело не только и не стольво icc. Разработчики пользуются... чем только не пользуются, вплоть до IA32 на Итаниуме. Результат плачевен. EPIC не видно. Видно пародию на традиционное программирование, даже при использовании 64-х битного кода. По идее, компилятор для Итаниума должен генерировать паралленьный код на уровне команд. Я этого не видел ни разу. По слухам, компиляторами для Itanium в Intel занимались Бабаян и Ko, если это так, то я не удивлён результатом.

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

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

grim (23.12.2009 2:13:15)

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

>Это неверно. Я приведу очень простой пример, настолько упрощённый, что он неверный, но смысл, надеюсь, будет понятен. Допустим, надо сложить А+В, и в зависимости от результата, вывести сумму A+C или B+C. Так вот, для Итаниума выгоднее будет cделать так : A+B; A+C; B+C; анализ результата; джамп в зависимости от результата. Итого :

Забавно, но вы делаете в уме компиляцию, при этом утвердая что другим это не под силу. :)

grim (23.12.2009 2:16:19)

> Забавно, но вы делаете в уме компиляцию, при этом утвердая что другим это не под силу. :)

Вам выше уже сказали, что c = a + b оптимизировать и запрограммировать на ассемьлере можно и в уме, но в любом реальном алгоритме на 20 строк любой человек запутается. Это вам не x86, где за вас оптимизирует железный транслятор x86 кода в процессоре. Никто никогда не программирует на ассемблере критичные к производительности участки ни для RISC, ни для VLIW. Эти архитектуры как раз и создавались только для работы в паре с эффективным компилятором языка высокого уровня. Вообще-то, это фундаментальные знания, этому учат в университете и за незнание таких вещей на экзамене ставят три очка только по душевной доброте.

http://ru.wikipedia.org/wiki/RISC

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

Вот так, в ДЕСЯТКИ РАЗ? А подтвердить слова слабо?

> Никто никогда не программирует на ассемблере критичные к производительности участки ни для RISC

Не надо сказок, программируем, под ARM, самый настоящий RISC.

Кулю недорого ентрпрайзный морально умерший титаник. Неужели никто не заменит их в связи с новостью поскорее на x86_64?

sv75 (23.12.2009 3:22:00)

>Вот так, в ДЕСЯТКИ РАЗ? А подтвердить слова слабо?
Дитя, на слабо идите сверстников раскручивать.
Я же досточно открыто написал, что не уверен в надёжности информации.

grim (23.12.2009 4:16:15)

>Это вам не x86, где за вас оптимизирует железный транслятор x86 кода в процессоре.
:)
Вы видимо никогда не писали на х86 асемблере, раз такое пишете

>c = a + b оптимизировать и запрограммировать на ассемьлере можно и в уме,
Вам осталось сделать ещё один шаг и сказать, что просмотрев листинг компиляции, можно оценить уровень оптимизации компилятором оперции с=а+б

grim (23.12.2009 4:21:52)

Требую оживить PDP-11 !
Вот где ляпота была на ассемблере писать. Регистры общего назначения, прямая и косвенная адресация память-память, и т.д.

Удобней, чем на бейсике :)

ovax (23.12.2009 4:49:02)

> Я же досточно открыто написал, что не уверен в надёжности информации.

Это было не просто "не уверен в надёжности информации", это была конкретная, громкая и вонючая газификация водоёма (довольно крупного):)

Led (23.12.2009 4:52:15)

> Вы видимо никогда не писали на х86 асемблере, раз такое пишете

А Вы, видимо, зачем-то пиписьками решили померяться. Сейчас не в настроении, сори.

> Вам осталось сделать ещё один шаг и сказать, что просмотрев листинг компиляции, можно оценить уровень оптимизации компилятором оперции с=а+б

А Вам осталось осознать, что если вы можете в уме сложить 25 и 32, то это отнюдь не значит, что Вы с такойже легкостью в уме возведете одно это число в степень другого. Оптимально разложить сколько-нибудь сложный аглоритм на исполнительные блоки, грамотно разогнав конвеер - задача, которую в разумные сроки сделает только машина.

> Требую оживить PDP-11 ! Вот где ляпота была на ассемблере писать. Регистры общего назначения, прямая и косвенная адресация память-память, и т.д.

m68к такойже. Хоть из одной ячейки памяти в другую пересылай.

> Не надо сказок, программируем, под ARM, самый настоящий RISC.

Программируйте-программируйте, кто вам запретит. Каждый играет, как умеет.

> Кулю недорого ентрпрайзный морально умерший титаник.

На ebay загляните. Недавно пробегал четырехядерник с 32-ми гигами ОЗУ за тыщу баксов.

> Требую оживить PDP-11 !

Он жив и не кашляет! В виде MSP430

> Допустим, надо сложить А+В, и в зависимости от результата, вывести сумму A+C или B+C. Так вот, для Итаниума выгоднее будет cделать так : A+B; A+C; B+C;

Это и для любой суперскалярной архитектуры выгодно, в том числе и для x86. Поэтому команде CMOV на x86 сто лет в обед.

mv (23.12.2009 14:24:43)

> Никто никогда не программирует на ассемблере критичные к производительности участки ни для RISC, ни для VLIW. Эти архитектуры как раз и создавались только для работы в паре с эффективным компилятором языка высокого уровня.

Компиляторов чё-то не видно только... Векторные операции до сих пор руками быстрее пишутся.

Что касается инопланетности IA64, то ему нужен инопланетный же язык. Haskell, например. Я глубоко сомневаюсь, что для Си можно написать такой компилятор, который будет использовать мудрёный итаниумовский конвейер на полную катушку. Язык, на котором разговариает Итаниум, слишком мудёрный, посмотрите сами его референсы хотя бы вскользь. Всему вина недетерменированность обычных языков, у которых нельзя сказать, что там будет через сто тактов. У Хаскелля с его строгостью и декларируемым отсутствием сайдэффектов есть шанс. Конечно, человеческое умишко полностью безглючный компилятор даже для x86 написать не может, но есть хотя бы теоретическое обоснование возможности существования идеального компилятора. Даже для Итаниума.

mv (23.12.2009 14:38:58)

>А Вам осталось осознать, что если вы можете в уме сложить 25 и 32, то это отнюдь не значит, что Вы с такойже легкостью в уме возведете одно это число в степень другого.
Раз уж вас потянуло на аллегории, то могу привести ещё одну- Чтобы увидеть, что плика уложена качественно, совершенно не обязательно уметь её укладывать самому.

Возвести 2 числа в степень я могу на бумажке.
Точно так-же, можно на бумажке(или на компьютере) проверить качество оптимизации компилятора нарисовав регистровую и конвейерную модель

ps
Подумайте на досуге - кто пишет эти компиляторы.

grim (23.12.2009 17:01:43)

> Возвести 2 числа в степень я могу на бумажке.

Не сможете Вы возвести 25 в степень 32 на бумажке.

> Подумайте на досуге - кто пишет эти компиляторы.

Если кто-то способен написать программу вычисления факторила, это не значит, что он спобен вычислить в уме 1000! и проверить результат работы этой программе в уме.

Вопрос решён, теперь на Итаниуме будет доминировать SLES и всё под эту платформу будет писаться исключительно на mono!

Vudod (23.12.2009 19:17:10)

>Не сможете Вы возвести 25 в степень 32 на бумажке.
LOL

grim (23.12.2009 19:37:15)

Ни кто не знает, почему AMD сравнивает производительность ссвоих систем на Windows Server 2003 c Интеловскими на Windows server 2000...? Они б еще Win 95 взяли...

> Они б еще Win 95 взяли...

Для SPECint, SPECfp ось абсолютно параллельна, можно взять dos или linux, какая разница, xeon все равно в ж**е.

> Однако, Itanium всегда был и остаётся абсолюным лидером по производительности одного ядра на гигагерц.

Где об этом написано? Я Вам не верю.

> Где об этом написано?

Если бы Вы этим действительно интересовались, давно уже нашли бы нужные данные на SPEC.ORG.

CFP2006 base, peak
HP Integrity rx3600 (1.66GHz/18MB Dual-Core Intel Itanium) 19.6, 20.2
Dell Precision 690 (Intel Xeon 5160, 3.00 GHz) 15.3, 15.6
n4250QE (S4985) AMD Opteron 2222 SE 3.00Ghz 14.3, 15.2

> Это неверно. Я приведу очень простой пример, настолько упрощённый, что он неверный, но смысл, надеюсь, будет понятен. Допустим, надо сложить А+В, и в зависимости от результата, вывести сумму A+C или B+C. Так вот, для Итаниума выгоднее будет cделать так : A+B; A+C; B+C; анализ результата; джамп в зависимости от результата. Итого : код уже на таком простом примере нечитаем (алгоритм просматривается не чётко), в любом более-менее сложном проекте человек со своим ассемблером запутается в соплях и не поймёт, что сам же нагородил уже через месяц.

Какой нафиг джамп? Только условный мув!

>Ни кто не знает, почему AMD сравнивает производительность ссвоих систем на Windows Server 2003 c Интеловскими на Windows server 2000...?

А windows server 2003 был выпущен на архитектуре итаниум ?
Я просто как бы не в курсе.

anonizmus (25.12.2009 1:30:54)

> >Вот так, в ДЕСЯТКИ РАЗ? А подтвердить слова слабо?

> Дитя, на слабо идите сверстников раскручивать.

Дитятко, если ты не понял, я у тебя просил ссылки на источники. Надеюсь, так понятнее?

> Я же досточно открыто написал, что не уверен в надёжности информации.

Нет, про "надёжность информации" ты не писал. Ты писал про свою память. Любой человек, более-менее представляющий устройство современных CPU, перед выдачей такого перла просто сгорел бы от стыда.

> А windows server 2003 был выпущен на архитектуре итаниум ?

Итаниумы умели/умеют динамическую трансляцию х86 в их нейтив код (интел же).

>Итаниумы умели/умеют динамическую трансляцию х86 в их нейтив код (интел же).

Это ты так шутишь что-ли ? %))) Или в веществах ?

anonizmus (25.12.2009 20:09:41)