Comments 48
По Вашей ссылке на Википедию очень символично соседствуют изображения «умирающего» Itanium и «перспективного» Эльбрус-4С, построенных на схожей архитектуре.
В своё время в широко известном в узких кругах ограниченных людей блоге «The old new thing» был цикл из 10 статей по архитектуре этого монстра (можно гуглить по «old new thing itanium processor part»). Я добрался до середины второй и там сломался. Неудивительно, что под него не появилось нормального оптимизирующего компилятора.
>> Я добрался до середины второй и там сломался
Вообще она и разрабатывалась чтобы удобно было компиляторы писать.
Экс-Эльбрусовцы его (компилятор) и писали.
Вообще она и разрабатывалась чтобы удобно было компиляторы писать.
Экс-Эльбрусовцы его (компилятор) и писали.
UFO just landed and posted this here
Примерно в годы создания Itanium некоторое количество разработчиков Эльбрус были раханчены Intel'ом. Думаю они внесли большой вклад в ход работы по всем аспектам Itanium. Кстати, некоторые потом вернулись.
Это инсайд :)
Это инсайд :)
ЦРУ смогло украсть наработки Эльбруса, но не смогли украсть программистов :)
ЦРУ то тут при чем?) Понимаю, что это сарказм, но мой коммент не имел конспирологического подтекста)
Программистов украсть как раз смогли (RTLщиков как минимум).
История давно была, еще до меня, нет точной информации, но слухи ходят разные и если хотя бы половина из них правда, то Интел:
1) Очень хотела этих разработчиков
2) Не принимает отказы :)
Программистов украсть как раз смогли (RTLщиков как минимум).
История давно была, еще до меня, нет точной информации, но слухи ходят разные и если хотя бы половина из них правда, то Интел:
1) Очень хотела этих разработчиков
2) Не принимает отказы :)
Ну что, я тогда буду ждать когда этим компилятором OpenJDK построят. Чтобы посмотреть как оно зааутперформит i386 железки обычные.
>> Бабаян, про которого вы скорее всего говорите, далеко не компиляторщик, а железячник, при этом далеко не самый лучший.
Нет, я имел в виду Андрея Боханко и других бывших сотрудников МЦСТ
Нет, я имел в виду Андрея Боханко и других бывших сотрудников МЦСТ
А вот у МЦСТ такие люди есть, и компилятор Эльбруса — это, без преувеличений, произведение искусства. Никакой LLVM, над которым кстати работает весь мир, еще даже близко не способен на то, на что способен компилятор эльбруса, который тоже не стоит на месте и постоянно развивается, с каждым годом становясь все лучше и лучше.
Тем обиднее, что эти люди работают над Эльбрусом, а не над LLVM...
И, кстати на что способен компилятор Эльбруса, с чем LLVM рядом не стоял?
UFO just landed and posted this here
Почему обиднее? Как только мировое собщество начнет контрибьютить в Эльбрус, эльбрусовцы начнут контрибьютить в мировое сообщество, в т.ч. в LLVM.
Потому что Эльбрусом пользуются 2.5 человека, а LLVM — миллионы
С такой логикой до сих пор бухгалтерскими счётами бы пользовались.
Как только мировое собщество начнет контрибьютить в Эльбрус
Открывать свои собственные разработки, такие как компилятор LCC, фирма не планируетНу и о чем это вы?
UFO just landed and posted this here
Мне в этом контексте интереснее, что означает фраза «эльбрусовцы начнут контрибьютить в мировое сообщество».
UFO just landed and posted this here
Не, не стало.
Я понимаю, чего хотелось бы МЦСТ (или как правильнее назвать — сообщество разработчиков Эльбруса?) от мирового сообщества.
Я понимаю, что такое вклад в опенсурс.
Я не понимаю, каков будет этот вклад от МЦСТ, если открытия их разработок не планируется. МЦСТ выделит оплачиваемые часы для работы над LLVM? Или разработчики Эльбруса начнут это делать частным порядком (а сейчас что мешает?)?
Я не в порядке наезда, я действительно не понимаю. Можете описать подробнее: что именно, по вашему мнению, может законтрибьютить фирма, если свои разработки она открывать не собирается?
При этом вроде бы понятно, что частная инициатива разработчика тут не очень причем (или я ошибаюсь?) — в свободное от работы время ему никто не мешает писать куда угодно, лишь бы NDA соблюдал.
Я понимаю, чего хотелось бы МЦСТ (или как правильнее назвать — сообщество разработчиков Эльбруса?) от мирового сообщества.
Я понимаю, что такое вклад в опенсурс.
Я не понимаю, каков будет этот вклад от МЦСТ, если открытия их разработок не планируется. МЦСТ выделит оплачиваемые часы для работы над LLVM? Или разработчики Эльбруса начнут это делать частным порядком (а сейчас что мешает?)?
Я не в порядке наезда, я действительно не понимаю. Можете описать подробнее: что именно, по вашему мнению, может законтрибьютить фирма, если свои разработки она открывать не собирается?
При этом вроде бы понятно, что частная инициатива разработчика тут не очень причем (или я ошибаюсь?) — в свободное от работы время ему никто не мешает писать куда угодно, лишь бы NDA соблюдал.
Объективно, у Эльбруса шансов захватить рынок нет. У революционных идей, которые, по вашим словам, содержаться в его компиляторе — возможно, но их же практически никто не видел -_-
К счастью есть госзаказ. Рынок обычно захватывает УГ.
UFO just landed and posted this here
UFO just landed and posted this here
Объективно, на равне с Intel+AMD у Эльбруса шансов захватить рынок нет.
То есть не делаем, чтобы покупали, а покупаем, чтобы делали?
Я считаю что рынок в искусственной регуляции не нуждается, и если продукт никто не покупает, то он никому не нужен. Если же он хорош с теоретической точки зрения, то и заниматься им надо в институтах, на гранты, с полной публикацией результатов.
UFO just landed and posted this here
И без помощи государства, без регуляции рынка, у него нет шансов.
Я утверждаю, что и с помощью государства у него шансов нет, кроме как производиться для того, чтобы было чему помогать.
Эльбрус, оставший от интела на 15 лет, явно не в таких условиях.
Но ведь он никогда Intel не догонит? С этого я и начал. И потому, как в продукте, смысла в нем нет.
UFO just landed and posted this here
После ваших комментариев мне очевидно, что вы не понимаете и не хотите меня понимать. Поэтому предлагаю закончить этот, теперь уже бессмысленный, разговор.
Я и правда не понимаю, что вы пытаетесь сказать, но и вы, как мне кажется, не совсем меня поняли.
Я хотел сказать, что с моей точки зрения, было бы гораздо круче, если бы крутые ребята из Эльбруса пилили что-то, чем пользуется весь мир, по сравнению с Эльбрусом, у которого, имхо, перспектив нет. Все это сугубо личное мнение, а не истина в последней инстанции.
Если ничего не делать, ведь вы именно это предлагаете, то конечно не догонит.
Я имел ввиду чисто физически, пока интел продолжает работать, отставание во времени не уменьшается -_-
1,2 и 5 обычные процессоры делают в динамике, когда у них заведомо больше информации. 3 не нужно благодаря предсказателям ветвлений, которые позволяют не выполнять лишней работы.
Не надо путать «не могут» и «не хотят париться бесполезной фигней».
Не надо путать «не могут» и «не хотят париться бесполезной фигней».
UFO just landed and posted this here
Зачем мне научная степень, чтобы использовать логику?
VLIW компилятор переделывает под
Даже если по факту cond() выполняется раз в год, процессор будет считать и f1, и f2, потому что VLIW не может в ветвления, а так код параллелится лучше. Откуда экономия энергии?
Или такой код:
Обычный ОоО сделает так:
In-Order процессору придется делать так:
При той же степени сокрытия задержек памяти, код на VLIW в пять-десять раз больше, значит при прочих равных потребует гораздо больше кеша инструкций, который самый дорогой кремний на чипе после регистрового файла и TLB-кеша. Причем, наращивать его бесконечно всё-равно нельзя, поэтому миссы в кеше инструкций заведомо будут чаще, чем у ОоО собрата, так что зачастую всё ядро будет крутить такты впустую. Такая-то экономия.
Ну и еще не получится выполнять сложения одновременно с загрузкой данных, но это уже ерунда относительно.
float x = (cond()) ? f1(y) : f2(y);
VLIW компилятор переделывает под
float x' = f1(y), x'' = f2(y);
float x = (cond()) ? x' : x'';
Даже если по факту cond() выполняется раз в год, процессор будет считать и f1, и f2, потому что VLIW не может в ветвления, а так код параллелится лучше. Откуда экономия энергии?
Или такой код:
float s = 0;
for (int i = 0; i < 16; ++i)
s += d[i];
Обычный ОоО сделает так:
reg0 = 0;
[какой-то ассемблер для цикла for]
load(reg1, d[i])
add reg0, reg
In-Order процессору придется делать так:
reg0 = 0
load(reg1, d[0])
...
load(reg16, d[15])
add reg0, reg1
...
add reg0, reg16
При той же степени сокрытия задержек памяти, код на VLIW в пять-десять раз больше, значит при прочих равных потребует гораздо больше кеша инструкций, который самый дорогой кремний на чипе после регистрового файла и TLB-кеша. Причем, наращивать его бесконечно всё-равно нельзя, поэтому миссы в кеше инструкций заведомо будут чаще, чем у ОоО собрата, так что зачастую всё ядро будет крутить такты впустую. Такая-то экономия.
Ну и еще не получится выполнять сложения одновременно с загрузкой данных, но это уже ерунда относительно.
UFO just landed and posted this here
Это еще почему процессор будет считать это каждый раз? И кстати, а что в этом случае сделает суперскаляр?
Потому что в этом идея VLIW, мы фигачим обе ветки исполнения параллельно, а потом отбрасываем не оправдавшую себя и за счет этого выкидываем сложный предсказатель ветвлений, не ломая конвеер на каждом ифе. Если это не использовать, то в чем вообще смысл широкого слова?
Суперскаляр здесь запомнит, что cond() в 95% случаев возвращает true или false и даже не будет задумываться о более редкой ветке, таким образом не тратя регистры, место в кешах и не прогревая воздух бесполезной арифметикой. Даже если он будет ошибаться в 50% случаев, это всё еще лучше чем что бы там ни соорудил компилятор в статике.
Скажите пожалуйста, сколько подобных реалтаймовых, реализуемых в железе, алгоритмов вы знаете?
Но совершенно очевидно
Да он по факту один и есть. https://en.wikipedia.org/wiki/Tomasulo_algorithm За 60 лет к нему добавили возможность выполнять условные переходы до того, как стало известно, выполнилось ли условие (собственно, спекулятивное исполнение), убрали ложные зависимости, когда две инструкции пишут в разные половины одного регистра, да еще load после store по одному указателю ни в кеш, ни в память может не лезть. Сами же написали, ресурсы ограниченные, ничего реально сложного туда не запихнешь.
Ну, мне это не совершенно очевидно. Как минимум, кеш тупо занимает больше места на кристалле, чем N узко строго специализированных под нужны планировщика регистров. Но точных замеров у меня нет, может вам и очевидно.
выполняет железо, компилирующее x86 код в микрокод.
Это вообще вещь ортогональная, что x86, что ARM делают это из-за трейд-оффа между плотностью инструкций и сложностью вычислительных конвееров (ну и обратной совместимости, конечно). Не очень, знаете, приятно, когда код, в котором слишком много делений, превращается в томик Войны и мира на ассемблере.
компиляторами для VLIW'ов, у которых, фактически, бесконечное количество ресурсов и времени.
Проблема предсказания переходов решается с помощью статического предсказателя, профилировки, спекулятивного и условного исполнения, глобального планирования исполнения кода.
1) Половина задач, которые решает компилятор — вообще NP-полные. Любые «сложные» алгоритмы — это такой брутфорс с амбициями. Т.е., допустим, Skylake имеет reordering buffer на 211 микроопераций, а компилятор VLIW (очень условно) сможет что-то оптимайзить с окном 400 инструкций, но без рантаймовой информации. Попробуем взять больше — никаких бесконечных ресурсов не хватит, чтобы перемолоть что-то длиннее hello world. И компилятор не может предсказать, что переменная A будет находиться в L1, переменная B в L2, а переменной C даже в TLB-кеше не будет.
2) Профилирование — это всегда здорово, но только одно дело, когда мы переписываем на ассемблере всякую экзотику типа битового упаковщика для архиватора, потому что никакой компилятор не догадается использовать специальные инструкции для этого, а другое — вести проц за руку на любом нетривиальном участке кода. Причем, когда выйдет новое поколение, у которого регистров на 40% больше или там буфер для предзагрузки не два килобайта, а четыре, это придется проделывать заново, иначе новенький чип новообретенные ресурсы использовать никак не сможет и окажется быстрее старого процентов на 20, а это полнейшая ересь. И это еще если программа в исходниках доступна.
Я ничего не имею против существования Эльбруса, понимаю, почему он представляет собой то, что представляет, но VLIW — это вещь изученная и опробованная. Ничего кардинально нового тут не придумать.
Проблема с компилятором там ровно одна. Машина очень чувствительна к качеству планирования кода, а код хорошо спланировать можно только зная его динамическое поведение (по каким путям ходили, где стояли и ждали загрузки из памяти и т.д.). В итоге получается, что если угадали, то всё хорошо, если не угадали, то всё плохо. И это достаточно фундаментальное ограничение архитектуры.
В остальном архитектура была очень красивая и приятная.
В остальном архитектура была очень красивая и приятная.
У архитектур с сильным распараллеливанием (это касается и многоядерных процессоров), есть ещё одно фундаментальное ограничение, согласно которому, машина с одним исполнительным блоком, работающим на частоте v*N, будет всегда эффективнее машины, с числом N исполнительных блоков, работающих на частоте v.
UFO just landed and posted this here
В угоду титанику HP полностью свернули производство процессоров Alpha (не плохой камень был...). Перевели VMS на титаник (следует отметить: говно отменное получилось)
Что теперь с VMS? Хоронить с музыкой будут, или на х86 перетаскивать?
Что теперь с VMS? Хоронить с музыкой будут, или на х86 перетаскивать?
Ализар.
Заголовок: Процессор Intel Itanium официально умер
Текст статьи: Вчера начались поставки новой модели процессоров Intel Itanium.
Заголовок: Процессор Intel Itanium официально умер
Текст статьи: Вчера начались поставки новой модели процессоров Intel Itanium.
Кстати, а с точки зрения системы команд Итаниум лучше других архитектур? Есть там какие-то интересные оригинальные решения?
Где бы почитать об этом?
Где бы почитать об этом?
А хоть приблизительно известно, сколько стоит процессор? Т.е. тот же серверный Xeon/Opteron в среднем от 500 до 2к вечнозелёных. А Итаниум сколько стоит?
На новое поколение пока цены не выложены в паблик. Топовый процессор предыдущего поколения:
Intel® Itanium® Processor 9560 32M Cache, 2.53 GHz — Recommended Customer Price $4650.00
Источник.
Intel® Itanium® Processor 9560 32M Cache, 2.53 GHz — Recommended Customer Price $4650.00
Источник.
Ну к примеру если взять ebay то серверы десятилетней давности на itanium'е в 4-5 раз дороже своих ровесников на xeon'ах.
Sign up to leave a comment.
Процессор Intel Itanium официально умер