Эсхатология и герменевтика парапрограммных объектов

У них достаточно много и хороших решений. И про "с самого начала" я не согласен, 8086 очень неплохо продуман.

From:

http://users.livejournal.com/_slw/

по сравнению с pdp11?
с его вот этим всем, моделью прерываний, например?

From:

> по сравнению с pdp11?

И по сравнению с PDP-11 тоже. Например, в таком её виде она банально нерасширяема. Почему эта её хвалёная ортогональность вдруг заканчивается на ряде команд, и уже MUL и DIV работают только с регистром (или двумя) в качестве целевого операнда? Почему точно так же не хватило полноценных кодов на ADCB, SBCB, XOR, и не сделали расширение? Почему в VAX не стали повторять этот принцип, а перешли на байтовую грануляцию команд?

> с его вот этим всем

Это чем? Например, виртуальной памятью в стиле "узкое окошко"? Неисправимой 16-битностью?

> моделью прерываний

Модель прерываний там тупейшая и слабо управляемая. То, что в PDP-11 для некоторой цели можно было поднять IPL, а в 8086 - загнать маску в 8259, принципиально ничего не меняет. (Или ты про один флажок IF? Он - последнее средство в цепочке, и то, что некоторые использовали только его, говорит не более чем об их способностях и потребностях.) Зато в 8086 можно было управлять каждым запретом раздельно (привет BSD с её spl*()), а в PDP-11 - если ты запретил то, что на уровне 6, то то, что на уровне 4, уже никак не будет доступно.

Да, программировать человеку приятнее с полной ортогональностью. Это удобнее, чем помнить всякие странности типа того, что на amd64 почему-то push константы есть только 32-битный. Но расход ресурсов на это может быть чрезмерный. Мне в этом плане подход S/360 с потомками кажется куда адекватнее.

From:

alex dubov (from livejournal.com)

Очевидным образом, на "ИСУ" всем наплевать - никакого существенного влияния на производительность процессора или програмистов она не оказывает (и никогда не оказывала, что характерно - все эти мипсы и прочая компания нещадно тормозили еще во времена пентиума-1, зато стоили в тысячах).

Кстати говоря, есть еще одна равно кривая и достаточно живучая ИСА - с/360 и производные.

From:

Ну S/390, z/Architecture кривы в арифметике (она у них до-NZVC'шная), но чрезвычайно прямы, например, в организации VM - никакого кошмара в стиле x86. I/O уникальный, но в рамках своей концепции вполне прямой. Так что я бы о них так не отзывался. Другой вопрос, что IBM со своей позицией "компьютер - это штука не менее чем за мегабакс" заведомо сливает массовому рынку, но Linux на S/390 выручает:)

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

From:

alex dubov (from livejournal.com)

Там не такие уж кошмары - в Интеле всегда придерживались золотого правила "make the common case fast and the uncommon work" (последнее, правда, не всегда получается, доставляя порядочные неприятности людям, которым нужно поддерживать старые и долгоживущие программы). В остальном, как известно, микрокод все стерпит.

Интересным образом, вопросом зависимости производительности от ИСЫ я озабачивался еще в далеком 98м году, благо было много всякого доступного железа (запускал какую то криптографию). Основной платформой был Пентиум Про на 200Мгц, и что характерно, быстрее него была только 164я Альфа (процентов на 50 быстрее при частоте то ли 400, то ли 600 МГц). МИПС R10к с родными силиковским компилятором давал более менее ту же производительность (но стоил как бы не в 10 раз больше). Па Риск 8500 не тянул совершенно (не удивительно что HP с таким энтузиазмом подписались под Итаниум). По факту стало очевидно, что ИСА на производительность существенного влияния не оказывает (да и если подумать, оказывать не может - из всех компонентов процессора, декодер инструкций как бы не самая простая запчасть).

From:

Как раз в те времена на тех Альфах и НР-шных машинах крутились вещи типа больших БД, которые на х86/PPro было нереально запустить.
А криптография... мало ли как написано, как оптимизировано компилятором. Не показатель.

From:

> которые на х86/PPro было нереально запустить.

Вполне реально, но, возможно, не с теми характеристиками. Но конкуренты брали свои ниши, как сейчас видится, за счёт архитектурно перекошенных решений. Например, кэш в 4-8 раз больше того, что могли себе позволить даже на продвинутых x86 - уже достаточное средство для того, чтобы БД летали (в сравнении). Это как сейчас топовый Corei7 против целерона той же базовой архитектуры. Но и стоило это так, что обычные люди и фирмы с оптимизацией каждого цента не покупали.

А x86 таки всегда в истории этого периода держал баланс между фичами, не перекашиваясь в одну сторону, если совсем уж явно не просили, и так и прошёл по принципу "Сейчас мы ме-е-едленно доедим траву, ме-е-едленно спустимся с горы и отымеем всё стадо".

(Мне в связи с этим вспоминается история из ранней жизни lucky.net ещё времён тотального UUCP - как uucico из Taylor UUCP начал при расширении списка пользователей (систем, знакомых узлу) всё больше тупить до тех пор, пока не начали отваливаться по таймауту. Стали читать код - мамочки родные... оно сначала один раз читает конфиг "в общем", потом второй - запоминая смещения секций каждой системы, затем, получая "Shere=$name" на входе, парсит секцию системы ещё пару раз. Срочно купили Pentium 75 вместо 486/50... время среднего старта сократилось с 50 секунд до 5. Вот что кэш животворящий делает.)

Alpha, если почитать сейчас, ужасно кривая архитектура, кривее x86. То, что она не выжила, закономерно. И все эти HPPA - туда же...

From:

>>У большинства этого не получилось и они сдохли (как та же Alpha).

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

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

From:

> "кривы в арифметике" - это как понимать ? векторные вычисления в 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; куда уж другие тянуть?

From:

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

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

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

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

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

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

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

Edited Date: 2013-12-24 10:00 pm (UTC)

From:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From:

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

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

From:

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

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

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

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

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

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

From:

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

Стив Джобс желавший предлагавший 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.

Edited Date: 2014-01-07 11:43 pm (UTC)

From:

> 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 уверенно направлена на то, чтобы эти зависимости сократить до минимума, и это в основном получается.

From:

>> 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-а показывает, что эффективная статически-предиктивная компиляция недостижима), а за счет глубокого спекулятивного исполнения, т.е. за счет увеличения по сравнению с Альфой в несколько раз площади и стоимости кристалла процессора и его энергопотребления.

Edited Date: 2014-01-23 02:00 am (UTC)

From:

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

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

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

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

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

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

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

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

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

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

From:

skolk.livejournal.com

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

From:

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

From:

>> Результат выглядит как корабль, слой ракушек на котором в несколько раз толще ширины корабля. Зачем?

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

Но Arm'ы за последние несколько лет совершили рывок, ускорившись более чем на порядок (раз эдак в 20, с учётом многоядерности), а х86-64 лишь раза в полтора-два (смотря как считать). В итоге SnapDragon 800 , стоящий в топовых серийных смартах, уделывает Атомы с 2-4 ядрами, Хром на нём крутится так же быстро, как и на 4х ядерном х64 Core i5, и это на fullHD дисплее.
А в iphone 5S уже стоит 2х ядерник с 64ит ядрами, каждое из которых ещё в 1.5-3 раза (смотря что запускать) быстрее, и на подходе ещё более мощные ядра.

From:

alex dubov (from livejournal.com)

Это не "армы совершили", а Интел поводья отпустил. :)

From:

То есть инженеры Арм, Квалкомма, Эппла, Самсунга и тд. сделали все свои разработки (а это несколько великолепных основных дизайнов процессоров, от Арма, Квалкомма и Эппла, и их доработки и доводка под ТЗ фирмы, чем занимаются все остальные) просто потому, что "Интел поводья отпустил" ?

From:

alex dubov (from livejournal.com)

Совершенно верно (вообще у Арма очень любопытная история, поучительная, я бы даже сказал).

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

From:

Самсунг делает процессоры, и, скажем так, не самые плохие. Один из первых массовых чипов на А15 ядрах, который стоит в Нексусе10 - именно Exynos5250, не самый экономичный, но шустрый. Вопрос денежной отдачи того подразделения - дело 10е.

Интел сделал 2 больших шага вперёд, с самыми первыми Core и с Core II (Sandy Bridge) , а до того самый большой шаг вперёд сделала AMD, создав х86-64 и первой выкатив честные многоядерные х86 процессоры, но далее каждый новый шаг всё менше приносит и всё труднее даётся.
Вот выпустили они HAswell, и что ? прирост мизерный, из ценных плюшек разве что avx2, который в софте массово будет использоваться лет через 5-7.
Некуда им дальше стремительно расти, не предусматривает х86 архитектура "дешевого" одновременного выполнения 10 команд за такт, а частоты свыше 7-8 ггц пока что недостижимы, при этом в рамках текущих технологий для огромных и сложнейших х86 чипов граница по частоте уже несколько лет проходит чуть ниже, где-то на уровне 4-5 ггц.

А Арм'ам есть куда расти, и они стремительно растут. "Наследие прошлого" у них не такое тяжелое, то же число логических регистров вдвое больше, да и вообще Arm risc архитектура намного эффективнее с точки зрения отношения миллионов транзисторов к эффективности.
Вот и растут. Думаю, скоро мы увидит миллионы серверов на Arm x64.

From:

amarao-san.livejournal.com

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

From:

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

From:

coctic

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

From:

> x86 живо только пока идёт бурное развитие (по закону Мура). Как только последний остановится, она потеряет преимущество и лет за 10 уйдёт в ноль

У метрической системы есть преимущества перед имперской системой мер, тем не менее последняя не только не ушла за 200 лет, но уходить не собирается.

Подобно имперской системе, у x86 есть то преимущество, что она представляет стандарт, вокруг которого выстроена огромная экосистема (для огромного количества приложений -- попросту "вся экосистема"), и это преимущество не перебивается ничем.

Edited Date: 2014-01-07 02:32 am (UTC)

From:

Это преимущество в экосистеме и возникло за счёт того, что архитектура развивалась с сохранением совместимости. А это развитие - оттого, что оно вообще было возможно в базовом дизайне.

From:

Не уловил, что вы желали сказать.
Я всего лишь указал, что высказанный вами прогноз безоснователен и не имеет сколь-либо значимых шансов на осуществление, только и всего.

Edited Date: 2014-01-07 10:06 pm (UTC)

From:

Почему не имеет? Если уже, считаем, половина устройств, с которых что-то делают - смартфоны и планшеты, то на них не работают ранее скомпилированные приложения. Где-то это за счёт другого процессора, а где-то за счёт другой оси, но результат один и тот же - чтобы что-то даже почтенное работало на новом, его надо как минимум перекомпилировать, а то и переписать. Чуть раньше аналогичный эффект дал переход 32->64 для десктопа и ликвидация поддержки 16-битного кода, а ещё раньше - выход DOS из активной реальности.

Вы сами в соседнем комментарии утверждаете, что RISC (в Ваших терминах "процессор архитектуры Альфы") экономичнее среднего x86 по количеству транзисторов, затрат электричества и т.д. в разы. При остановке развития встанет принципиальный вопрос: брать что-то эффективное в этих условиях, дешевле, экономичнее и т.д., для которого вся экосистема таки есть (для начала она формируется, грубо говоря, андроидом), или старое и прожорливое, с какой-то долей наследия, но только за последний десяток лет (дос, 16-битное, 32-битное уже, считаем, ушло из видимости, даже несчастный браузер уже съест 4GB VM с ходу и попросит добавки). Думаю, выбор очевиден, и даже десяти лет не потребуется на полный переход.

From: