процессорное

[netch80]

Может, баян, но я для себя ещё не формулировал.

Общеизвестная критика Intel с позиции "этот ваш x86 полный отстой, надо было делать как в ARM/MIPS/etc., конверсия во внутренний RISC не нужна, команды разбирать слишком дорого", которой полны соответствующие форумы - обычно заканчивается тем, что оппонент или стихает, или переходит в режим "от обоснуя слышу" и на этом обсуждение заканчивается якобы победой критика.

Но я ни разу не видел возражения на это, что RISC, VLIW, etc. организации банально нерасширяемы. Да, иногда цена расширения велика - начиная от тотального OOO+Tomasulo во внутренней логике (дорогая таки штука) до префиксов на каждую операцию (в x86-64 коде, ~38% всех команд с префиксом REX, и это я не считал те, у которых он подразумевается из-за единственности сути), но она подъёмна и, главное, перспективна в плане сохранения совместимости с существующими готовыми продуктами. X86-32 пережило даже внедрение AVX:) и умирать не собирается.

Отсюда обратный вывод - что x86 живо только пока идёт бурное развитие (по закону Мура). Как только последний остановится, она потеряет преимущество и лет за 10 уйдёт в ноль; но пока рост есть - она непобедима. Закон Чёрной королевы в действии.

Но странно другое. Практически каждое архитектурное решение Intel это в лучшем случае оптимальность на один шаг вперёд, уже через два шага побочные эффекты сиюминутной выгоды становятся явными недостатками. Результат выглядит как корабль, слой ракушек на котором в несколько раз толще ширины корабля. Зачем? Я не верю, что у них так плохо с мозгами.

Comments

[netch80.livejournal.com]

> "кривы в арифметике" - это как понимать ? векторные вычисления в power* появились, кажется, раньше, чем в х86 расширениях.

Я не про Power, а про S/360 с потомками (zSeries, а не pSeries).
Например, банальная для всех архитектур начиная с PDP-11 операция "выполнить длинное сложение цепочкой команд ADC" на S/360 напрямую невозможна. Ну нету на ней аналога такой команды. Набора флагов NZVC нет, есть двухбитовое поле, которое принимает одно из 4 значений; например, для сложения это "0 - результат равен 0, 1 - меньше 0, 2 - больше 0, 3 - было переполнение в дополнительном коде, а что там ещё кроме этого было - мы вам не скажем". И даже в последних это не исправляли (видимо, считают несущественным). Соответственно написание для них на низком уровне это очень непривычная задача.

Что-то подобное, кстати, есть у MIPS и Alpha - у них тоже нет понятия condition codes. Но Alpha вообще адский уродец в этом смысле. Например, задача записать 1 байт в память там выполняется через: прочитать слово из памяти; выставить в нём конкретный байт с помощью масок и сдвигов; записать слово в память.

> Архитектуры Alpha , MIPS (серверная) и HP-PA были искусственно убиты в рамках соглашений с Интелом о совместном (с НР) выпуске Итаниумов и выпуске серверов на них.

Про MIPS - не верю. Убить его так совсем невозможно, что видно по тому, что он жив и сейчас, и его продолжают развивать и расширять. Alpha и HP-PA скончались потому, что тянуть их дальше стало катастрофически невыгодно - не расширяемы, не переносимы без потери существенного качества на новую базу. Даже AMD'шный уродец x86-64 оказался лучше Альфы. HP-PA ещё хуже - типичный VLIW ещё и в слабо продуманной версии (IA-64 и то был лучше, но тоже не выдержал). В современном мире специалистов не хватает даже на развитие одной x86; куда уж другие тянуть?

[iskatel.livejournal.com]

>>Про MIPS - не верю. Убить его так совсем невозможно, что видно по тому, что он жив и сейчас, и его продолжают развивать и расширять.

Он жив в виде ядер для сетевых устройств, от многоядерных мощных провайдерских до домашних коробок. С серверного рынка его убрали через манагерские соглашения с SGI .
Точно так же убрали и Альфу, потом АМД и шину лицензировала, и спецов к себе приняла, появление прекрасных (на то время) процессоров К серии - во многом заслуга альфовцев.

>>Даже AMD'шный уродец x86-64
В 64 хотя б память можно нормально адресовать, а не так извращённо, как в классическом х86.

>>Alpha и HP-PA скончались потому, что тянуть их дальше стало катастрофически невыгодно - не расширяемы

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

>>IA-64 и то был лучше, но тоже не выдержал

С ним интересно было.
Сначала Интел договорилась об убирании конкурентов, потом, прямо на старте, сами же интел-манагеры прибили сектор IA-64 рабочих станций (никто не захотел делать станции по цене навороченног сервера и выпускать под них софт.)
Потом путём удерживания цен... по такой цене Итаники брали неохотно двже после убирания конкурентов (Саны и Power* -то остались)
А когда появились Оптероны с х64, стало ясно, что Итанику будет сложно.
Что сделал Интел ? А ничего, продолжил продавать дорогие Итаники, крайне медленно их развивая, и параллельно сам стал двигать х64.
Итоги известны. Хорошая, в теории, архитектура, и дорогущие , ничем не блещущие, процессоры и платы.

[netch80.livejournal.com]

> В 64 хотя б память можно нормально адресовать, а не так извращённо, как в классическом х86.

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

Сравнивать же с x86 до виртуальной памяти (286 и ранее) считаю бессмысленным.

> Значительно более кривой х86 с чудовищнми инструкциями разной длины, которые потом транслируются в risc-код, с кривой адресацией и то оказался вполне развиваем.

Вот на такие мнения я и отвечал в исходном постинге - что именно такая конструкция и является практически развиваемой. А не одноразовый снапшот текущего состояния отрасли.

> Подумали и сделали х64.
> Альфа находилась в намного лучшем положении - первоклассные разработчики, серверный рынок.

Это лучшее положение оказалось безвозвратно потеряно через несколько лет независимо от того, был бы явный слив или нет. Альфа изначально построена не развиваемой дальше одного короткого цикла технологий (грубо говоря, 10 лет). Её авторы успешно сняли сливки в виде славы и короткого периода прибыли. Дальше стало понятно, что надо перестраивать всё - и вот это они не потянули.

Несколькими годами раньше аналогично слился M68k. У него точно так же было идеальное положение в течение нескольких лет. Но с приходом необходимости тотального OOO оказалось, что перевести все его супер-навороченные адресации на новый стиль - задача неподъёмная. Последний публичный процессор общего пользования вышел в 1994. Дальше - только embedded для тех, кто привык к.

> Он жив в виде ядер для сетевых устройств, от многоядерных мощных провайдерских до домашних коробок. С серверного рынка его убрали через манагерские соглашения с SGI .

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

Во-вторых, я считаю, что все описанные вами "манагерские соглашения" и т.п. - это уже следствие, методы сделать перераспределение рынка более предсказуемым после того, как стало понятно, какие игроки в чём сильны. Исходная же причина именно техническая - имевшиеся решения конструктивно не вытягивали потребности среднего сервера тех времён за разумную плату. Когда это было осознано, и начались уже менеджерские шаги по решению проблем без откровенных крахов и банкротств.

> Итоги известны. Хорошая, в теории, архитектура, и дорогущие , ничем не блещущие, процессоры и платы.

Именно, что "в теории". Архитектура-однодневка, негибкая и не пригодная к малейшим изменениям внешних условий.

На самом деле в IA-64 итересо другое, но его очень мало кто вспоминает - система обеспечения надёжности. Те же привычные по x86 MCE появились на IA-64 и потом были очень частично портированы. Итаники позволяли, в частности, самоконтроль операций и восстановление после сбоев. Но опять-таки в массовом сегменте это не окупается - в лучшем случае поставят настоящую ECC память...

[oboguev.livejournal.com]

> Альфа изначально построена не развиваемой дальше одного короткого цикла технологий (грубо говоря, 10 лет)

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

[netch80.livejournal.com]

> Альфа проектировалась и была спроектирована на максимальную longevity архитектуры,

Я охотно верю, что таковы были амбиции её создателей. Но я говорил не о том, что им хотелось, а как оно получилось. Её авторы прошляпили всё, что можно было.
К несерверной нагрузке она была в принципе не готова. Например, как можно было исключать крайне важную часть в самом начале и потом спешно доделывать BWX вслед уходящему поезду? В результате работа с текстами получилась провальной.
А для серверов? Где возможность того развития, которое в случае x86 вылилось в MMX, SSE, AVX и так далее? Неужели сложно было на основании опыта векторного сопроцессора VAX (который был догнан Intel'ом только в SSE2) понять, что это крайне перспективное направление?

> с запасом отсутствия архитектурных ограничений по росту производительности реализаций на 40 лет,

Ага, ага. В то время, как у соседей за счёт AVX считается по 8 действий за такт, эти так и будут по одному гонять. Зато на 6-8 гигагерцах (которые так и не наступили, если не в сжиженном сферическом вакууме). И PALcode, который типа независимый от всех будущих революций, но на вызов которого уходит всё время.

> и с как минимум 1000-кратной масштабируемостью по отношению к начальной реализации.

В смысле - 1000 маленьких процессорчиков в ряд? Если плоский SMP, то из-за поддержки когерентности кэшей весь пар уйдёт в свисток. Если NUMA, то кому сейчас такое нужно?

[oboguev.livejournal.com]

> К несерверной нагрузке она была в принципе не готова.

Стив Джобс желавший предлагавший DEC-у использовать Альфу в новом Макинтоше думал иначе.

> как можно было исключать крайне важную часть в самом начале

Ее ведь и не исключали.
Просто приняли (разумное и верное) решение, что time to market важнее, чем полнота системы комманд в первом же EV.

> спешно доделывать BWX вслед уходящему поезду
> В результате работа с текстами получилась провальной

Неужели?
Что, TPU или Rdb или Oracle работали неудовлетворительно?

> А для серверов? Где возможность того развития, которое в случае x86 вылилось в MMX, SSE, AVX и так далее?

http://en.wikipedia.org/wiki/DEC_Alpha#Motion_Video_Instructions_.28MVI.29

> векторного сопроцессора VAX (который был догнан Intel'ом только в SSE2)

VAX vector и SSE -- это совершенно разные вещи.
SSE не покушается на крее-подобную архитектуру, поэтому утверждать, что "SSE догнал VAX Vector" -- бессмысленно.

> Неужели сложно было на основании опыта векторного сопроцессора VAX ... понять, что это крайне перспективное направление?

Вы, очевидно, не рефлектируете, что смотритесь со стороны несколько странно с утверждением, что вы, к этим делам никакого реального отношения не имевший, дескать, "понимаете", а организация, разработавшая и продававшая (или пытавшаяся продавать) векторные машины, и имевшая обширный технологический и рыночный опыт в этой области и вообще компьютерной области (и также определившая векторные расширения в PRISM, проекте-прототипе Альфы) -- "не понимает".
При этом вам почему-то даже в голову не приходит задаться вопросом, каков оказался рынок для VAX VECTOR, и было ли придание Альфе крееподобных векторных расширений окупаемым и рыночно-приоритетным в тот отрезок времени.

> В смысле - 1000 маленьких процессорчиков в ряд?

В смысле,
10х за счет повышения тактовой частоты, т.е. сугубо технологий реализации.
10х за счет увеличения глубины конвейеризации и внутрипроцессорной параллелизации исполнения.
10х за счет SMP.

Цифры разумеется условны, может быть не 10х, а 20x или 30х -- речь о порядковых целях ставившихся разработчиками.

В конечом счете, архитектура x64 значимо хуже Альфы ровно в одном, но важном фукциональном отношении: массой имплицитных взаимозависимостей в наборе инструкций, каковые зависимости из набора инструкций Альфы тщательно устранены. В поздних моделях x86/x64 влияние данных зависимостей на скорость исполнения одного потока маскируется благодаря большой глубине спекулятивного исполнения -- но это достигается за счет нескольки-кратного увеличения требуемого количества транзисторов и энергопотребления.

Иными словами, сегодяшний максимально-быстрый на отдельном потоке процессор с архитектурой Альфы не был бы радикально быстрее, чем максимально-быстрый процессор с архитектурой x64, но он был бы (при прочих равных обстоятельствах, как то условно-равных масштабах и накладных расходах производства) в несколько раз дешевле и в несколько раз энерго-экономичнее.

Или, прочтя то же в обратном направлении, за одинаковые деньги на производство и эксплуатацию high-end машины можно было бы иметь в такой машине в несколько раз большее количество Альфа-ядер, чем x64-ядер, при равной производительности ядра.

Или же, для устройств класса Xeon Phi, при одинаковой стоимости производства и эксплулатации, архитектура Альфы давала бы в несколько раз бОльшую производительность, чем архитектура x86/x64.

[netch80.livejournal.com]

> VAX vector и SSE -- это совершенно разные вещи.
> SSE не покушается на крее-подобную архитектуру, поэтому утверждать, что "SSE догнал VAX Vector" -- бессмысленно.

Вы, наверно, говорите о чём-то другом (возможно, VAX 9000?) Я говорю об вот этом, которое ничем принципиально не отличается от того же SSE; а, если в более общем смысле - то о том, что сама по себе идея поддержки векторных операций родилась задолго до рождения Alpha (и почти одновременного с ним рождения Intel MMX), и это могло бы намекнуть, что здесь открывается совершенно новое поле для развития. VAX был выбран как ближайший по времени крупный пример. Специфика Cray, своя у каждой модели, слишком разнообразна, чтобы с ней сравнивать.

> Вы, очевидно, не рефлектируете, что смотритесь со стороны несколько странно с утверждением, что вы, к этим делам никакого реального отношения не имевший, дескать, "понимаете", а организация, разработавшая и продававшая (или пытавшаяся продавать) векторные машины, и имевшая обширный технологический и рыночный опыт в этой области и вообще компьютерной области (и также определившая векторные расширения в PRISM, проекте-прототипе Альфы) -- "не понимает".

Ничего странного не вижу. Совершенно очевидно, что для истории Alpha я здесь уже изображаю типичного второго участника из "был бы я таким умным, как моя жена завтра". Это не умаляет ценность их работы, и того, что они приняли посильное участие в развитии отрасли. Но это позволит сделать вывод о причинах их проигрыша.

> При этом вам почему-то даже в голову не приходит задаться вопросом, каков оказался рынок для VAX VECTOR, и было ли придание Альфе крееподобных векторных расширений окупаемым и рыночно-приоритетным в тот отрезок времени.

Здесь Вы уже однозначно не понимаете, что я говорю. Я не предлагаю включать машину времени и срочно гнать векторные расширения (не "крееподобные"!) в изделия 90-го года. Но я говорю, что сама по себе возможность лёгкого включения таких расширений без глобального перелома архитектуры и без массового заката солнца вручную оказалась важнее, чем другие полезные свойства.

>> А для серверов? Где возможность того развития, которое в случае x86 вылилось в MMX, SSE, AVX и так далее?
> http://en.wikipedia.org/wiki/DEC_Alpha#Motion_Video_Instructions_.28MVI.29

Это эквивалент для 1-2 первых этапов в цепочке. Но не для неограниченного развития.

> Что, TPU или Rdb или Oracle работали неудовлетворительно?

Есть ссылка на сравнения тех времён при примерно равной цене за решение? Потому что, насколько я помню, такая работа была крайне медленной, а для эквивалента надо было переплатить в несколько раз.

> Иными словами, сегодяшний максимально-быстрый на отдельном потоке процессор с архитектурой Альфы не был бы радикально быстрее, чем максимально-быстрый процессор с архитектурой x64, но он был бы (при прочих равных обстоятельствах, как то условно-равных масштабах и накладных расходах производства) в несколько раз дешевле и в несколько раз энерго-экономичнее.

Почти безусловно, так (с заменой "Alpha" на "почти generic RISC"). Именно поэтому на смартфонах и планшетах взлетел ARM, а попытки загнать туда же x86 пока не дают заметного успеха. Но взлёт андроида произошёл на яве, а не на родном коде процессора.

> В конечом счете, архитектура x64 значимо хуже Альфы ровно в одном, но важном фукциональном отношении: массой имплицитных взаимозависимостей в наборе инструкций, каковые зависимости из набора инструкций Альфы тщательно устранены.

Это отдельная долгая тема. Но заметим, что современная компиляция для x86 уверенно направлена на то, чтобы эти зависимости сократить до минимума, и это в основном получается.

[oboguev.livejournal.com]

>> VAX vector и SSE -- это совершенно разные вещи.
>> SSE не покушается на крее-подобную архитектуру, поэтому утверждать, что "SSE догнал VAX Vector" -- бессмысленно.
> Вы, наверно, говорите о чём-то другом (возможно, VAX 9000?) Я говорю об вот этом, которое ничем принципиально не отличается от того же SSE

VAX Vector -- это процессор с длиной вектора 64 double и SIMD-фактором 64 с набором команд ориентированным на плавающую точку и рудиментарной поддержкой целых чисел и битовых операций (насколько помню, всего по 1 команде из последних категорий).
SSE -- это процессор с очень короткой длиной вектора (лень смотреть, но примерный SIMD-фактор 2-4, позднее при продвижении к AVX чуть больше) ориентированный первоначально по преимуществу на битовые и целочисленные операции, с первоначально третьестепенной и далее нарастающей ролью floating point.

Это совершенно разные устройства с совершенно разными назначениями:
VAX Vector -- это сопроцессор клонирующий архитектуру Cray-1/2 предназначенный для задач типа газовой динамики и т.п. решаемых алгоритмически так, как они решались на Cray-1/2 или других машинах подобной же архитектуры вроде Convex C1-C4.
SSE -- это набор команд с коротким SIMD-вектором предназначенный изначально в основном для битовых и целочисленных операций, т.е. для задач multimedia, и потом очень медленно расширявшийся в сторону большей пригодности для BLAS.

SSE совершенно не является аналогом VAX Vector.
Аналогом SSE является Alpha MVI.

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

> Я не предлагаю включать машину времени и срочно гнать векторные расширения (не "крееподобные"!) в изделия 90-го года. Но я говорю, что сама по себе возможность лёгкого включения таких расширений без глобального перелома архитектуры и без массового заката солнца вручную оказалась важнее, чем другие полезные свойства.

В Альфе эта возможность не только существовала, но и была осуществлена в виде MVI.

>> http://en.wikipedia.org/wiki/DEC_Alpha#Motion_Video_Instructions_.28MVI.29
> Это эквивалент для 1-2 первых этапов в цепочке. Но не для неограниченного развития.

В архитектуре Альфы не существует никаких ограничений для "неограниченного развития".

>> Что, TPU или Rdb или Oracle работали неудовлетворительно?
> Есть ссылка на сравнения тех времён при примерно равной цене за решение?

Разумеется есть: тесты SPECххх, TPC и других смесей, которые совершенно несомненным образом позиционировали Альфа-системы в качестве самых высокопроизводительных микропроцессорных машин своего времени, с далеким отрывом.
До тех пор, пока этот отрыв не был преодолен увеличением глубины спекулятивного исполнения в x64, со всей стоимостью этого решения.

>> Иными словами, сегодяшний максимально-быстрый на отдельном потоке процессор с архитектурой Альфы не был бы радикально быстрее, чем максимально-быстрый процессор с архитектурой x64, но он был бы (при прочих равных обстоятельствах, как то условно-равных масштабах и накладных расходах производства) в несколько раз дешевле и в несколько раз энерго-экономичнее.
> Почти безусловно, так (с заменой "Alpha" на "почти generic RISC").

Нет, без замены: RISC-архитектура сама по себе вовсе не подразумевает устранение implied зависимостей между командами.

>> В конечом счете, архитектура x64 значимо хуже Альфы ровно в одном, но важном фукциональном отношении: массой имплицитных взаимозависимостей в наборе инструкций, каковые зависимости из набора инструкций Альфы тщательно устранены.
> Это отдельная долгая тема. Но заметим, что современная компиляция для x86 уверенно направлена на то, чтобы эти зависимости сократить до минимума, и это в основном получается.

Это получается не за счет компиляции (опыт Itanium-а показывает, что эффективная статически-предиктивная компиляция недостижима), а за счет глубокого спекулятивного исполнения, т.е. за счет увеличения по сравнению с Альфой в несколько раз площади и стоимости кристалла процессора и его энергопотребления.

[netch80.livejournal.com]

> VAX Vector -- это сопроцессор клонирующий архитектуру Cray-1/2 предназначенный для задач типа газовой динамики и т.п. решаемых алгоритмически так, как они решались на Cray-1/2 или других машинах подобной же архитектуры вроде Convex C1-C4.

Отлично. Но под что он использовался кроме этого? И аналогичные векторные процессоры конкурентов? Использование под нужды графики и аналогичные, да и просто короткие пачки сихронных однотипных операций, возникло достаточно рано и показало основное направление, а также то, что это направление может развиваться достаточно долго. Газовая динамика, 64 значения - это всё уже вторично.

> В Альфе эта возможность не только существовала, но и была осуществлена в виде MVI.

И насколько его можно было расширять? Могло оно пройти полный путь нынешнего векторного процессинга в x86? Думаю, ответ очевиден.

> В архитектуре Альфы не существует никаких ограничений для "неограниченного развития".

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

> До тех пор, пока этот отрыв не был преодолен увеличением глубины спекулятивного исполнения в x64, со всей стоимостью этого решения.

OK, предположим (с поправкой, что x86-64 сам по себе тут ни при чём). И что плохого в этой стоимости, если она приемлема для >99% применений?

> Это получается не за счет компиляции (опыт Itanium-а показывает, что эффективная статически-предиктивная компиляция недостижима), а за счет глубокого спекулятивного исполнения, т.е. за счет увеличения по сравнению с Альфой в несколько раз площади и стоимости кристалла процессора и его энергопотребления.

То есть, в переводе на понятный язык, на десктопе и выше она перестала тянуть из-за слабой расширяемости и недостаточно "спекулятивного" исполнения, а для более embedded ниш она в разы кривее MIPS, ARM и прочих конкурентов.

[skolk.livejournal.com]

http://en.wikibooks.org/wiki/360_Assembly/360_Instructions/ALR (http://en.wikibooks.org/wiki/360_Assembly/360_Instructions/ALR)
Carry генерируется, только добавлять непонятно куда ;(

[netch80.livejournal.com]

Дядьку, ты посмотри в историю, кто сделал эту статью:)
Да, я знаю, что перенос делается. А примеры кода можно смотреть, например, в libgmp. Там есть ассемблерные вставки для кучи архитектур. И удобным я бы его не назвал.