Обсуждение

Нужно все-таки учитывать при подсчете ФЛОПСов в этих архитектурах имеются в виду параллельные вычисления, но не все задачи просто параллелизовать, а некоторые очень трудно, а наверняка есть и такие, которые невозможно.

SGI обещали к концу года в стойке петафлоп, вот это чудо )

Честно говоря, зря как-то обижают архитектуру x86. ULV Core i процессоры эффективнее на ватт чем ARM под нагрузкой, а скоро и в простое не дадут себя обижать. Да, пока что у них нет ультрамногоядерных систем - вот будут 12 ядерные ксеоны по 8W на ядро 3Ггц + гипертред (т.е. много для каких задач это почти 24 ядра) + куча dmips/flops на Ггц + большой кэш + быстрая шина и при этом стандартная архитектура. При этом есть платы на 4 камня - это уже почти 200 потоков на 2U. И это не застарелый MIPS внутри, а куда более быстрый современный x86.

У Тилеры не ФЛОПСы, а просто ОПСы :). У них нет флоатинг пойнт вычислителей :). Так что они чисто для логических вычислений :).

архитектура х86 убогая как ни крути, но процессоры несмотря на это хорошие

Вот я тоже удивился, когда это увидел. Мне тоже показалось странным про флопсы при таком количестве ядер :) С другой стороны, я абсолютно прав, когда указал именно их в качестве лучшего харда на сегодня для логических вычислений. По $9 за ядро -- это не так уж много, если сделать правильную архитектуру доступа к памяти...

А что в ней такого убогого, пардон? Наследие старой совместимости?

Ну есть и другие архитектуры: Azul с 54 ядерными Жаба чипами, тот же GF100 от NVidia, FPGA "серверы" и т.д. Да и АМД с 12 ядерными процами уже неплохо выглядит, если штук 8 на плату запихать (ну и Интел тоже). Какой из них удобнее и выгодней - хрен знает. Чтобы оценить надо иметь софт, потому как непонятно какая архитектура лучше ложится на логические задачи (они ведь тоже разные). А софта нет.

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

Давайте не будем про полувековые давности. x86 появился в 79 году, MIPS в 81, а ARM в 83. Это все архитектуры одного и того же времени. Кроме того, считается как раз, что несмотря на сложность транслятора CISC-RISC, это дает массу преимуществ в производительности и в разработке. Да, это более крупная схема, чем ARM и тем более MIPS. Но при текущих размерах процессоров это значения почти не имеет.

30 лет назад - и есть "чуть ли не полувековой давности". Кроме того, считается как раз, что несмотря на сложность транслятора CISC-RISC, это дает массу преимуществ в производительности и в разработке. Да, это более крупная схема, чем ARM и тем более MIPS. Но при текущих размерах процессоров это значения почти не имеет. Это если на процессоре 4-8 ядер, а бОльшую часть занимает кэш - то может и не имеет. А если на чипе 100 ядер, то очень даже имеет, потому что надо уже 100 декодеров, да еще и скедъюлингом надо заморачиваться. Если Вам надо генерить код на лету - тоже очень плохо подходит, потому что компилировать в х86 медленно. К примеру, АРМ поддерживает расширения инструкций, в которую Жаба транслируется быстро и компактно, почти не теряя при этом производительности (в сравнении с трансляцией в РИСК код). Т.е. для современного серверного железа - многоядерного, с динамической генерацией кода, архитектура х86 - убогая. Для обычного десктопного софта - вполне себе подходящая, учитывая что именно на х86 самые быстрые и доступные процессоры. Тем не менее она все равно остается убогой, как ни крути. РИСКи кстати тут не являются сильно лучше. Но у них хотя регистров больше, и команды единообразнее. Благодаря этому у АРМ есть расширения инструкций, которые уже сильно лучше.

Вот это все теории, которые не подтверждаются практикой. Практика показывает, что процессоры с малым кэшом для большинства сегодняшних бытовых "датацентровских" задач не актуальны. А раз так, то ваши 1000 ядер на кристалле с мизерным кэшом и низкой производительностью в результате массовому пользователю не нужны. А нужно это на спец задачах с хорошей параллельностью и четким конвеером - например 3Д. Ну так там и не x86. В чем проблема? ARM пока что показывает исключительно компромисс между низким потреблением и нормальной скоростью. При этом, обладая большим набором средств, чем Атом, сливает даже ему, не говоря уже о Core i ULV. В общем я все к тому, что убогая или нет, а для центрального процессора это пока что лучшее из того что есть. И говорить устарело, убого неправомерно и необоснованно.

Я ведь не оспариваю тезис, что для центрального процессора это пока что лучшее из того что есть. Я полностью согласен. Тем не менее как архитектура х86 убогая. Да, лучшее из того что есть, сделано на убогой архитектуре. В этом есть определенная печаль, но это так :). А насчет задач, то этот топик как раз и посвящен тем задачам, для которых нужна другая архитектура, а не х86. Про массового пользователя речь не идет, он сидит на том, что ему впарили, тут все понятно (а ему впарили и х86, и GPU и АРМ). Однако, массовый пользователь не один такой, и есть много задач из серии Throughput Computing, где есть много маленьких подзадач, и важно не решить как можно быстрее каждую в отдельности, а чтобы в среднем решалось много таких задач в единицу времени. Здесь вобщем-то по барабану до скорости исполнения одного потока, зато имеет значение энергоэффективность, потому как можно больше ядер на чип разместить, и больше в пределах бюджета на энергопотребление, все это дает рост пропускной способности в целом. И им имеет значение удобство трансляции, потому что если код на лету генерить, то времени на его оптимизацию не так много. Я поэтому АРМ и считаю оптимальной для такого рода задач архитектурой. Тут конечно есть проблемы с доступностью - АРМ серверов-то нет. Может инженеры в АРМ не такие крутые как в Интеле. Может у них бюджета не хватает и т.д. Тем не менее архитектура у АРМ гораздо лучше.

Да ничего в ней убого нет. Я это и говорил. Она подходит для своих задач. Легаси тут непричем. Но я в общем немного подустал повторять. Кроме того, наблюдаются провалы в знаниях вопроса, которые я не могу пофиксить никак. И, да, многоядерные процессоры выгоднее делать на MIPS. И, к слову, ARM и MIPS сами фактически не выпускают процессоры - они сдают лицензию на ядра и обвязки на чипе. Так что, конечно мультиядерные MIPS уже не раз делались. Пару таких компаний я знаю. Обе уже умерли.

Подходит потому что обычные программеры на ассемблере не пишут, и код не генерят. Это за них делает компилятор. Поэтому они просто не сталкиваются с х86 напрямую. Но из этого не следует, что архитектура хорошая. Из этого следует, что обычных программеров ее убогости никак не касаются. Вот и все. А вот если стоит задача код генерить, то все убогости и всплывают. Пофиксить Вы тут ничего не сможете в принципе. Ссылки на компании, которые пытались делать МИПСы и померли то же не уместны. Тут ведь не обсуждается рыночная успешность той или иной архитектуры. Есть много компаний, которые пытались что-то делать, и у них это не получилось. Это не значит, что то что они пытались делать, было плохим. Так же из того, что у компании успешная на рынке, не следует, что она делает что-то хорошее. Это разные вещи.

Все я устал. У вас засело в голове слово "убогая" - вы никак просто не можете это мотивировать, а просто в это верите, не слушая аргументы. Вам надули в уши, что ARM это новое слово, современная архитектура, настоящий RISC. Мне это неинтересно, простите.

Почему убогая я писал в самом начале, не врите. Я писал, что она неудобная ни для кодогенерации, ни для исполнения на процессоре. Писал даже для каких задач, эти неудобства существенные. А Вы против этого ничего аргументировать даже и не стали. Просто писали, мол что х86 типа коммерчески успешная, и массовому юзеру ее достаточно для его задач. Ну это и так всем известно, что тут обсуждать-то?

Крайне интересный был еще такой Ambric 336 ядер и 1 Терафлопс - http://en.wikipedia.org/wiki/Ambric Правда, он в кризис пострадал. Интересен в частности тем что там можно пайплайны выстраивать.

ТераОПС конечно :)

Вот еще красавцы (с объяснением, почему они лучше "традиционных") на другом конце стоимостного спектра: http://www.greenarraychips.com/home/documents/greg/WP003-100617-msp430.pdf -- наши старые знакомые многоядерные Forth-процессоры.