ISA ошибок не прощает

[mark_ablov]

У Intel было много ISA, как минимум с десяток. Ни одна, кроме x86 не выстрелила, увы.

[vvvphoenix]

Горестная судьба Itaniuma вся прошла перед моими глазами. Поделка, впрочем не была так плоха чтоб с первого дня окрестить ее Itanicом. Однако, это EPIC…

[vvvphoenix]

Зато энергию этот backward compatibility блок потреблял за троих :)

[tyomitch]

Внезапно, как раз Huawei и пытается продвигать собственные VLIW-архитектуры: www.zdnet.com/article/amazon-huawei-efforts-show-move-to-ai-centric-chips-continues

[Ankoroid]

Для очень специфических задач, а вовсе не для процессоров общего назначения.
Так то есть несколько VLIW архитектур (не Эльбрус), которые вполне живы — например ST2XX встречаются в спутниковых ресиверах.

[tyomitch]

Qualcomm Hexagon живее всех живых: наверное, в большинстве смартфонов стоит.

Мне просто показалось забавным, что VLIW хоронят в блоге Huawei, которая один из нынешних активистов VLIW-строения.

[Ankoroid]

Qualcomm Hexagon

Да, все это из области DSP-like процессоров, не более.

[screwer]

и одна VLIW-архитектура по-настоящему не взлетела.

Qualcomm Hexagon. Используется, наверное, в половине мобильных устройств по всему миру. А это многие миллиарды девайсов.

[screwer]

Нет, давайте смешивать. Потому что прошивка модема это процентов на 90 самое обычное прикладное ПО. И размер его огромен. В несколько раз больше ядра линукса. Там и OS есть, и задачи (несколько десятков!), и примитивы синхронизации, сигналы, сисколлы, привилегии и т.д. Даже подкачка виртуальной памяти. Ту же самую OS Qualcomm собирал и под ARM. Не вижу особых различий в исполнении обычного прикладного кода. А в 2016 туда ещё и прикладную часть WiFi запихнули.

[tyomitch]

Как на этой прошивке запустить сторонний код?

census-labs.com/media/attacking-hexagon-recon19.pdf

[VladislavBojarov]

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

[plus79501445397]

ЕМНИП, x86 разрабатывалась «на скорую руку» как временная, а основной должна была стать iAPX 432

[vvvphoenix]

:) Я тоже слышал эту байку. Не уверен, что правда, оч давно было. Но хорошо коррелирует с мыслью о том, что в истории X86 гораздо большую роль играло стечение обстоятельств, чем изначально заложенная логика :)

[beeruser]

Это не байка.
«Stephen Morse: Father of the 8086 Processor»
www.pcworld.com/article/146917/article.html

management decided that I would be the ideal person to design the architecture for the stopgap measure. If management had any inkling that this architecture would live on through many generations and into today’s Pentium processors, and be the instruction set executed by more instances of computers than any other in history by far, they never would have entrusted the task to a single person.

Или вот ещё момент оттуда, про порядок байт, если кому лень читать статью:

I always regret that I didn’t fix up some idiosyncrasies of the 8080 when I had a chance. For example, the 8080 stores the low-order byte of a 16-bit value before the high-order byte.
…
Now there was no reason for me to continue this idiocy, except for some obsessive desire to maintain strict 8080 compatibility. But if I had made the break with the past and stored the bytes more logically, nobody would have objected. And today we wouldn’t be dealing with issues involving big-endian and little-endian—the concepts just wouldn’t exist.

[mvv-rus]

And today we wouldn’t be dealing with issues involving big-endian and little-endian—the concepts just wouldn’t exist.

Ну, вообще-то, little endian порядок байт в слове был и в архитектурах весьма распространенных в те времена миникомпьютеров от DEC — PDP-11 и VAX-11. Так что насчет того, что концепции разных порядков байтов не существовали бы — это автор, наверное, всё же погорячился.
PS Правда, у этих концепций тогда был бы шанс не дожить до нашего времени — может, он это имел в виду?

[mpa4b]

Были архитектуры, где правильно выбранный порядок байт упрощал или ускорял работу процессора. Были — где наоборот, замедлял. И были же — те, где на него пофиг было процессору. примеры:

1. pdp-11: процессор 16-битный и слова всегда выровнены по 2 байта. на порядок байт в слове пофиг, сделали LE.
2. i8080: процессор 8-битный, но читает 16-битные слова всегда как 2 подряд идущих байта. тоже на порядок байтов пофиг, сделали LE
3. mc6800 (не путать с mc68000!). 8-битный, порядок байт BE. за что расплата лишним тактом в адресации типа LDA ADDR,X, где процессор побайтно читает 16-битное число, прибавляет к нему 8-битный индексный регистр и с полученным адресом выходит на шину прочитать аргумент. порядок байт выбран неправильно (почему — см. ниже)
4. 6502! идеологически похож на 6800, порядок байт LE. благодаря этому, в описанном в п.3 случае читает сначала младший байт, потом во время чтения старшего — одновременно прибавляет к уже прочитанному индексный регистр. и если нет переноса в старшую часть, то на шину выходит сразу же, не тратя дополнительный такт. порядок байт выбран верно!

ну и соглашусь, что уже в i8086, mc68000 и далее — порядок байт перестал играть какую-либо роль. например архитектура ARMv7A позволяет переключать порядок байт прям в пользовательской программе, инструкциями SETEND BE/LE.

[dmitrmax]

У PDP-11 не little endian, а PDP endian

[mpa4b]

"pdp endian" относится только к опциональному FPU. сам PDP-11 без FPU чисто 16-битная машина и соотв-но может быть назван little endian

[dmitrmax]

Например, в DSP TigerSHARK 32битная архитектура. В смысле там даже char 32 бита. Там вообще нигде не вылезает endianess, кроме как при взаимодействии с переферией. Но для ALU это бессмысленно.

[vvvphoenix]

Вот что подумал — arm — консорциум вендоров. А Интел — одна компания. И решения в ней принимает гораздо меньшее число людей. А людям свойственно ошибаться. И поэтому в x86 гораздо больше странных решений…

[tyomitch]

Прямо сейчас над вашим комментарием отображается три полностью пустых.
Всё чудесатее и чудесатее!

[vvvphoenix]

Н-да. Занятно. Я тот комментарий писал к комментарию про Стивена Морса и его высказывания как он боролся с 8086 в одно личико.

[vikarti]

Что? А британцы из ARM Holdings в курсе что они консорциум вендоров?
Ну да — они могут продать дизайн готового ядра а могут — лицензию на архитектуру (задорого и ядро дизайнить самим, Apple и Qualcomm пользуется этой опцией, Samsung вроде пользовался но решил что не надо больше).

[netch80]

Скорее тут фактор личности — нужно смотреть, кто это такой смелый экспериментатор в Intel.

[Balling]

Вот я не понимаю, внутри процессоров Intel всё равно используется ARM (их же взломали и получили доступ к внутренней операционной системе MINIX). Кроме того, Qualcomm же выпустила ARM+x86 процессор, где можно на лету аппартаную архитектуру переключать.

[code07734]

>от я не понимаю, внутри процессоров Intel всё равно используется ARM
Вы имели ввиду risc внутри? Там не arm.

>Qualcomm же выпустила ARM+x86 процессор, где можно на лету аппартаную архитектуру переключать.
Нет, там программная эмуляция и не от qualcomm а от microsoft

[Balling]

>Нет, там программная эмуляция
Программная эмуляция это qemu & binfmt_misc. ownyourbits.com/2018/06/13/transparently-running-binaries-from-any-architecture-in-linux-with-qemu-and-binfmt_misc Там вроде аппаратная частично. habr.com/ru/news/t/404527
>Вы имели ввиду risc внутри? Там не arm.
Ну не знаю, в IDA выглядит как ARM64. Только линковка другая.

[code07734]

docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details

[Balling]

Да кстати, прошивка ME тоже на ARM64. Но это только одно из сотен устройств, которые подключены к чипсету.

[Balling]

Приблизительно. Lakermont CPU — это чипсет. Но полный доступ к декодированному микрокоду и блоку CPU (левый верхний угол, это типо сам кристалл Intel Core и его шина CRBUS) и SSA-PSS подписям (https://twitter.com/h0t_max/status/1263516824211161088?s=20) мы получили типо 3 дня назад. Cмотрите (разумеется там на самом деле намного больше устройств):

[dartraiden]

Нет, прошивка ME работала до 2015 года на ARC (не ARM), с 2015 на x86.

Версии ME от 1.x до 5.x использовали ARCTangent-A4 (только 32-битные инструкции), тогда как в версиях от 6.x до 8.x использовался более новый ARCompact (смешанная 32- и 16-битная архитектура набора команд)

Начиная с ME 11, в основе лежит 32-битный x86-совместимый процессор на технологии Intel Quark

[tyomitch]

Во-первых, не Qualcomm, а Nvidia, а во-вторых, не выпустила, а только собиралась, но в итоге отказалась от поддержки x86.
Это если вы про en.wikipedia.org/wiki/Project_Denver

[Balling]

Ну вы бы еще Эльбрусы x86 эмуляцию аппаратную привели в пример. LOL. Надо будет разобраться с snapdragon 8cx.

[dartraiden]

Если вы про Management Engine (судя по словам про Minix), то

— оно живёт в чипсетах, а не процессорах
— с 2015 года оно крутится на x86
— до 2015 года оно работало на ARC, а не на ARM

[vvvphoenix]

Подумал о том, что ARM — это консорциум вендоров. А Интел -одна компания, пусть и большая. И решения там принимают люди. Очень умные. Но людям свойственно ошибаться. Поэтому в истории X86 так много было странных решений. Просто эти решения принимались гораздо меньшим числом людей. Иногда вообще одним человеком

[tyomitch]

Почему это ARM — консорциум? Одна компания, намного меньше Intel.

[dmitrmax]

Консорциум вендоров. То есть куча компаний, которые применяют ARM в своих чипах.

[tyomitch]

И в чём отличие от Intel?

[dmitrmax]

Чипы с архитектурой x86 на настоящий момент производятся только двумя компании в сколь-либо заментном количестве.

[vvvphoenix]

Отличие в том, что ARM должен согласовывать спецификации с каждым из больших вендоров. И шансов ошибиться у него намного меньше при этом. А Интел не должен ни с кем. И часто решения принимаются одним человеком.
Я верю в философскую теорему о том, что «только открытые системы могут быть устойчивы». ARM — открытая система. Интел -нет

[dmitrmax]

На мой взгляд, little endian гораздо логичнее. Big endian это всего лишь попытка натянуть на АЛУ привычную нам запись чисел слева направо.

[tyomitch]

Не стоит забывать, что «привычная нам запись чисел слева направо» позаимствована у арабов, которые пишут справа налево, т.е. в естественном порядке от младших разрядов к старшим (little-endian).

[dmitrmax]

С чего вы взяли, что она позаимствована от арабов? Арабские цифры на самом деле индийский. Арабы используют другие цифры.

[tyomitch]

Арабы используют другие цифры.

Как и индийцы ;-)

[netch80]

Это вариации начертания, принцип же — позиционный, 10 знаков, младшие справа — одинаков.
У индийцев, кстати, у каждого языка чуть свои цифры — см. список юникода, например:

0030;DIGIT ZERO;Nd;0;EN;;0;0;0;N;;;;;
0660;ARABIC-INDIC DIGIT ZERO;Nd;0;AN;;0;0;0;N;;;;;
06F0;EXTENDED ARABIC-INDIC DIGIT ZERO;Nd;0;EN;;0;0;0;N;EASTERN ARABIC-INDIC DIGIT ZERO;;;;
07C0;NKO DIGIT ZERO;Nd;0;R;;0;0;0;N;;;;;
0966;DEVANAGARI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
09E6;BENGALI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
0A66;GURMUKHI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
0AE6;GUJARATI DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
0B66;ORIYA DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
0BE6;TAMIL DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
0C66;TELUGU DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;
0CE6;KANNADA DIGIT ZERO;Nd;0;L;;0;0;0;N;;;;;

Но важнее то, что у индийцев, которые писали слева направо, позаимствовали арабы, не меняя порядок — младший справа — и затем европейцы, восстановив исходный порядок.

[netch80]

Не проходит: арабы сами позаимствовали эту запись у индийцев, которые писали слева направо. Европейцы восстановили индийский порядок записи.
Сам же этот порядок происходит от языка, в котором — за исключением локальных инверсий типа ein zwanzig — во всех мировых языках начинают с самых больших значений (типа «пять миллионов восемьсот тридцать две тысячи...»)

[tyomitch]

Как раз в семитских языках исторически были little-endian числительные, например «пять и шестьдесят и триста».

[netch80]

OK, принимается (хотя ещё надо уточнить типичность этого по всем стилям). Но всё равно европейский порядок цифр — восстановление индийского.
(Хм, у кого ещё LE порядок в языке?)

[tyomitch]

Я ещё добавлю, что основное преимущество арабских/индийских цифр перед традиционными европейскими (римскими, греческими, славянскими и т.д.) — возможность выполнения действий «в столбик».
Все действия «в столбик» выполняются от младших разрядов к старшим, так что запись справа налево для арабских чисел намного естественнее.

И ещё, что в древнеанглийском числительные были как в немецком: seofon and twēntiġ; лишь под влиянием понаехавших норманнов англичане перешли на чистый big-endian.

[netch80]

> Все действия «в столбик» выполняются от младших разрядов к старшим, так что запись справа налево для арабских чисел намного естественнее.

1. Не все; как минимум деление делается, наоборот, от старших. Это существенно потому, что чем сложнее действие, тем важнее его облегчение — а деление из четырёх арифметических действий безусловно самое сложное.
2. Логический переход от первой ко второй части мне непонятен. Почему вдруг порядок называния должен соответствовать порядку первых трёх арифметических операций, а не каким-то другим соображениям, вроде того же порядка в устной речи?

> лишь под влиянием понаехавших норманнов англичане перешли на чистый big-endian.

Верю. Источники по ОИЕ утверждают тоже такой порядок, типа: «The normal order of composite numerals is units+tens, and there was a natural
tendency to follow a ‘units+tens+hundreds+...’, cf. Skt. ekādaśaṃ sahasram, lit. ‘one ten thousand’, one thousand and eleven. So e.g. penqe dekṃ kṃtóm, one hundred and fifteen, oinom qatwŕdkṃta septṃkṃtos, seven hundred and forty-one.»
Но кто сказал, что это хорошо? Язык неолита не очень подходит для современных условий.

[tyomitch]

2. Запись числа — это ведь инструмент для прикладных задач; порядок записи не обязан соответствовать порядку чтения (что немецкий и демонстрирует).

[netch80]

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

[tyomitch]

Косвенно распространяющийся («семь-и-двадцать-тысяч»)

[dmitrmax]

Капитан, эта прелесть называется позиционная система счисления.

[netch80]

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

Или: если число записывается в переменное число байт — то big-endian дороже для пишущего (надо вначале размотать, найдя, где старшая часть), но дешевле для читающего (просто по порциям читаем и сдвигаем), little-endian — наоборот. Поэтому выбор форматов [u]leb128 для DWARF — ошибка: надо удешевлять читающий отладчик, а не пишущий линкер: линкер работает один раз, а отладчик читает управляющие структуры по многу раз.

[ultrinfaern]

Все арифметические операции делают с меньших разрядов, а большая часть программы это арифметические операции. Так что для читающего лучше читать с младших разрядов.

[netch80]

Это имело бы смысл, если бы память читалась и писалась побайтно под управлением процессора. На какой-нибудь S/360 model 20 такое было, да. На Intel 8088 тоже. На первых 68000.
Но сейчас обычная операция это прочитать/записать строку кэша (32-64-128 байт), дальше с ней целиком работать (между АЛУ, регистрами и кэшами параллельные интерфейсы, иначе тупо скорости не хватит), записать обратно. И там порядок байт конкретной операции с машинным словом уже ничего не значит.
Длинная арифметика стиля GMP меняла бы стиль, да — грубо говоря, вместо i от 0 до n-1 идём от n-1 до 0. Но там обычно делают LE массив лимбов, даже если лимбы хранятся в BE.

[ultrinfaern]

Для того чтобы что-то прочитать, сначала надо вычислить адрес: для LЕ ничего делать не нужно, для BE взять размер, сложить с начальным адресом и мы получаем младший разряд. То есть на каждую арифметическую операцию нужно доп.телодвижения.
ЗЫ Мы тут говорим про длинную арифметику, а если операнды влазят в размер регистра, то там разницы нет, так как чтение все равно за раз будет происходить.

[netch80]

> Мы тут говорим про длинную арифметику

Спасибо за уточнение, а то я успел офигеть от первой части. Но давайте тут подробнее. Что вы называете длинной арифметикой и что за «дополнительные телодвижения»?

Вот я складываю числа (без знака, в стиле GMP mpn — знак отдельно хранится — иначе утонем в ненужных деталях). Для LE это будет выглядеть — считаем, что операнды уже одинакового размера —

unsigned *param1, *param2, *result;
...
for (int i = 0, carry = 0; i < n; ++i) {
  carry = ADD(param1[i], param2[i], &result[i], carry);
}

А для BE цикл превращается в:

unsigned *param1, *param2, *result;
...
for (int i = n-1, carry = 0; i >=0; --i) {
  carry = ADD(param1[i], param2[i], &result[i], carry);
}

Хотя может быть написан и в идиоматичном стиле:

unsigned *param1, *param2, *result;
...
unsigned i = n, carry = 0;
while(i--) {
  carry = ADD(param1[i], param2[i], &result[i], carry);
}

Тут ADD это что-то типа (тип переноса в общем неважен)

inline bool ADD(unsigned input1, unsigned input2, unsigned *output, bool carry) {
  unsigned temp1 = input1 + input2;
  bool ovf1 = temp1 < input1;
  unsigned temp2 = temp1 + carry;
  bool ovf2 = temp2 < temp1;
  *output = temp2;
  return ovf1 || ovf2;
}

Ну и в чём разница между LE и BE, кроме направления итерирования цикла?

Если же цикла нет — например, процедура просто для чисел двойной длины — и снова пофиг, делать первую выборку по [rcx] или [rcx+8], всё захардкожено…

Ну в упор не вижу разницы. Покажите код, что ли.

[ultrinfaern]

for(int i=0,…
for(int i=n-1,…
Переложите их на ассемблерных инструкции. Разница вполне очевидна.А теперь помножьте эти дополнительные операции на на то, как часто это нужно делать (как часто эта функция вызывается)…

[netch80]

> Переложите их на ассемблерных инструкции. Разница вполне очевидна.

Да, очевидна: проверка на 0 (случай BE) на какие-то милликопейки дешевле из-за того, что не надо n хранить в регистре. В отличие от вас, я проверил результат реальным ассемблером. Хотите возражать — начните делать это предметно: покажите команды на выходе обоих вариантов и докажите на листинге, что в LE варианте получается дешевле. А то я тут на каждую вашу реплику «разъедающего сомнения» привожу реальный код, а в ответ получаю ещё одно «не верю» без аргументов. Жду.

[mpa4b]

Достаточно указывать указателем на конец BE числа, чтоб отпала необходимость складывать с размером.

[netch80]

Как минимум не надо забывать, что little-endian были PDP-11, VAX, 6502, а также, что многие вещи становятся проще и понятнее в little-endian… например, читая доку по z/Arch надо следить, каким образом мы рассматриваем конкретный регистр: одни и те же биты будут называться 0-31 (0 — старший), если регистр рассматривается как 32-битный, и 32-63, если как 64-битный. На little-endian такого нет, расширение возникает естественно без перенумерации.

А если ещё вспомнить, что знаменитая IEN 137, в которой были впервые введены термины little-endian и big-endian, выпущена в 1980, а x86 появилась в реально массовом употреблении на несколько лет позже… увы, Intel виноваты только в одном — что их архитектура оказалась ещё одной сверхуспешной.

[mpa4b]

Нумерация битов в слове не имеет никакого отношения к порядку байт того же слова в памяти. И что в ibm360 и всех последующих, а также в powerpc нумерация битов со старшего разряда — это конечно дремучий трындец.

[netch80]

> Нумерация битов в слове не имеет никакого отношения к порядку байт того же слова в памяти.

То есть вы IEN137 тоже не читали? Ну-ну.

Вот пусть у нас массив битовых флагов. Мы с ним можем обращаться, например, так:

typedef uint8_t access_t;
const unsigned shift_for_cell = 3;
const unsigned val_mask = 7;
_Bool get_bit(void *bitset_area, unsigned index) {
  unsigned offset = index >> shift_for_cell;
  unsigned shift = index & val_mask;
  return 0 != (1 & (((access_t*) bitset_area)[offset] >> shift));
}

Что будет, если мы изменим access_t с uint8_t на uint32_t, shift_cell на 5, а val_mask на 31? Ну вот решили, что удобнее доступаться не по 1, а по 4 байта?
Для little endian результат не изменится. Для big endian — будет читаться совсем другое: порядок доступа поменялся.

Как исправить, чтобы порядок не менялся от размера access_t на big endian? Проще всего в вычислении shift заменить index на ~index. Но при этом бит 0 будет старшим в байте по смещению 0, а не в младшем.

Представим себе структуру с битовыми полями. Например, сделаем её такой (чтобы поактуальнее):

struct float32 {
  unsigned sign: 1;
  unsigned exponent: 8;
  unsigned significand: 23;
};

Почитаем одно поле:

unsigned get_sign(const float32 *val) {
  return val->sign;
}

Сначала для s390x:

get_sign:
l %r2,0(%r2)
risbg %r2,%r2,64-1,128+63,64+32+1
br %r14


тут всё правильно — сдвинули вход на 1 бит влево по кругу (старший бит стал младшим), отделили один этот бит на выход и вернули.

Теперь пробуем на AA64:

get_sign:
ldrb w0, [x0]
and w0, w0, 1
ret


Ой, что случилось? Почему оно взяло младший бит вместо старшего? Глупый, глупый GCC? Не знает, что надо было старший бит брать? Меняем определение:

struct float32 {
  unsigned significand: 23;
  unsigned exponent: 8;
  unsigned sign: 1;
};

Смотрим:

get_sign:
ldrb w0, [x0, 3]
ubfx x0, x0, 7, 1
ret


Ух ты — заработало!

Как вы думаете, почему GCC для LE заполняет поля начиная с младших бит, а для BE — со старших?

> И что в ibm360 и всех последующих, а также в powerpc нумерация битов со старшего разряда — это конечно дремучий трындец.

Это не «дремучий трындец», а естественное следствие big endianness.

Можно пойти против него, но начнутся разрывы в неожиданных местах.

[mark_ablov]

У меня, кстати, лежит плата под iAPX 432. Может дойдут руки пощупать этот процессор в живую.

[vvvphoenix]

Может все же не стоит оживлять призраков? Мало ли… :)

[vvvphoenix]

Может не надо оживлять призраков. Мало ли… :)

[ultrinfaern]

У Интел было как минимум три возможности перелопатить набор инструкций — при переходе в защищеный режим (286) и при смене разрядности (32 и 64). Все равно для декодирования используется режим процессора/дескрипторы. Но с 64 я смутно помню, что Интел как раз и хотела все перелопатить, но тут подсуетилась амд выпустив быстрее набор инструкций для 64 разрядности.

[vvvphoenix]

Да. Был такой момент. EM64T назывался. Когда Intel на своем поле оказался в роли догоняющего.

[vvvphoenix]

[perfect_genius]

Комментарий не прогрузился что ли?

[vvvphoenix]

Похоже на то :( Кажется я там писал, что не очень -это еще очень мягко сказано. Работал этот блок медленно а энергии потреблял больше чем все осталное

[netch80]

Так они эту песочницу сделали очень слабой в расчёте, что народ побежит на IA64. Сделали бы нормальной — AMD не опередила бы тут.
Какое-то странное у них соревнование — Intel уносится в выси из слоновой кости, AMD ищет явные провалы и затыкает их…

[picul]

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

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

Только вот чем проще ISA — тем больше инструкций содержит код. Длинные инструкции CISC в RISC превратятся не в короткие инструкции, а в огромное количество коротких инструкций. И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC.

[ultrinfaern]

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

[picul]

Ну так загрузили же блоки процессора — в чем же тогда проблема? Декодер работает асинхронно и на большой дистанции не добавляет задержки. Говорят, правда, что в него можно упереться — но у меня вот не получалось, насколько я помню.

[vvvphoenix]

По большому счету это так. Обычно проблемы front end связаны или с предсказанием ветвленией или с промахами в instruction cache. Проблемы с декодером — экзотика. Хотя если еще увеличивать длину командного слова — она может стать реальностью.

[vvvphoenix]

Только вот чем проще ISA — тем больше инструкций содержит код. Длинные инструкции CISC в RISC превратятся не в короткие инструкции, а в огромное количество коротких инструкций. И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC..
Это отчасти справедливое замечание. Но тут я бы хотел послушать компайлерных людей, ибо самому тяжело сравнивать. Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.

[ultrinfaern]

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

[tyomitch]

Чем плотнее код (грубо говоря, чем больше инструкций на килобайт), тем эффективнее используется instruction cache, а это уже сильно вляет на производительность.

[picul]

Думаю, задизайнить ISA так, что бы длина инструкции декодировалась практически мгновенно — не проблема.

[vvvphoenix]

Не уверен. Мне в детстве пришлось повозиться с декодированием битстримов по хаффмановским табличкам. Это сугубо последовательная операция. А при добавлении каких то маркеров появляется избыточность.

[agalakhov]

Как минимум Таненбаум писал, что современные компиляторы используют CISC-процессоры фактически как RISC, генерируют только простейшие инструкции. Мои личные наблюдения это подтверждают: и gcc, и llvm для x86 и для ARM генерируют очень похожий код. Из сложного используется только SIMD.

[tyomitch]

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

[DistortNeo]

Ну так современные процессоры все равно раздраконивают CISC-команды на RISC-составляющие, поэтому и нет принципиальной разницы.

[netch80]

Проверять утверждение про CISC-процессоры на основе ARM — это сильно :)

Но Таненбаум прав в том, что как минимум GCC и LLVM они строго SSA-based. Это резко упрощает оптимизацию верхнего уровня, но приводит к тому, что модифицирующие операции, которые являются основной вкусностью CISC для кодера-человека, теряют смысл (совпадение ячейки аргумента и результата надо ещё явно обеспечить), хитрые комбинированные адресации типа @-(Rn) надо явно собирать обратно из возможно разбежавшихся по коду операций… в итоге получается, что переводить результат после оптимизаций SSA в RISC в десятки раз легче, чем в CISC. Если не будет найдено новых моделей работы компилятора, или хотя бы эффективной свёртки после SSA в CISC-операции — то причин строить новые CISC не будет, от слова «совсем».
(Проблемы кэширования и out-of-band исполнения тут, конечно, играют тоже существенную роль. Но сейчас я не о них.)

[tyomitch]

Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.

Можно собрать лучшее от обоих миров: так, в Thumb-2 команды переменной длины (16 либо 32 бит), но это всё равно RISC ISA, специально оптимизированная под плотность кода. И поскольку длина команды однозначно определяется по старшим битам, то их несложно декодировать параллельно.

[netch80]

В 64-битке ARM этого не делает (пока?)
А вот RISC-V ввели compressed set и за счёт этого уже выигрывают по длине кода перед x86.

[Rutel_Nsk]

Думаю проблема не в CISC, RISC или конкретной ISA, а в недостаточной степени абстракции решаемой задачи от процессора. В целом любая система команд, любой процессор после некоторого времени активной «жизни» обрастет большим числом проблем. Процессор (и не только эта часть вычислительной системы), как живое существо накапливает ошибки, которые приведут его к смерти. На сегодня нет механизма «перерождения» вычислительной системы, кроме как переписывать ПО (пусть даже не 100%) с использованием человека.
PS Да и сам человек (программист) в процессе написания ПО вынужден думать как процессор, а это существенно ограничивает его возможности.
Аналогия программирования: Написание инструкций быстрому, точному, исполнительному но все же «дураку».

[vvvphoenix]

нет механизма «перерождения» вычислительной системы, кроме как переписывать ПО (пусть даже не 100%) с использованием человека.
На моей памяти таких моментов было несколько. SIMD, многоядерность. И да — каждый из них требовал серьезного перелопачивания всей экосистемы. Ну по крайней мере перекомпиляции. Но каждая такая революция была «бархатной». Происходила постепенно и требовала много времени…

[Rutel_Nsk]

SIMD — без переписывания алгоритма? Скорее всего переписали системные библиотеки?
По поводу многоядерности, тут совсем печально, современная вычислительная парадигма (Фон Нейман) не содержит в себе не то что понятия многоядерности, так в ней вообще нет такой сущности как другая точка исполнения команд и изменения данных (поток команд и тд). Соответственно нет никаких механизмов кооперации, синхронизации и распределения решаемой задачи. Наличие одной точки исполнения вообще убило прогресс производительности (в идеале производительность должна линейно зависеть от числа транзисторов).
То что необходимо получить (принципы создания ПО), должно иметь свойство жидкости, заливаемая в любой сосуд принимает его форму. А сейчас мало того что не изменяет форму, так еще и при переносе тащит за собой и часть особенностей предыдущей вычислительной системы.

[lain8dono]

код на хорошо спроектированной CISC ISA окажется короче, чем на RISC

Проблема в том, что семейство x86 имеет плохо спроектированный ISA.

Только вот чем проще ISA — тем больше инструкций содержит код.

На ARMv7 и ARMv8 количество инструкций сравнимо с x86-64 при более простом ISA. По крайней мере это верно для первого попавшегося примера: https://godbolt.org/z/_m4EBC

[picul]

Проблема в том, что семейство x86 имеет плохо спроектированный ISA.

Почему?

На ARMv7 и ARMv8

ARM вообще-то уже давно свернула с RISC-дорожки.

[netch80]

А если считать не в количестве инструкций, а в байтах?
Если не искусственные примеры, то я как-то развлёкся с компиляцией реальной программы (прокси особого сетевого протокола):

-rwxrwxr-x 1 netch netch 344456 лис 24 21:19 qmodo_aa64_s
-rwxrwxr-x 1 netch netch 340376 лис 24 21:10 qmodo_amd64_s
-rwxrwxr-x 1 netch netch 531552 лис 24 21:25 qmodo_mips64_s
-rwxrwxr-x 1 netch netch 466088 лис 24 21:17 qmodo_ppc64_s
-rwxrwxr-x 1 netch netch 355752 лис 26 14:43 qmodo_rv_s
-rwxrwxr-x 1 netch netch 408640 лис 24 21:11 qmodo_s390x_s
-rwxrwxr-x 1 netch netch 336776 лис 24 21:35 qmodo_sparc64_s

RISC-V тут чуть длиннее, но незаметно; и это ещё без compressed команд, которые укорачивают ещё процентов на 20. Неожиданно Sparc опередил на процент:). ARM/64 (aa64) больше аж на 1%. Самый дикий провал у MIPS, неожиданно. Опции сборки одинаковые (-O, strip), везде gcc5, кроме RISC-V с gcc6. s390 жалко: из-за совместимости они вынуждены большинство полезных команд делать 6-байтными, и то нарастание не очень заметное.

[tyomitch]

В менее синтетическом примере 32-битный mips оказался самым компактным.

[netch80]

1. У меня был пример никак не синтетический, а реальная программа, так что «менее синтетический» тут как-то некорректно. C++11 без тяжёлой шаблонизации, простой иерархией типов и т.п.
Tcpdump тут более сомнительный — глубоко системная программа со специфическими оптимизациями.

Можно сейчас на чём-то повторить, но надо, чтобы оно просто компилировалось (без кучи библиотек), иначе у меня не хватит терпения.

2. Вы про 32-битный. Даже если это было так, они это преимущество сейчас теряют (кроме embedded).

[nixtonixto]

Чем мощнее система команд, тем выше производительность в сложных вычислениях за счёт меньшего количества тактов на решение задачи, но и выше энергопотребление. Что сейчас видно на примере x86 (x64) vs ARM. ARM при своей многоядерности и тех же 2...3 ГГц до сих пор не смогли проникнуть на рынок ПК (кроме маломощных компьютеров), но при этом ARM захватил рынок носимых устройств с батарейным питанием.

[Kobalt_x]

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

[beeruser]

а в огромное количество коротких инструкций.

«Огромное» количество это сколько?
Что бы не измерять сферических коней в вакууме, давайте на реальных примерах.
Так вот в реальности ARM часто нужно меньше «коротких» RISC инструкций чем х86 «длинных» CISC инструкций.

[picul]

ARM давно уже CISC.
Вы, кстати, правильно сделали, что взяли «коротких» в кавычки — в ARM длина инструкции не может быть меньше 4 байт, тогда как в x86 — может.

[beeruser]

ARM это не CISC. Это скорее Advanced RISC (что отражено в названии фирмы).
Дело в том, что разработчики архитектуры прагматично подходили к вопросу организации ISA, а не идеологически. Поэтому там были сделаны вещи, нужные здесь и сейчас (т.е. в 80х годах). Вещи, которые плохо ложились на OoO (например conditional execution, LDM/STM). Поэтому архитектура была перепроектирована «с чистого листа» и ARMv8 стал ещё более классическим RISC чем ARMv7.

в ARM длина инструкции не может быть меньше 4 байт, тогда как в x86 — может.

Вообще-то может. Thumb — фиксированная длина 16-бит, Thumb2 — 16+32-бит VLE. Jazellе — 8 бит байткод.
Но это не какие-то особенные инструкции, а просто режим компрессии — для каждой компактной версии есть аналог в полном наборе. Опять же это не делает ARM CISC-ом.
В ARMv8 опять вернулись к фиксированной длина команды, что есть один из признаков классической RISC архитектуры (как я уже говорил).
Что характерно, даже имея фиксированную длину инструкции — 32 бит, плотность кода у ARMv8 выше чем у x86_64.

[mpa4b]

тут интересный вопрос, что именно делает ARM — RISC'ом. если его называть load/store архитектурой — то всё верно. а c очень уж расплывчатым понятием "RISC" как быть?

[vvvphoenix]

Согласен. RISC и CISC — это не четко определенные термины. Скорее «понятия» :)

[beeruser]

Сами термины не имеют чёткого описания, скорее это набор признаков, по которым мы можем их расположить на оси CISC-RISC.
Одним из таких признаков которых является наличие сложных команд. Сложные они не потому что делают несколько операций, а задействуют несколько блоков верхнего уровня (MEM, ALU) (*1) или требуют микропрограмму.

Load-op/RMW команды обычно являются примером таких операций.
Но так как не бывает правил без исключений, в ARM есть и те, и другие.
VLDx, где x=1..4 напоминает load-op, выполняет загрузку и вставку лейнов в несколько регистров. Правда ALU тут не используется и не нарушает правила (1).
infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489h/CIHCCEBB.html

SWP — RMW операция обмена регистра с памятью
infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0489c/Chdbbbai.html
Эта операция считается deprecated, но она есть.

х86 точно так же не является «абсолютным» CISC.
Он не поддерживает ни операции mem->mem, ни сложные режимы адресации,
как умеет 68020.

[rogoz]

операции mem->mem

push dword ptr [eax]

[tyomitch]

Да даже и MOVS[BWDQ].
Но это отдельные инструкции, а не все, как в PDP-11.

[DistortNeo]

Можно даже так:

push dword ptr [eax + ebx*4 + 16]

[mpa4b]

в 32-битном режиме с THUMB-2 — длина инструкций 2 или 4 байта.

[Coocos]

И x86 и ARM (Apple) показывают высокую производительность однопотока. ISA — это только фасад процессора, все самое интересное внутри.

[tyomitch]

Когда фасад занимает 10% чипа (и, вероятно, потребляет 10% электричества) — это уже серьёзно.

[Coocos]

Согласен. Ходит спорное утверждение, что ARM — это медленно.

[netch80]

> И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC.

Самый короткий код сейчас из основных ISA на RISC-V с поддержкой compressed набора. Основной набор у них, как у большинства RISC, из 4-байтовых команд, но они тщательно разобрали реальные шаблоны и зафиксировали их в «сжатом» наборе.
Несжатый у них, у AArch64 — немного длиннее x86.

> Только вот чем проще ISA — тем больше инструкций содержит код.

Так RISC/CISC это не о простоте набора, а о простоте базовой логики одной инструкции. При этом конкретная выполняемая операция может быть нетривиальной, как, например, BFM из ARM.

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

На сейчас это на 100% следствие того, что Intel успел раньше и стал толще. ARM догоняет, но за счёт сокращения подобных утяжелений у него шансы выше.

[ultrinfaern]

Самый красивый набор инструкций был у pdp-11. И его режимы адресации тоже сказка.

[vvvphoenix]

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
B Opcode Mode R Src Mode R Dst

нашел в википедии. Ну да — логика за этим есть. Но как расширять набор команд?

[ultrinfaern]

Ну кто в те времена думал о расширении команд? Тогда новый процессор — новая архитектура. Для 32 разрядной архитектуры он стал VAX-11.
ЗЫ Хотя оригинальный pdp-11 и расширяли — добавили команды умножения/деления, вещественные числа…

[vvvphoenix]

Вот в том то и дело. Хороший дизайн ISA должен закладывать возможности расширения с самого начала. только вот осознали этот очевидный в общем то факт уже в конце 80'х…

[netch80]

Расширять его как раз банально, было бы зачем. В основном наборе много неиспользуемых опкодов (10-77, часть 7000-7777, 75000-76777...) Сделать каждый из них префиксом для следующего 16-битного слова со своими командами — «и телемаркет» ©.
Другой вопрос, что архитектура тупо перестала быть интересной с новыми ресурсами.

[mordusnaglus]

Более того, обработку свободных опкодов можно было делать программно, чем и занимался интерпретатор Фокала на БК-0010, реализуя поддержку чисел с плавающей запятой.

[nerudo]

Все это очень логично, вот только x86 со своим ужасающим набором инструкций работает на 4,5ГГц, а ARM на 3. Хотя технологические возможности Intel и того же TSMC весьма близки.

[vvvphoenix]

О, кстати. Надо будет как нибудь в следующий раз написать про частоту, длину пайплайна и энергопотребление. Это моя любимая тема. Я ещё помню p4, который работал на 10ГГц и охлаждался жидким азотом :)

[b_t]

Уже ждем!

[ultrinfaern]

Только x86 это дескоп/сервер и ему можно жрать энергии сколько хочешь — главное производительность, а arm это мобильные устройства и там прожорливость очень не приветствуется. Только недавно начали пытаться arm продвигать в серверные платформы — посмотрим что получится.

[mistergrim]

Да как недавно — лет пять-шесть уже об этом слышу.

[vvvphoenix]

Насколько я помню спецификации SVE датируется 2017-2018 годом. Ну то есть можно сказать что именно в этот момент arm стал серьёзно заглядывать на ентерпрайс рынок

[kingleonfromafrica]

Вообще лет 10 уже.

Ветку ARM8 х64, при анонсе разработки в 2011 году позиционировали не больше не меньше, как убийцу блэйд-серверов на х86 архитектуре.
В 2015 или 2016 году, вроде, эти самые серверы таки были выпущены, но что то пошло не так :)

[vvvphoenix]

Ну деклараций о намерениях в этом мире всегда хватало… Я то имел в виду, что более или менее реальная жизнь началась, когда ARM взялся за SVE. Имея на вооружении только 128 bit SIMD (NEON) на этом рынка кокнурировать сложно…

[beeruser]

У ThunderX3 4 юнита NEON, т.е. 512 бит суммарно, что даёт 3.3TFLOPS в теории, как и у A64FX.
Для серверов же общего назначения широкий SIMD и не нужен.

kingleonfromafrica
ARM серверы в 2015 и в 2020 это две большие разницы.
Тогда не была готова софтверная инфраструктура. Особенно это касалось загрузки, сборки ОС, работы популярных приложений. Лишь недавно стало возможным пользоваться ARM серверами точно так же как и x86, что видно на примере Graviton2. Сейчас можно скачать образ ОС и запустить его на своей ARM системе, без того, чтобы проверять, есть ли поддержка именно вашей платы.

[kingleonfromafrica]

Это всё понятно, но где же тесты сопоставимых по цене/количеству процессоров/цвету корпуса/etc. конфигураций и обзоры их результатов?
Их нет.
Меня это очень удивляет, если что.
Я бы и сам хотел получить сервер с сопоставимой х86 производительностью, но не требующий двух блоков питания с мощностью как у сварочного аппарата ...

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

Но, реальных решений на ARM как не было, так и нет.

[beeruser]

Это всё понятно, но где же тесты сопоставимых по цене/количеству процессоров/цвету корпуса/etc. конфигураций и обзоры их результатов?

Проблема курицы и яйца. Вы требуете обзор каких-то интересных вам железок, но чтобы они были, ARM серверы должны приносить ощутимую прибыль, чего мы не наблюдаем пока. Думаете по щучьему велению, по вашему хотению появится куча компаний и 100500 моделей серверов?
Сейчас мы находимся в самом зарождении рыночной ниши.
Время покажет насколько она жизнеспособна.
Только гиперскейлы сейчас могут позволить себе экономить на ARM серверах. А для штучной продажи в магазине ARM серверы будут дороже х86.
store.avantek.co.uk/arm-servers.html

Тестов, на самом деле полно. По Graviton 2, A64FX, ThunderX2 есть масса информации.
Последние два используются для суперкомпьютеров Fugaku, Isambard, Astra.

Вот недавно появился обзор ARM-сервера Huawei более близкого к потребностям обычных людей.
servernews.ru/1010630
Тесты это хорошо, но измерять нужно свои нагрузки а не обстрактные 7z в вакууме. Делаете инстанс на Graviton2 и вперёд.

Но, реальных решений на ARM как не было, так и нет.

Ну нет, так нет. Я не продажник, а любитель поразбирать микроархитектуры =)
Уже есть 3 работающих суперкомпьютера на ARM, а будет ещё больше.
Cloud — сервисов на ARM тоже несколько есть. Серверы и СХД на ARM тоже можно купить.

[tyomitch]

arm.com хостится на ARM-серверах, хотя скорее в маркетинговых целях, чем ради экономии на электричестве.

[kingleonfromafrica]

Пример с обзором и тестированием ARM-сервера Huawei очень показателен тем, что ни каких ровно преимуществ у него нет.
При сопоставимой производительности вполне себе сопоставимая потребляемая мощность.
Это близко не обещанные х10 экономии — там о какой либо заметной разнице вообще речь не идет.

Тестирование, замете, выполнено "на поле" ARM. Тестировалось и сравнивалось только то, что на нем вообще запустилось.
Я не хочу тут как то особо ехидничать и понимаю, что проблема "курицы и яйца" имеет место быть, но первое, что мне пришло в голову, это слова представителей Intel про P4 — "это не процессор плохой, это вы программы не правильные под него пишете" на какой то конференции в Москве примерно в 2003 году :)

[xztau]

Ждите MacBook на ARM в 2020-м. Там и сравнят.

[code07734]

Я вижу кроме меня только вы не опускаете ARM в каждом комменте.
Решил с вами поделиться новостью.
Май настал)
www.anandtech.com/show/15813/arm-cortex-a78-cortex-x1-cpu-ip-diverging/4

[vvvphoenix]

Спасибо. Добавил в закладки себе

[vvvphoenix]

Нет, тоже не сколько хочешь. Если бы это так было — не было бы троттлинга. А они троттлятся тока в путь. Power envelopes никто не отменял для серверов. Но там они связаны скорее с отводом тепла.

[VADemon]

Продвигали уже и раньше, да так, что Qualcomm отказался от сей затеи, вот старый бенчмарк: blog.cloudflare.com/arm-takes-wing
Хотя, ЕМНИП, Amazon как раз на ARM дизайнит свои новые процессоры.

[vvvphoenix]

Посмотрел бенчмарки — интересно, спасибо. Потом гляну повнимательнее еще. Первое впечатление — там где требуются длинные SIMD ARM конечно проигрывает. А в остальном — вполне себе ничего

[DistortNeo]

Так и для серверов прожоривость тоже не приветствуется. Собственно, поэтому х86 процессоры в топовых серверах тоже редко работают на частотах выше 3 ГГц.

[vvvphoenix]

Ага. Это хороший пойнт. Google, Amazon и Facebook — никогда не берут топ бины(в отличие от HPC). Они берут системы на 2-3 ступеньки ниже по частоте. Потому что в их прилагах много задержек из за памяти, сетки и тп. И они не хотят платить за циклы, которые процессор намолотит ожидая данные

[maxzhurkin]

Только инструкции x86 выполняются за 2-3 такта, а ARM — за 1, если не ошибаюсь

[AVI-crak]

инструкции x86 выполняются за 2-3 такта

Не совсем так.
Мнемоника — это команды которые считывает процессор из памяти, то что мы можем контролировать глазами через экран монитора.
В арм одна машинная мнемоника имеет от одной до семи отдельных инструкций. Каждая инструкция выполняется синхронно с другими, имеет задержку выполнения от двух до четырнадцати тактов. Задержка потока и физическое исполнение — разные вещи. Читать можно быстрее чем будет фиксироваться физическое исполнение — получается 1 такт. Всё ломается с кодами ветвления.
В х86 одна мнемоника может иметь в своём составе сотни инструкций. Всё точно так-же использует конвейер. Та-же задержка, но теперь на каждую инструкцию отдельно. Идеальный код без ветвлений даёт выполнение одной мнемоники за такт. Но первое-же условие перехода — отбрасывает х86 в пещерный век.
Вся разница в энергопотреблении, и в условиях подсчёта.
Для интела удобно считать скорость через инструкции, потому как всегда получается больше чем у арм.
А для арм удобнее считать через мипс, где интел в глубокой жопе.

[nixtonixto]

AVI-crak
Для Интел МИПСы не имеют большого значения, т.к. те же AVX512, за счёт своей 512-битности, положат на лопатки любой АРМ с его МИПСами. Интел пошёл другой дорогой — добавляя пакеты инструкций для решения задачи минимальным количеством инструкций, классический процессор эту задачу будет решать десятками-сотнями низкоуровневых инструкций. Выигрывая в МИПСах, но проигрывая в скорости решения задачи. Умножая 256 на 256 бит, Интелу потребуется только одна инструкция, причём все операнды лягут в регистры, а АРМ будет умножать столбиком по 32 на 32 бита с суммированием и сохранением в ОЗУ кэша, т.к. ему даже регистров не хватит для этих 128 байт множителей и результата…

[AVI-crak]

nixtonixto
Проверь: две операции умножения AVX512, и после команда ветвления по сравнению результата. Время выполнения должно охладить веру в x86.
Код обязательно в асме вставке, иначе gcc наоптимизирует предварительное вычисление.

[nixtonixto]

AVI-crak
Такие операции используются в сложных расчётах типа шифрования с длинным ключом, вычислений с повышенной точностью, там очень много математики и очень мало переходов. Сам процессор всё так же 64-битный, нет и речи по переводу процессора на 512 бит, поэтому ветвление не пострадало. И компилятор, естественно, нужно использовать знакомый с этим набором инструкций, иначе он действительно наоптимизирует.

[netch80]

AVX512 чудовищно дорог по энергии. На самом деле, даже AVX256 уже дорог — если он не используется, блок с ним тупо обесточивают.
ARM тут, кстати, поступил умнее — сделал блок, которому можно просто задавать любую размерность, которую осилит на практике — так что код не надо переписывать, если следующий процессор станет поддерживать 512 бит вместо 128.

Новые наборы у Intel для конкретных применений, типа видеокодеков — да, факт, начиная с BMI наборов. Но вы ошибаетесь, отрицая это у ARM: ARM это делает вместе с конкретными вендорами и не вынося на общий доступ, поэтому в публичную документацию это обычно не попадает. Какое-нибудь «Умножая 256 на 256 бит» делается внутри Qualcomm или Apple, и доступно под NDA авторам конкретной библиотеки.

[nixtonixto]

Кастомизация процессора под заказчика — страшно дорогая. На рынке смартфонов с миллионными продажами это ещё можно позволить, особенно учитывая fabless статус ARM, но как вы себе представляете кастомизировать процессор под требования конкретного ПО? Наряду с Nvidia Quadro будут ещё и линейки процессоров с определёнными вычислительными блоками? Под видеомонтаж свой, под 3D свой?

Нереально это, поэтому Intel добавляет только универсальные наборы инструкций.

[netch80]

> Нереально это, поэтому Intel добавляет только универсальные наборы инструкций.

Что вы имеете в виду тут под «универсальными» наборами?
Вот смотрю список таких специфических команд Intel:

BEXTR, BLSI… — нужны под конкретные видеокодеки. Завтра или лет через 10 кодеки поменяются, команды станут не нужны.
AES*: ну ладно, AES уже 20 лет как жив и пока не взломали. Но вокруг полно альтернативных шифров. Почему какие-нибудь ChaCha не получили такой привилегии? Только за отсутствие госстандарта?
SHA1*: а вот этот уже устарел, есть подозрения на успешные атаки типа second preimage. Да и SHA256 хоть и активный набор — но SHA-3 уже принят.
CRC32: реализует Castagnoli. Верю, кому-то она нужна. Но это, например, не CRC-32-CCITT, которая в Ethernet — значит, соответствующие возможности аппаратно недоступны. Где используется Castagnoli? iSCSI, SCTP и пара линуксовых файлух? Из этого набора только iSCSI заслужил бы отдельной команды у Intel.
GF2P8AFFINEQB: ещё криптография. Напомнить, что из технологий 1990-х нам остался разве что RSA, и тот всем подозрителен?
ADCX, RORX...: ещё вылизывание под конкретный кодек.

Извините, сказка про "только универсальные наборы" как-то рассыпается.

> но как вы себе представляете кастомизировать процессор под требования конкретного ПО?

Ну вот потому я и говорю про вендоров. Для них встроить свой блог даже в Verilog-представление — не фатальная проблема.

[vvvphoenix]

По идее подобные алгоритмы надо бы поддерживать добавляя(и убирая) новые блоки на SOC, а не новые инструкции. Но это из области тех самых благих намерений...:(

[netch80]

Да, это был бы хороший вариант. Для пользователя это бы выглядело, например, как область памяти, замапленную ему — и надо записать данные, команду и прочитать результат.
Проблема с этим подходом, что он не интегрируется никак в OoO конвейер, не позволяет процессору выбрать, какое АЛУ будет исполнять, и так далее. Поэтому и работать с ним надо более крупными блоками. Например, SHA1 — лучше всего сказать ему «читай с этого адреса», а он дальше будет исполнять. Это уже криптопроцессор :) В чём-то вроде раутера, нацеленного на поддержку 100500 IPSec-соединений, такое точно будет — но в систему общего пользования ставить достаточно неудобно. Уже имеем аналогичный гимор с GPU: пока настроишь, пока данные в него вольёшь…

[vvvphoenix]

Да и еще один конкретный минус такого подхода — далеко не все кастомеры согласны использовать такого рода акселераторы (по разного рода причинам). Долго убеждал людей из одной ну очень большой конторы что видео надо транскодировать на акселераторе. Но так и не убедил.

[mpa4b]

AES делают потому, что он плохо ложится на обычные команды процессора (приходится или табличками, что чревато атаками через кеш, или же долгими и нудными расчётами мультипликативной обратной величины). А чача хорошо ложится на SIMD, как и SHA-3 в общем-то.

[netch80]

Где-то такого комментария я и ожидал :) Спасибо за подтверждение, что данные команды не относятся к «универсальному набору» и предназначены для оптимизации одного конкретного частного применения.

[vvvphoenix]

AVX512 кажется мне одной из самых дорогих ошибок Интела (эта тема наверно заслуживает отдельного поста). Три основные вещи — очередной префикс в Instruction set (ну это не самое страшное). Серьезный рост ядра по площали. Энергопторебление(!!!). С последней проблемой вообще справиться до конца не удалось. С задействованием AVX512 операций частота может просесть на 2-3 бина. И мы вместо прироста производительности получим убыль. Более того, частота выполнения становится непредскауземой и начинает зависеть от условия изготовлений кристалла.
Я не верю, что это проблема интеловской имплементации. Над этим очень умные люди работают и это уже не первое поколение.
А что в итоге? Ну ладно на линпаке (и части BLAS) получается почти двойка… Но на реальных бенчах куда меньше. На большом набор HPC прилаг я видел 8-11%
Посмотрим что у Арма получится с SVE. Но у меня есть твердое убеждение что 256 бит -sweet spot. Нет в природе (существуюзщей базе софта) более длинных векторов.

[Afterk]

Зависит от instruction throughput, а у некоторых он 1/4 такта (MOV, SUB, ADD, INC, CMP, NEG, NOT etc). Можно получить 4 инструкции за 1 такт.

[maxzhurkin]

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

[netch80]

На всех подобных архитектурах инструкции выполняются за много тактов. Можно сделать за один (особенно легко если разделить память инструкций и данных, у Harris+Harris пример, как это делается), но тогда такт будет длиной в самую медленную команду, а это никому не нужно — с DRAM это означает потерю скорости раз в 300.

Реально же одна инструкция даже в идеале выполняется минимум за 2 такта (в первом выбрали из памяти, во втором декодировали и исполнили), полезная же — за минимум 4 (ещё выбрали данные, послали в АЛУ и, если повезёт, на этом же такте записали в выходной регистр). Где вы видите меньше — там качество конвейера, out-of-band блока и прочих, где пока первая команда пишет результат в память, вторая выполняется в АЛУ, третья собирает данные из регистров, четвёртая декодирована и ждёт старта, пятая как раз читается из памяти (пусть другой канал, чем первая пишет результат...)
Показатель IPC (инструкций на такт) у x86 был <=1 только во времена приблизительно до Nehalem (2008). С наступлением Nehalem, Sandy Bridge и последующих, как окончательно закрылись возможности гонки по частоте — Intel и AMD начали оптимизировать именно параллельность в одном ядре, и теперь IPC=5 (то есть, в обратных цифрах, 0.2 такта на команду) не редкость. ARM'у не хватает инженеров, но уже пару лет как IPC=2 реальный тиражируемый результат.

[netch80]

> out-of-band блока
Что-то меня со сна заглючило — везде следует читать out-of-order.

[vvvphoenix]

Да так оно примерно и происходит. Вот статья, откуда я позаимствовал графики. blog.acolyer.org/2017/06/19/hardware-is-the-new-software
Если бы не этот ROM front end x86 давно превысил бы все разумные пределы. Там же оседают другие элементы ISA -например счетчики. Только этот ROM тоже не маленький и не бесплатный. Но поскольку все это не от хорошей жизни никто никогда не расскажет во что он обходится…

[netch80]

Можете почитать про сравнение моделей S/360 и S/370 (внутри каждого из этих рядов). Младшие модели обычно были максимально на микрокомандном исполнении инструкций стандартного набора, а старшие — на аппаратном исполнении вплоть до out-of-order. Разница в производительности доходила раз до 1000.

Для x86, в микрокоде очень мало что полезно писать именно отдельными командами. Туда выносятся инициализация/самопроверка, сложные многоступенчатые операции типа входа/выхода VM, анклавов и т.п., обработки денормализованных (где они ещё не исправлены по сравнению с допотопной реализацией 1970-х) или команды, которые нахрен никому не нужны, но надо поддерживать ради легаси (как RCL/RCR). Выносить туда декодинг — они себе не могут позволить: даже если удастся разогнать этот внутренний автомат до 20 ГГц, его не хватит, чтобы успевать разрабатывать столь путаный поток байтов.

[perfect_genius]

команды, которые нахрен никому не нужны, но надо поддерживать ради легаси (как RCL/RCR)

А если постоянно постепенно выносить устаревшее вне кристалла, чтобы освобождать место? В итоге работать будет медленно, но работать.

[gred]

интересно, что получится, если pdp11 воплотить в железе на сегодняшних технологиях?

[vvvphoenix]

микроконтроллер :)

[aleaksah]

msp430

[ultrinfaern]

Ну вообще можно сказать так — откуда вообще взялся CISC (а pdp-11 это CISC)? А взялся он из-за того что раньше памяти было мало, скорость исполнения маленькая, программы были простенькие, компиляторы и оптимизаторы убогенькие и желательно было (и иногда и нужно) писать все на ассемблере. Поэтому тут для удобства программистов нужен CISC. А потом появились крутые компиляторы куча ресурсов и смысла писать на ассемблере больше не стало. Соответственно и набор инструкций железа уже не имел значения. Поэтому набор инструкций x86 может быть ужасным — никто его не видит. И поэтому реализовал что-то вроде pdp/vax-11 смысла не имеет — никто это не почувствует, только разработчики компилятора. А в разработке компилятора все равно какой набор инструкций — всегда можно что-то подшаманить эффективно исходник переложит на пару кривых инструкций.

[vvvphoenix]

Согласен. Всегда говорил, что не надо программистам мозги ассемблером забивать. У них и так есть баги, дедлайны и начальство. :) И компилятора тоже не надо, самый лучший язык — Java :)

[beeruser]

откуда вообще взялся CISC

Эта классификация появилась намного позже самого создания «CISC» процессоров.

Поэтому тут для удобства программистов нужен CISC.

Ничем не обоснованное, ложное утверждение. Сколько лет вы программировали на асме?

[netch80]

> Ничем не обоснованное, ложное утверждение. Сколько лет вы программировали на асме?

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

> Эта классификация появилась намного позже самого создания «CISC» процессоров.

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

[netch80]

Про вторую часть — не совсем так.
Когда компилятор генерирует, грубо говоря, 99999 из 100000 исполняющихся процессором команд — оптимизация под компилятор становится безусловно важнее умений программиста. Можно под ту несчастную одну стотысячную долю организовать хорошо обученных людей (а не больше половины, как было в 70-е).
Дальше вопрос не в ресурсах, а в качестве самих компиляторов. Хорошая теория типа SSA — это уже 80-е и 90-е, когда основы x86 были заложены; до этого компиляторы делали код заведомо хуже человека, но с этого момента человеку надо хорошо учиться конкретной архитектуре, чтобы обогнать компилятор. С тех пор новых разработок типа CISC не делается — потому что SSA в разы легче ложится на RISC, чем CISC (трёхадресная типовая команда, отсутствие чтения-записи памяти в одной команде (атомарные — явное и дорогое исключение) и т.п.)
Вторым тут работает жутко медленная память, иерархия кэшей и как следствие — неизбежность out-of-order для нормальной работы; межъядерная синхронизация… — даже LL/SC требуют спецкостылей, а если бы заметная часть команд была чем-то вроде PDP-11 «ADD R1,2(R2)» — то скорость падала бы на порядки. Отсюда разложение CISC внутри на RISC микрооперации.
А x86 оказался заложником своего легаси — 32-битная архитектура уже была вся заточена на CISC-подходы без кэшей, out-of-order и многоядерности. AMD могли бы это исправить, но не захотели (возможно, от бедности) — в результате 64-битная система команд ещё хуже 32-битной (кроме отдельных микроулучшений вроде адресации по RIP), а Intel унёсся в небеса, думая, что сейчас все проблемы решатся, память станет быстрой, OoO станет не нужен и т.п. (это про IA64).
Вот с этим легаси и живём.

[tyomitch]

AMD могли бы это исправить, но не захотели (возможно, от бедности) — в результате 64-битная система команд ещё хуже 32-битной

Вероятно, просто на чип не помещалась бы эффективная реализация одновременно двух слишком разных наборов команд.

[netch80]

Им и так пришлось её сделать отдельно: в 64-битке часть опкодов уже работает иначе даже без префикса (некоторые команды с константами), заметно изменён разбор дополнительных байт адресации (какие-то варианты убраны, добавлено RIP-based), на верхнем уровне добавлены REX, убрана часть старых кодов…

Ну может я не вижу какого-то трюка, который бы дал частично это совмещать — но слишком уж они разные.

Кстати, слышал, у Intel в P4 и части ранних Core 64-битка была с сильно урезанным конвейером — они впихнули её просто ради формальной поддержки (в результате 32-битка работала заметно быстрее). Опять же, если бы тут было легко совместить — они бы быстрее сделали полноценную реализацию.

Таки больше похоже на то, что авторам было облом слишком радикально менять.

[vvvphoenix]

Все так. Что то мне не видится, что память в обозримом будущем станет сравнимой с CPU по быстродействию. К тому же вижу все больше ворклоадов(cloud) где ключевой затычкой становится ожидание данных по сетке. Необходимость в скрывании латентностей только возрастает.

[Gordon01]

• Digital signal processors (DSPs) generally execute small, highly optimized audio or video processing algorithms. They avoid caches because their behavior must be extremely reproducible. The difficulties of coping with multiple address spaces are of secondary concern to speed of execution. Consequently, some DSPs feature multiple data memories in distinct address spaces to facilitate SIMD and VLIW processing. Texas Instruments TMS320 C55x processors, for one example, feature multiple parallel data buses (two write, three read) and one instruction bus.
• Microcontrollers are characterized by having small amounts of program (flash memory) and data (SRAM) memory, and take advantage of the Harvard architecture to speed processing by concurrent instruction and data access. The separate storage means the program and data memories may feature different bit widths, for example using 16-bit-wide instructions and 8-bit-wide data. They also mean that instruction prefetch can be performed in parallel with other activities. Examples include the PIC by Microchip Technology, Inc. and the AVR by Atmel Corp (now part of Microchip Technology).

Еще был такой эпизод:

In November 2007, to celebrate the project completion and to mark the start of a fundraising initiative for The National Museum of Computing, a Cipher Challenge[84] pitted the rebuilt Colossus against radio amateurs worldwide in being first to receive and decode three messages enciphered using the Lorenz SZ42 and transmitted from radio station DL0HNF in the Heinz Nixdorf MuseumsForum computer museum. The challenge was easily won by radio amateur Joachim Schüth, who had carefully prepared[85] for the event and developed his own signal processing and code-breaking code using Ada.[86] The Colossus team were hampered by their wish to use World War II radio equipment,[87] delaying them by a day because of poor reception conditions. Nevertheless, the victor's 1.4 GHz laptop, running his own code, took less than a minute to find the settings for all 12 wheels. The German codebreaker said: "My laptop digested ciphertext at a speed of 1.2 million characters per second—240 times faster than Colossus. If you scale the CPU frequency by that factor, you get an equivalent clock of 5.8 MHz for Colossus. That is a remarkable speed for a computer built in 1944."

[Sergani]

Если x86 такой устаревший, почему он такой быстрый?

[vvvphoenix]

А кто говорил, что он устаревший. Я только говорил, что груз legacy велик. А так он живее всех живых :)

[Ankoroid]

Мало того, что живее всех живых, так совсем недавно подавляющее большинство новых айфонов имели на борту x86 процессор :) Правда в связи с недавним проигрышем Intel Qualcomm'у этот исторический зигзаг остается в истории.

Если кто не верит, то: lcq2.github.io/x86_iphone

;)

[screwer]

подавляющее большинство новых айфонов имели на борту x86 процессор

… в модеме! Для его RTOS и прошивки обработки сотовых протоколов.

Но не в качестве Application Processor для основной ОС и приложений.
у кого-то в модемах ARM
у кого-то VLIW (Hexagon).

Пользователь разницы не видит. Айфоны так вообще одно время производились с двумя модемами сразу, в аппарате мог быть как Qualcomm так и интел.
ЗЫ: кстати, забавно что интел-модемы «сливали» куалкоммовским. И даже была тяжба на эту тему — обвиняли Apple, что она специально занижает скорость беспроводных соединений у аппаратов с модемом Qualcomm, чтобы они не отличались от таких же, но с модемом интел.

[Ankoroid]

… в модеме! Для его RTOS и прошивки обработки сотовых протоколов.

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

у кого-то в модемах ARM
у кого-то VLIW (Hexagon).

Hexagon — это DSP.
В модемах — да, есть прямая конкуренция, причем x86 показал, что он не хуже.

Пользователь разницы не видит.

Вообще-то видят, просто они не знают, кого винить в том, что у него внезапно данные не передаются.

в аппарате мог быть как Qualcomm так и интел.

На стороне сотового оператора много чего видно и статистика есть…

кстати, забавно что интел-модемы «сливали» куалкоммовским.

Это не удивительно, Qualcomm все таки накопил огромную базу кода (я видел части, это кошмар), с кучей условных #ifdef, это крайне сложно переписать по спецификациям.

[spqr_voldi]

Быстрый для чего и по сравнению с чем?

[potan]

Потому что разработка хорошо финансируется.

[VelocidadAbsurda]

К вопросу о сложности компиляторов для VLIW: ок, нужно подбирать порядок инструкций для максимального заполнения «пакетов». Но разве это не схоже с задачами, решаемыми out-of-order архитектурами в железе? Однако у компилятора по идее для этого куда больше ресурсов — больше информации о коде, мягче требования к скорости. В чём загвоздка?

Посчитал (руками в дизассемблере) среднее заполнение пакета в случайно выбранной функции из примерно 500 инструкций (функция — управляющий алгоритм общего плана, никакой DSP специфики) для VLIW-ядра QDSP6 (оно довольно распространённое кстати, по нескольку в каждом SoC/модеме от Qualcomm), получил 62.5% (2.5 из 4). Интересно, как это соотносится с эффективностью переупорядочения инструкций тем же x86?

[DistortNeo]

Однако у компилятора по идее для этого куда больше ресурсов — больше информации о коде, мягче требования к скорости. В чём загвоздка?

Загвоздка в том, что:

1. У разных процессоров может быть разное количество функциональных блоков, разные задержки. То есть код получается жёстко привязан к конкретному процессору.

   
   

2. Предсказание ветвлений в современных процессорах — динамическое, тогда как компилятор генерит статический код.

   
   

3. Программы под x86 и так компилируются непозволительно долго. А для VLIW это время вырастет ещё на порядок, либо придётся генерить неэффективный код.

   
   

[beeruser]

Никто не мешает предсказанию ветвлений во VLIW быть динамическим.
Просто в бандле будет один переход, который точно так же предсказывается BTB.
За примерами не нужно далеко ходить.
en.wikipedia.org/wiki/Transmeta_Efficeon

the Efficeon has… one branch prediction unit

Хотя, конечно, современные OoO процессоры могут выполнять до двух переходов за такт.

Время компиляции не сильно отличается. Даже на Эльбрусе это не является проблемой.
Для Интел так же нужно двигать инструкции из-за требований DSB к их выравниванию.
Да и декодеры вовсе не симметричны. Первый декодирует 4 МОП, остальные 1 МОП.

«Causes of Performance Instability due to Code Placement in X86 — Zia Ansari, Intel»
www.youtube.com/watch?v=IX16gcX4vDQ

[tyomitch]

Дело не в предсказании ветвлений как таковом, а в том, что OoO-процессор может выполнять код после ветвления параллельно с кодом до ветвления, тогда как VLIW-компилятор не может код после ветвления объединить в бандле с кодом до ветвления.

[beeruser]

VLIW-компилятор не может код после ветвления объединить в бандле с кодом до ветвления

Бранч и будет завершающей операцией в бандле.
Если вы переживаете на счёт потенциально пустых VLIW слотов, то начать вычисление можно спекулятивно. Во VLIW/EPIC процессорах как правило есть механизмы спекулятивного выполнения на уровне ISA.
По сравнению с другими проблемами VLIW, эта совершенно незначительная.

[ShadowTheAge]

Тут еще проблема в том что если Intel выпускает новый процессор в котором добавятся out-of-order блоки или теневые регистры — то все программы начинут работать немного быстрее. А если выходит новый VLIW процессор с еще больше увеличенной длиной слова, то старые программы быстрее работать не начинают, а новые начинают занимать еще больше места.

[netch80]

> Но разве это не схоже с задачами, решаемыми out-of-order архитектурами в железе? Однако у компилятора по идее для этого куда больше ресурсов — больше информации о коде, мягче требования к скорости. В чём загвоздка?

1. VLIW — аббревиатура не показательная. Лучше про эти реализации говорить как EPIC.

2. Загвоздка в том, что в случае, когда исполнение отдельных команд зависит от непредсказуемого внешнего ресурса — предсказание ухудшается в принципе, а если та скорость различается раз в 300 (как с доступом к DRAM) — оно неэффективно настолько, что лучше говорить про его отсутствие.

Вот вам надо, например, выполнить два сложения:

out1 = a + b
out2 = c + d

На типовом RISC это выльется в:

load r1, a (1)
load r2, b (2)
add r1, r1, r2 (3)
store r1, out1 (4)
load r3, c (5)
load r4, d (6)
add r3, r3, r4 (7)
store r3, out2 (8)

или во второй группе регистров могут быть те же r1, r2 — блок переименования регистров назначит им два новых, без разницы.
Команды 1, 2, 5, 6 между собой совершенно независимы, OoO может назначить их выполнять в любом порядке.
То же про 3 и 7, 4 и 8 — в каждой паре связи нет.

Пусть стиль типа IA64 — три субкоманды на команду, но с неявной строгой последовательностью (реально в IA64 метки следования явные, но пусть тут так для иллюстрации). Компилятор может собрать их в:

load r1, a; load r2, b; load r3, c
add r1, r1, r2; load r4, d; nop
store r1, out1; add r3, r3, r4; nop
store r3, out2

или так:

load r1, a; load r3, c; nop
load r2, b; load r4, d; nop
add r1, r1, r2; add r3, r3, r4; nop
store r1, out1; store r3, out2; nop

или ещё с полдесятка аналогичных вариантов… скорее будет ближе к первому варианту, чем ко второму.

А теперь представьте себе, что b, c, d — в кэше L1, а a — не в кэше (ждём 300 тактов). Чтение a задерживает не только первый add, но и всех последующих, хотя мы давно могли выполнить операции для c+d. Но стоим ждём…

На таком примере кажется, что это мелочь и эффект не столь заметен — или что возможности IA64 реально шире (да, там можно в пачку собирать не одну тройку команд, а много). Но границы всё равно надо ставить явно. У SkyLake, например, OoO конвейер на 97 исходных команд x86 и 224 сгенерированных из них микроопераций — значит, это выгодно. И в таком конвейере может вполне быть, что 1-я команда ещё ждёт чего-то, а 97-я уже выполнилась. А на EPIC мы такого не получим, задержки будут чудовищными.

Я думаю, этот ваш QDSP6 работает поверх статической памяти (её ж много не надо).

> Интересно, как это соотносится с эффективностью переупорядочения инструкций тем же x86?

Вот линия Core (с ~2005), в отличие от Pentium 4, уже имела качественный внутренний заполнитель. С тех пор его ещё в разы улучшили.

[Gryphon88]

А теперь представьте себе, что b, c, d — в кэше L1, а a — не в кэше (ждём 300 тактов). Чтение a задерживает не только первый add, но и всех последующих, хотя мы давно могли выполнить операции для c+d. Но стоим ждём…

А разве компилятор не может (должен) добавить префетч?

[netch80]

Префетч где и для чего? Проблема же именно в том, что компилятор обязан явно вставить метку синхронизации («architectural stop») между командами, где есть зависимости. Если он не поставит такой стоп между load r1, a и add r1, r1, r2 — то процессор решит, что он имеет полное право выполнить их в любом порядке — и этот порядок может оказаться обратным ожидаемому.
Представьте себе, что этот код — в отдельной функции. Вызываемая функция не знает про необходимость сделать префетч — будем тормозить и ждать.
OK, пусть это часть большой функции. Тогда мы дали префетч тактов 50 назад, а на прочитать из DRAM надо 300. Стоим ждём…
Ну и сами префетчи место занимают — надо их закодировать, адрес предварительно вычислить и тоже его сохранить…

[Gryphon88]

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

[netch80]

> Префетч может быть сделан до входа в функцию, если перед её вызовом нет ветвления?

Нет, если сам программист не позаботился об этом, потому что просто не на чем предсказать, когда и как его выполнять. Компилятор получает такие знания при инлайнинге, и то это работает не всегда — адрес может быть следствием вычислений в функции.
По крайней мере сейчас логика префетча включается, AFAIK, только в векторизованных циклах. И то — она обычно работает на ситуацию «строка DRAM уже открыта, надо выбрать следующие 64 байта в этой строке», а не «идём на произвольный другой адрес, на переоткрытии строки теряя 200-300 тактов». Потери такого порядка (самые длительные) компилятору недоступны для понимания и могут быть отработаны только человеком.
И вот тут как раз, если OoO со свободным переупорядочиванием даёт хотя бы 20-30% ускорения, то оно стоит реализации.

[Gryphon88]

Спасибо, я надеялся, что одновременно с графом исполнения строятся и тайминг-диаграммы. В х86 латенси фиг просчитаешь, а вот во VLIW и ARM это должно быть хотя бы теоретически возможно.

[netch80]

Возможность более-менее реально оценить задержки зависит не от того, X86 это, Itanium или ARM, а от источника самих задержек — памяти. А также того, что стоит по пути к ней — это кэши и система синхронизации этих кэшей между разными ядрами и процессорами.
Устранить эти задержки очень просто… ставите static RAM. Для этого нужно… ну вот смотрю — 32GB (нормальный объём в 2020 для десктопа, где запускается что-то не только для дома) стоит (2*16) — около 220$. Для SRAM надо будет его (если будет массово производиться в сходных объёмах! а также спроектированы и вылизаны контроллеры и модули памяти) умножить этак на 6-12… возьмём самую оптимистичную цифру (6), получим 1320$. Вы готовы столько платить?
Я думаю, что для зверя типа «рабочая станция» с софтом, который может стоить не меньше — это подъёмно. Но рынок со мной не согласен. У большинства запросов достаточная локальность, чтобы кэш сокращал большинство задержек. Не все, но большинство. Но разница между 1100$ на памяти и, пусть даже, 50$ на OoO-блок — никак не в пользу быстрой памяти…

[Gryphon88]

Сразу скажу, что это диванная аналитика, область для меня чужая.

А также того, что стоит по пути к ней — это кэши и система синхронизации этих кэшей между разными ядрами и процессорами.

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

Но разница между 1100$ на памяти и, пусть даже, 50$ на OoO-блок — никак не в пользу быстрой памяти…

Но если учесть затраты на программистов, которым нужно больше мозгов и следовательно зарплаты, уже можно подумать. Жаль, интересанты разные :)

[DistortNeo]

Поведение не станет предсказуемым, потому что есть ещё и многоядерность, и работа с памятью ведётся по принципу "вас много, а я одна". Помимо разведения кэшей придётся ещё и разводить память, переходя к NUMA-архитектуре. Кстати, в первых Threadripper именно так и было.

[Gryphon88]

Оно не станет полностью детерминированным, но станет более предсказуемым, можно будет подогнать данные заранее. Имхо, когда данные ждут в L3 лишние 100 циклов, лучше, чем если проц ждёт данные из памяти 100 циклов.

Помимо разведения кэшей придётся ещё и разводить память, переходя к NUMA-архитектуре

Почему бы и нет? Каждому ядру свой канал, например. Не понимаю, почему это должно пугать: при программировании для GPU NUMA уже есть, но есть и инструменты, уменьшающие геморрой.

[vvvphoenix]

Почему бы и нет? Каждому ядру свой канал, например. Не понимаю, почему это должно пугать: при программировании для GPU NUMA уже есть, но есть и инструменты, уменьшающие геморрой.

А далеко не всегда получается с этим геморроем справиться. Оч сильно от ворклоада зависит.

[DistortNeo]

Оно не станет полностью детерминированным, но станет более предсказуемым, можно будет подогнать данные заранее. Имхо, когда данные ждут в L3 лишние 100 циклов, лучше, чем если проц ждёт данные из памяти 100 циклов.

Собственно, и сейчас ничто не мешает подогнать данные заранее. Просто алгоритмов, которые на 100 тактов вперёд могут однозначно определить, какие данные им понадобятся, не так уж и много. Навскидку — это алгоритмы обработки изображений, не имеющие ветвлений, но они как раз вполне нормально реализуются на GPU. Ну и по своему опыту могут сказать, что расстановка префетчей в реальных алгоритмах — как мёртвому припарка, эффекта практически нет.

Почему бы и нет? Каждому ядру свой канал, например.

Потому что нагрузка на память неравномерная. Например, одно ядро молотит большие матрицы с использованием AVX-512, а другое работает с данными, помещающимися в L2-кэш.

А ещё добавьте сюда обмен данными между памятью и различными устройствами — видеокартой, жёсткими дисками. Оно вообще минуя ядра идёт.

[vvvphoenix]

Ну и по своему опыту могут сказать, что расстановка префетчей в реальных алгоритмах — как мёртвому припарка, эффекта практически нет.

Cогласен на 99%. Хардварные префетчеры очень четко отрабатывают простые паттерны доступа. Добавить что то поверх них, как правило не выходит.

[Gryphon88]

Знаете, иногда хочется перенестись назад во времени, куда-ть в 60е и сказать «Не надо так. Нафиг общую шину». Нелогично, но иногда хочется, чтобы у каждого ядра стояло в монопольном доступе по палке памяти в виде L4 кэша :) А всё общение с хардваром и системные вызовы унести на отдельный процессор.

[netch80]

Проблема в том, что всё это чудовищно сложно, много острых углов в тёмных местах, а умных и грамотных людей, которые способны конструктивно что-то разрабатывать… судя по темпу развития и проблемам, на которые натыкаемся на ровном месте — совершенно недостаточно.

Вот например MESI протоколы синхронизации кэшей — везде в обычных книгах описывают только состояния, не упоминая сложность переходов. Действительно, кодеру достаточно понимать базу (достаточно ли?) А реализатору — ещё и сообщения, как они себя ведут (краткий обзор тут). И тут «открылась бездна, звезд полна». Помните, в конце 1990-х были популярны чипсеты от Serverworks? У Intel тогда эта синхронизация была настолько глупо сделана, что на Serverworks система могла работать раза в два быстрее, ничего больше не меняя в железе и софте. Кончилось закономерно — их скупили и алгоритмы применили у себя. У Intel мало разработчиков? Вроде достаточно:) но всё равно работы безумно сложны.

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

[vvvphoenix]

У Intel мало разработчиков? Вроде достаточно:) но всё равно работы безумно сложны

— Много. И Умных. Но каждый копошится в своем углу. Полную картину вряд ли кто то понимает…

[Gryphon88]

А если чуть серьёзнее, то я понимаю, что предлагаю дичь в стиле «разрушить и построить». Интересно, когда-нибудь будет осуществлён такой радикальный подход? Всё-таки традиционное усложнение с каждым годом всё хуже работает, придётся упрощать, и тут «менять не меняя» навряд ли получится.

[Gryphon88]

Потрясёт — заметим, тут как с новыми аккумуляторами. Им понадобится как минимум новый компилятор для своей архитектуры, а может и новый язык и трансляторы для топ-5 языков в этот язык, голая платформа вряд ли кого-то потрясёт.

[vvvphoenix]

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

[vvvphoenix]

И все препеисать заново?

[Gryphon88]

Понимаю всю вероятность такого решения :) Но, имхо, когда-нибудь придётся, когда груз легаси станет слишком велик и будет проще переписать.

[vvvphoenix]

Такой ад это будет… Даже думать не хочется. Уж лучше бинарная трансляция. Хотя я ее терпеть не могу.

[vvvphoenix]

Но если учесть затраты на программистов, которым нужно больше мозгов и следовательно зарплаты, уже можно подумать

.
Часто ловлю себя на мысли, что мне уже мозгов не хватает. То ли я стал настолько старым, то ли программирование стало настолько сложнее. Похоже и то, и другое… :(

[vvvphoenix]

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

А уж скока места он занимает — просто кошмар. Но надо сказать, что он адресует много корнер кейсов. Там где простенький анкор AMD зачастую ломается и проседает по производительности, интеловый держится.

[vvvphoenix]

«строка DRAM уже открыта, надо выбрать следующие 64 байта в этой строке», а не «идём на произвольный другой адрес, на переоткрытии строки теряя 200-300 тактов». Потери такого порядка (самые длительные) компилятору недоступны для понимания и могут быть отработаны только человеком.

И то не всегда. Мои «любимые» кейсы — вычисления с двойной идексацией. По первому индексу берешь второй из массива (огромного) и ловишь кэш мисс. А потом по этому индексу читаешь данные из другого массива (еще больше). И разумеется ловишь второй. И сделать с этим ничего нельзя. Даже программистов поубивать, потому что код 40 лет назад написан :)

[Gryphon88]

Ждём, когда в компиляторы завезут преобразование AoS<->SoA и инлайн данных :)

[DistortNeo]

И то — она обычно работает на ситуацию «строка DRAM уже открыта, надо выбрать следующие 64 байта в этой строке»

А разве это не связано с банальным размером кэш-линии? Программа запросила байтик, процессор не нашёл его в кэше, психанул и загрузил burst-ом из памяти сразу 64 байта, так на всякий случай.

[netch80]

Ну да, грузится кэш-строками (лучше не «кэш-линиями», это таки плохой перевод). Я про другое. Строка DRAM это что-то сильно более длинное — например, в 16GB модуле она может быть 64KB или 128KB. Открытие строки это чтение (разрушающее) из собственно строки и перенос в кэш (на триггерах) в модуле памяти. Закрытие — запись обратно в основную DRAM. Модуль DRAM открывает/закрывает только целыми строками. Если строка уже открыта, прочитать её соседние байты сильно быстрее, чем из другой строки. Если надо открыть другую, то закрытие текущей и открытие новой это длительная операция (сколько там лучшие результаты на сегодня — 20 нс? а на бюджетных модулях 30-40.) Поэтому локальность данных получается не только в один уровень — размер строки кэша (64 байта на x86 начиная с Core), но и во второй — соседние несколько десятков килобайт тоже будут быстрее читаться.
Собственно, поэтому и делают автоматический префетч в процессоре (алгоритмы его у разработчиков за ста семью замками, но его существование известно): высокий шанс на использование этих данных и лёгкая доступность, значит, «надо брать».

[vvvphoenix]

ну по идее 2.5 из 4 нормально. Если это конечно не Linpack. :) Но есть несколько вопросов -сколько всего команд предоставляет архитектура (примерно)? сколько времени разрабатывается компилятор? В интеле компилятор для Itanium задышал лет через 5 только. И самое главное — если в системе добавляются новые инструкции, сколько времени уйдет на перестройку компилятора?

[screwer]

>> сколько всего команд предоставляет архитектура (примерно)?

дохрена

>> сколько времени разрабатывается компилятор?

раньше Qualcomm дорабатывали GCC. Потом перешли на LLVM. Соотв. доработка заключается только в работе над кодогенератором.

>> И самое главное — если в системе добавляются новые инструкции, сколько времени уйдет на перестройку компилятора?

Весь же он перестраиваться не будет…

[vvvphoenix]

Ведь он же перестраиваться не будет… — в этом то и дело. VLIW системы сложно модернизировать. Мне думается задачка компляции для VLIW близка к NP-полной проблеме. Ну по крайней мере куда ближе чем RISC. поменял немного в наборе команд — и привет, все надо строить заново

[potan]

В среднем длинна инструкций у x86 как раз небольшая, часто встречающиеся инструкции короче.

[vvvphoenix]

Писал выше уже. Да этот так. Можно пойти еще дальше и закодировать часто встречающиеся инструкции и последовательности арифметическими (или хаффмановскими кодами). Плата за это — невозможность параллелить декодирование.

[hhba]

Кажется очевидным, что простота и ортогональность ISA (и соответственно простой фронтенд) — хорошая академическая концепция, которая не может обеспечить предельных параметров. Именно поэтому мы видим то, что видим — процессоры ARM отнюдь не являются «академически чистым RISC», а трижды проклятый х86 как натягивал всех, так и натягивает, и нет этому конца. Просто не у всех есть лицензия на х86, поэтому и существует в природе дискурс «а вот ARM/MIPS/Power лучше». :)

Но у этой медали есть и оборотная сторона — сегодня вы можете взять, например, Jetson Nano или Zynq UltraScale и сделать на них нечто чумовое, что ни на каких решениях от Интела вы не сделаете, потому что nVidia и Xilinx в комплекте с не Бог весть какими ядрами от ARM предлагают от себя нечто особенное. И пусть те ядра сравнимы с ядрами х86 десятилетней давности, но вы ни десять лет назад, ни сейчас не могли у Интела купить что-то аналогичное в комплексе. Вот в этом и есть настоящий успех ARM.

[Dr_Sigmund]

трижды проклятый х86 как натягивал всех, так и натягивает

Он их «натягивает» примерно по той же причине, по которой стандарт 110В продолжает «натягивать» 220В в США — на него слишком много всего завязано, перейти на любую альтернативу, будь она хоть в три раза эффективнее по энергопотреблению или средней длине кода, очень сложно, долго и дорого.

[tyomitch]

Не только в США, а в обеих Америках, в Японии, и в части Африки.

[Dr_Sigmund]

Про Японию знал, а вот про Южную Америку — нет.

[nixtonixto]

Dr_Sigmund
Не совсем так. Вот я бы купил ноутбук для работы (трёхмерная графика) на ARM, но на них для работы нет ничего — есть только недопланшеты с прикреплённой клавиатурой, для которых максимум — браузер и плеер. Всё, что сложнее — дико лагает, независимо от частоты и количества ядер.

[picul]

А можно поинтересоваться, зачем для работы ноутбук именно на ARM?

[nixtonixto]

Здесь же утверждается, что у ARM более совершенная система команд, а следовательно — лучше экономичность. Если ноутбук равной производительности от батареи той же ёмкости (и веса) будет работать хотя бы на 50% дольше, я не пожалею ради него денег.

[picul]

А экран, видеокарта, диск, Wi-Fi адаптер тоже на ARM-архитектуре? :) То что процессор будет есть 10W вместо 15 — погоды не сделает.

[nixtonixto]

В телефонах и планшетах это всё есть, и они от батареи 5...10 А*ч умудряются больше 10 часов работать… Диски теперь без мотора, поэтому потребляют пару Вт. А вот 10-Втный ARM вместо 35...45-Втного Интела той же производительности, может заметно продлить время работы типовой ноутбучной батареи.

Ну а если заметной экономии не будет — то к чему вообще весь этот спор про системы команд?

[picul]

В телефонах экран меньше, видеокарта вообще не то — допускаю, что при работе с 3D-графикой Вас не устроит жалкое тайловое ядро из мобилок. А 10-ватный ARM не будет иметь ту же производительность что 35W интел — все же кроме нехороших декодеров инструкций, которые чуточку сложнее чем ARM'овские, есть ALU, кеши и другие блоки, которые никуда не денутся — а они и потребляют основную мощность, между прочим.
К чему спор про ISA — ну, каждому свое. Мне интересна преимущественно скорость исполнения, которая может поменяться при изменении системы команд — энергопотребление на втором плане.

[vvvphoenix]

Я тоже раньше был равнодушен к энергоптреблению. Для существующих систем это и правда не так важно. Но вот при проектировке будущих эти соображения вылезают на первый план. Мы все сильнее упираемся рогами в разного рода power wallы…

[Dr_Sigmund]

Так это и есть один из участков замкнутой петли. Вы бы ноутбук на ARM, может, и купили, но большинство покупателей предпочтёт x86, потому что абсолютное большинство прикладного софта — на x86 (а возиться со сборкой из исходников готовы далеко не все, да и большинство коммерческого ПО не open-source). Поэтому производители ноутбуков их не делают — не ждут достаточного спроса, и продолжают выпускать устройства на x86. А производители софта продолжают его писать под x86, потому что большинство железа у клиентов — на x86.

[nixtonixto]

Мне для работы достаточно 2 приложений, которые есть и на Мак, и на Линукс, и на Виндовс (плюс Офис и браузер, которые есть для любой ОС, поэтому не учитываем). Было бы подходящее железо — скомпилировали бы и на ОС под ARM. Но увы, ARM процессоры слишком слабы.

[Dr_Sigmund]

Ну а мне, к сожалению, двух приложений не хватает. Нужен Windows RSAT — всё, только x86.

[vvvphoenix]

Ага. Подобные самоподдерживающиеся (рефлексивные) процессы eще Джордж Сорос любил описывать.

[hhba]

Легаси — отдельная тема. Я о том, что за Интелом не угнаться в большинстве сегментов в части производительности и эффективности в расчете на ватт или что-нибудь еще.

[hhba]

Ну нет же, результаты тестов нормируются на ГГц, и именно на равных частотах Интел всех и уделывает.

Тут не спорить нужно, а профильные ветки читать, где люди тестами сами занимаются, по крайней мере я так делаю, поскольку сам в тесты не умею )))

[hhba]

Не буду спорить, здесь это вряд ли уместно, есть другие площадки. Безусловно прогресс есть у всех, но на картину надо смотреть реально.

[hhba]

Тут я должен поправиться — я имел в виду «х86 vs ARM/Power/прочие» (в тему поста), вопрос сравнения Интела и АМД был скорее вне этого дискурса (вы сочли, что я и АМД записал в аутсайдеры, когда писал только про Интел, а я своевременно вашу реакцию не отрефлексировал, был неправ).

[hhba]

Был невнимателен, сорян!
Тут на одном экране работа, на другом уведомления с Хабра в почте сыпятся, бывает всякое ))

[hhba]

Ну, справедливости ради Интел никогда не почивал на лаврах, но, да, конкуренция всегда во благо. Я бы даже сказал, что среди «прочих» конкуренция слабее.

[picul]

занёс некоторым разрабам бенчмарков (которые подумали-подумали и внезапно уменьшили вклад многопотока в общую оценку производительности)

А были пруфы на этот счет? Холиварить сейчас не в настроении, но если это действительно не просто вывод интелохейтеров — хотелось бы знать.

[picul]

По поводу изменений как таковых. Согласен, что внезапно взять да урезать влияние многопоточности на оценку процессора — это из категории «чет падазрительна». Но с другой стороны — согласитесь, что за последние годы количество ядер в процессорах растет быстрее чем когда-либо; тем временем, софт в основном поддерживает многопоточность все так же плохо, как раньше (подвижки есть, но они и близко не такие, как в случае ядер у процессоров). Поэтому лично я считаю, что в такой ситуации снизить фактор многопоточной производительности — это нормально. Не знаю на счет UserBenchmark, возможно они переборщили с модификациями — но сам факт изменения формулы ИМХО вполне оправдан.
На счет злополучного сравнения — я так понимаю, Вы имеете в виду i3-8350K vs 2700X. Давайте вместо него посмотрим на i3-9350KF vs 3700X. Там такое же скромное преобладание интела в однопотоке и огромное преобладание AMD в 8-core. Но еще там есть вкладка с FPS-ами в играх. Видим, что наглову разбитый Intel внезапно показывает себя лучше, чем AMD. Да, я понимаю, что теоретический пик FLOPS'ов у AMD больше. Но подавляющее большинство пользователей не сможет их использовать (у меня не получилось загрузить 6/12 процессор на полную ничем кроме компиляции плюсового проекта). Поэтому то, что оценка Интела лучше, чем AMD (напомню, что она всего лишь +2%) — это как раз то что нужно для подавляющей массы пользователей. А эксперты вместо горения могут проскроллить страницу и посмотреть на результаты конкретных тестов. А если не могут — возможно они просто относятся к подавляющей массе? :)

[picul]

А давайте.

Хмм, это интересно :) Видимо они также учитывают Value for Money и Price. Ну или действительно все поломали. Хотя, согласитесь, что для обычного смертного 8400 за $175 действительно лучше чем 9980XE за $1150.

Плюс утверждение про то, что большинство ради игр берут комп тоже так себе.

Верно, еще для серфинга в Интернете, офисных приложений… Сколько ядер они загружают?

фанатизм или подкуп

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

Так вот, банально, то, что вы не можете нагрузить 6/12 показывает превосходство сего процессора на 4/4.

Его превосходство в компилировании плюсового кода. А в браузере, Word'е и большинстве игр 4/4 с +10% однопотока будет лучше.

[rogoz]

Этой истории уже больше года, во многих местах писали, сравнительно свеженький апогей так сказать: twitter.com/VideoCardz/status/1250718257931333632/photo/1

[picul]

Циферки вышли красивые. Да, пожалуй их формулы немного сломаны. С другой стороны, Intel быстрее в однопотоке на 10%, а его оценка больше всего на 3.5%.

[hhba]

Тем не менее Интел безо всяких пинков внедрял много разных интересных вещей типа AVX2 например, тратили деньги на историю любви с Альтерой, так что они как раз отнюдь не та компания, которая будет ВАЗ-2105 выпускать без изменений, если нет повода. Но конечно откровенно рисковать бюджетом и рвать зад в отсутствие конкурентов никто не будет, потому я и согласился с тем, что конкуренция во благо. Причем я не думаю, что Интел что-то принципиально новое сейчас придумывает, скорее достает из загашника то, что было аккуратно придумано в «тучные годы». Скажем прямо — не все конторы так умеют.

[picul]

попытка его использования ведёт к сильному падению производительности

ЕМНИП путаете с AVX512.

[netch80]

Нет, уже с 256 заметно. Или тут. Если AVX не используются, соответствущие блоки выключаются.

[hhba]

которую многие оценивают как большой фейл, ибо попытка его использования ведёт к сильному падению производительности, потому что блоки больно горячие и вызывают просадку частот ниже базовой?

Однако многие аплодируют стоя )))

[DistortNeo]

AMD потеряла все полимеры как раз к 2008 году. А Intel добила AMD, выпустив Sandy Bridge с AVX в 2011 году, после чего и наступил застой.

[hhba]

Эх, Брежнев Сандики, застой, ностальгия! В 2011 году я мечтал купить себе i5-2500K, но денег пожалел. :)

[vvvphoenix]

Я смотрю на процы довольно просто. По сути все сводится к байтам на флоп. Stream/Linpack :) Мне думается, что самым сбалансированным чипом был Nehalem. Хотя по сравению с нынешними Сандик тоже очень неплохо смотрится…

[vvvphoenix]

Кто? Маркетологи? :)

[hhba]

Те, кто пишут софт, использующий векторные расширения.

[vvvphoenix]

Не зря наняли со стороны специалиста и тот первым делом начал бюрократию разгонять внутри своего куска ответственности)
Про Келлера?:)

[vvvphoenix]

Скоро все будут чиплетами. Монолит доживает свои дни. Ну разве что в нижних сегментах останется

[code07734]

>Ну нет же, результаты тестов нормируются на ГГц, и именно на равных частотах Интел всех и уделывает.
Нет, не уделывает
Вы тут про обьективность писали.
Так вот — я не сторонник какой-то фирмы.
Обьективно рейтинг по spec примерно такой:
1.Ice Lake
2.zen 2 — apple a11-13
3.skylake-coffelake — cortex-a76 — zen/zen+ apple a10

Ice lake чуть вышел вперед, но у него ядра совсем жирные стали.

[code07734]

>И пусть те ядра сравнимы с ядрами х86 десятилетней давности
Держите, вы уронили
www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/5

[vvvphoenix]

Спасибо за ссылочку. Хороший набор бенчей из уважаемого источника. Жалко только что AMD Rome там нет. Картинка была бы полнее.

[code07734]

www.anandtech.com/show/14664/testing-intel-ice-lake-10nm/4
Здесь ice lake и zen 2 в одном тесте. Они действительно оставили ARM вновь позади.
У ARM есть еще cortex a77, и в этом году будет что-то еще.
Armv8 всего 9 лет. А развитие фактичски началось с cortex a72 в 2015 году.

[hhba]

Простите, это вы к чему? Я писал про вполне конкретные микросхемы на вполне конкретных ядрах А57/А53, а не про Graviton2. Сравнение Graviton2 с решениями от Интел — отдельная веселая тема, поэтому я ее тут не поднимаю )))

[code07734]

Согласен, a57/53 не очень. Расскажите что веселого в том сравнении?

[hhba]

С полгода назад на хоботе это все обсуждалось, было весело, зайдите поглядите ))

Ну и, повторюсь, Гравитон/Гравитон2 — лишь одна ниша, пусть и довольно большая. Не зря именно в нее уже более пяти лет бьются примерно одни и те же лица, в другие ниши как-то совсем не лезет (помимо, конечно, эмбеда, о чем я выше написал).

[code07734]

Я без ссылки не найду. Впервые о хоботе слышу. Да и сказали бы в двух словах

[hhba]

Даже ссылку на ветку дам:
forum.ixbt.com/topic.cgi?id=8:25877

[code07734]

Информация по теме не найдена.
Вообще я сначала не понял что за Хобот.
Anandtech или habr я бы больше доверял чем ixbt.
Phoronix еще есть. Есть и другие профессиональные сайты.
Как ixbt верить я не знаю.

P.S.
У меня такое впечатление сложилось об ixbt что:
люди там не то что к IT но и как правило к естественным наукам отношения не имеют. Я помню там какие-то споры что читаешь и понимаешь что оба оппонента даже не знают о чем они спорят.
Я туда больше не хожу.

[hhba]

Информация по теме не найдена

Вы поиском пользовались?

Anandtech или habr я бы больше доверял чем ixbt

Очень зря. Но дело ваше.

[code07734]

Ок, я в то время не знал об этой стороне сайта.
Не, все равно на phoronix или anandtech тесты более профессиональные

[hhba]

Господь с вами, не надо смотреть их тесты. Читайте топики ))

[code07734]

Я поискал arm и graviton. Ничего не нашел или… не знаю.
Как тема называется?

[hhba]

Ну я же дал ссылку, там поиск, ну ввел я за вас:
forum.ixbt.com/post.cgi?id=print%3A8%3A025877&text=graviton&user=&date=&date_days=234&date1_d=5&date1_m=10&date1_y=2019&date2_d=25&date2_m=5&date2_y=2020&posts=&pages=

[code07734]

Не было у меня в ссылке ничего.
Мне жаль, но я не хочу столько читать.
Я бегло прошелся, тоже самое там что и здесь.
Одни говорят что arm крут, другие наоборот.
Как и у нас здесь с вами.
Один человек выразил странные сомнения что A76 слишком мал по площади чтобы быть таким быстрым. Все так привыкли к огромному по площади x86 что уже и не верят. Что тут поделать.
P.S.
Этот диалог превращается в бесполезный холивар.

[daggert]

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

[hhba]

Да, спасибо, я этого сам не заметил. А когда открывал, то по традиции выделил текст и сделал переход.

[code07734]

О, нет. Я знаю. Везде есть нормальные люди. Но хабр был полезнее для меня за все время. Практика по ассемблеру с помощью статьи, недавно. Например.
На ixbt я просто много насмотрелся когда люди спорят что лучше просто потому что. Без фактов. Оба.
Anandtech'ки довольно подробно делают тесты. На хабре тоже тесты часто качественные да еще и с фидбеком. Ну я тесты не особо часто читаю.
А ixbt чисто обзорный.

[code07734]

>На хабре — про программирование
Отсюда следует что здесь некоторые люди и сами неплохие тесты проводят.
По железу лучше электронику почитать)
А так я поссылке почитал — и сразу нашел несколько сферически-логических выводов в вакууме.

Мне вот это не нужно даже
>На хоботе лучше про железо обсуждать или читать.

У меня сейчас tablet с клавиатурой на core m3 -7y30(kaby lake). Я знаю что zen2 и ice lake уже быстрее, следовательно когда я буду менять железо, то это будет zen2-3-4/ice-lake/tiger-lake. И не сильно важно какая там сторона на 5% быстрее.

[code07734]

Причем тут бюджет? У меня выходит не больше 40 000 р раз в 3-4 года.
Может вы не так поняли.
1.Я УЖЕ знаю про эффективные zen 2 u-серии.
2.Я УЖЕ знаю что ice lake оказался не слабой печкой.
Покупал ноут на ice lake, мне вместо 2-ух 4 ядра достались.
Он вентилятор не заглушал вообще. Я сдал. Попутно узнал что и 2-ядерных вариантов все еще нет с пассивным охлаждением
3. К моменту покупки останется найти тесты Zen 3 и tiger lake.
Я уже предпочел zen 2 вместо ice lake, если новые не ждать. И все.
В утечках tiger lake было упоминание что intel займется эффективностью транзисторов, только не в смысле техпроцесса а в их количестве.
Самое важное:
Чтобы все это узнать — не нужно на форумах сидеть где люди это все обсуждают. Тесты SPEC в среднем по больнице — отличный показатель.

[code07734]

>«покупаем асус и баста»
Я так не делаю. Да, пару тестов и все.
Можно самому проверить, иногда.
>Теперь остается узнать, что если ноуты, то каждый производитель реализует систему охлаждения в разных моделях по своему, а именно от неё зависит насколько задушат процессор.
В таблетах выбор на порядок меньше чем в ноутбуках.
Я взял cube mix plus. Не очень удачная вещь)
Но к нему оказалось легко приделать медную пластинку и процессор упал с 90 до 60 градусов. На полные 2.6 работает.

[hhba]

Ну, по крайней мере по процессорной тематике там собрались довольно сильные полемисты. Не видел на Хабре подобных обсуждений (хотя тот же Игорь Ермолаев и тут присутствует).

Просто Хабр нынче более модный ресурс, и заметно более программистский (при этом в части ИТ-администрирования хобот все же сильнее и масштабнее ИМХО), к тому же тут нет «совсем уж посторонних ученым людям» форумов типа «Общей истории» (где на хоботе тоже весьма сильные люди были когда-то, хотя и не ВИФ2НЕ конечно), поэтому собеседнику Хабр кажется более лучше.

[screwer]

И, как говорится, почувствуйте разницу во входных трактах (front end) для ARM и X86.

Верно, 32 битный ARM очень прост. Но как раз ценой слишком низкой плотности кода. Например сколько % инструкций действительно нуждается в условном исполнении? А ведь биты уже не вернуть… Вот в Aarch64 плотность кода повысили, и вся простота тут же испарилась.

Другой недостаток огромной длины инструкций – относительно частые промахи в instruction cache. Грубо говоря, при равном размере кэшей, количество промахов будет тем больше, чем больше длина инструкции

.

В x86 длина типичной инструкции не особо отличается от других mainstream архитектур. В ARM же, для повышения плотности кода, пришлось придумывать костыли в виде Thumb. Где инструкция занимает 2 байта вместо 4. А потом мега-уродцев Thumb-2 и Thumb-3. Потому что Thumb был плотен, но убог. И чтобы не переключаться туда-сюда пошли на компромисс, разрешив миксить 16 и 32 битные инструкции. К чему это привело можно наглядно убедиться, посмотрев как кодируется B/BL в Thumb-2. Более отвратительной инструкции я в жизни не видел!

По этой же причне я очень настороженно отношусь к разного рода VLIW (Very Long Instruction World) архитектурам.

Посмотрите на Hexagon. Вроде бы те же самые 32 битные инструкции. Однако исполняется до 4 штук за такт, при этом некоторые инструкции могут быть составными (два действия внутри одной инструкции). 32 регистра. И DSP фишки — в википедии есть пример внутреннего цикла FFT, который выполняется за такт. Аналог RISC требует до 29 инструкций для аналогичного результата.

[tyomitch]

Где это вы видели Thumb-3?

[screwer]

Arm Programming Refernce Manual, например:

А7.7.75 MOV immediate
...

Encoding T1:
MOVS <Rd>, #<imm8>
MOV<c> <Rd>, #<imm8>
...

Encoding T2:
MOV{S}<c>.W <Rd>,#<const>
...

Encoding T3:
MOVW<c> <Rd>,#<imm16>

[Gumanoid]

Это 3 разные версии инструкции, закодированные в Thumb.

[tyomitch]

Подтверждаю, что это просто нумерация Thumb-кодировок.
У B есть ещё и T4.

[Dr_Sigmund]

В своё время был впечатлён, обнаружив, что один и тот же mov можно закодировать аж тремя разными способами.

[netch80]

В RISC вариантов больше, если есть пустой регистр :)

or rd, rs, rnull
xor rd, rs, rnull
add rd, rs, rnull
sub rd, rs, rnull
lsl rd, rs, $0
lsr rd, rs, $0
sbfm rd, rs, 0, 63 (эта и следующая — ARM)
ubfm rs, rs, 0, 63
… и ещё десяток…

если бы кто-то писал полиморфный вирус — у него появилась бы новая степень свободы по сравнению с x86.

[farafonoff]

Надо беречь Intel/AMD как зеницу ока. Пока их божественные процессоры существуют, у нас, программистов, есть свобода создавать и использовать любые ОС. Хочешь freebsd, хочешь windows, хочешь linux, хочешь bolgenos напиши.
Все эти ARM платы идут с впаянными процессорами, и предустановленной ОС. Даже на всякие популярные raspberry нельзя поставить альтернативную ОС, или даже собрать mainline linux kernel, что уж говорить о всех других платах.
Это не говоря уже о поддержке периферии. К x86 плате через разные адаптеры можно подключить вообще любую существующую периферию, а arm-платы имеют довольно короткий список совместимого оборудования.
Особенно я бы здесь не доверял huawei, их телефоны идут с залоченым загрузчиком, для которого нет официального анлока. Думаю, что с серверами будет такая же шляпа.

Я понимаю, что это не про ISA, но ISA ведь ничего не стоит без поддержки железа.

[vvvphoenix]

Вот FreeBSD не надо. Это же ад кромешный :)
Но с тем что впаянные прцессоры -это не айс согласен.

[netch80]

> Вот FreeBSD не надо. Это же ад кромешный :)

Нормальная система. Для ~90% применений — линукс линуксом, ну стиль местами другой :)
Виртуализация заметно слабее — это хуже, да.

[vvvphoenix]

Когда я рулил VTune в Intel y нас было всего два кастомера с БСД. Но когда приходил кто то из них у меня начинал дергаться глаз :)

[netch80]

> у меня начинал дергаться глаз :)

Судя по valgrind, у VTune должно было быть заметно специфической заточки под особенности ОС. Тогда понятно — ради двух кастомеров вспоминать всю специфику — задолбёшься. Или я неверно понял причину?

[vvvphoenix]

Ну как сказать. У BTюна есть драйвера. И фиксить в них баги куда сложнее чем в пользовательском коде. На линуксе — это ужас. На BSD — ужас-ужас…

[code07734]

А как конкретно впаянность влияет? — вы так написали будто…
На raspberry pi3 человек собрал gentoo arm64, я поставил, работает. Каких-то «особых» проблем нет.
Современные x86 по бОльшей части впаянные. Т.к. если я ничего не путаю, стационарники отходят.

[farafonoff]

Для серверов я думаю также важна гибкость и возможность ставить более и менее мощные CPU сохраняя остальную периферию стандартной.
Впаянность сокращает свободу сборки готовой системы. Сейчас можно в одну и ту же плату поставить разные процессоры (и наоборот). Кому-то нужно больше памяти, кому-то больше слотов pci-e x16, а кому-то экзотические интерфейсы.
На той же злополучной raspberry pi внутри есть PCIe, но к ней нельзя подключить внешнюю видеокарту, sata контроллер или что-нибудь еще.

[code07734]

Ну на x86 сокеты держатся не более 3 поколений, уже давно как. Хотя не знаю — как там на серверах? Переферия -да. Но смена процессора в пределах 2-3 поколений больше походит на видимость свободы.

[farafonoff]

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

[code07734]

Все равно впаянность такой роли уже не играет. У x86 уже такая экосистема что все материнские платы довольно функциональны. Если он станет распаянным, не составит труда найти нужную плату.
В то же время если одноплатники станут со сьемными процессорами — платы у них так и остануться без sata. На серверных платах у ARM как правило не так плохо с переферией.
По поводу gpu: Думаю одноплатники не предназначены пропускать 200 Вт. И с драйверами проблемы были бы.
А так — переходники ваше все)

[farafonoff]

посмотри на десктопный интел, прямо сейчас в днс 114 материнских плат, и 54 процессора. Из них я могу сложить 6156 компьютеров, и почти все будут работать. Кто еще так может?

[ValdikSS]

Современные ARM постепенно двигаются к унификации: ACPI, UEFI, вот это всё; производители SoC добавляют свои драйверы сразу в mainline. На многих современных одноплатниках запустится Ubuntu 20.04 прямо из штатного iso, без ядра и модулей от производителя.

[farafonoff]

Одноплатников развелось слишком много разной кривизны. Если хочется, например, sata, то доступно всего полторы модели, со своей уникальной кривизной.
Raspberry Pi кажется так и не могут поддерживать Gigabit Ethernet.
ACPI и UEFI конечно хорошо, но хочется еще пару sata и пару ethernet.

[code07734]

2 x ethernet то нахрена? Даже у x86 плат один обычно. Или я проспал что-то?
Что можно с двумя чего с одним нельзя? — Правда интересно.

>Посмотри на десктопный интел, прямо сейчас в днс 114 материнских плат, и 54 процессора. Из них я могу сложить 6156 компьютеров, и почти все будут работать. Кто еще так может?
Ну если считать процессоры с одинаковым числом ядер в пределах 500Mhz как за один(потому что разницы не чувствуется), то 6156 превратится в примерно 1000.
Да, у ARM все еще меньше будет выбор, но я с вами уже и согласился насчет периферии.

[DistortNeo]

Если один сгорит — можно воткнуть в другой.

[PKav]

«каждый новый бит в ISA снабжается ярлыком “хранить вечно”.
А как же инструкции „AMD 3DNow!“, которые AMD сама родила, и сама же не сильно давно убила, перестав поддерживать в процессорах Bulldozer?

А вообще, я думаю, это всё можно причесать, если убрать лишнее из железа и компиляторов, а устаревшие инструкции эмулировать при помощи тех, что остались на программном уровне.

[tyomitch]

а устаревшие инструкции эмулировать при помощи тех, что остались на программном уровне

Как вы себе это представляете?
Процессор, продающийся с примечанием «ваши старые программы на нём заработают только под новой ОС, где реализована эмуляция старых инструкций»?
Это будет очередной Itanium.

[netch80]

Apple себе такое позволил аж дважды (M68k->PPC, PPC->x86).
Но внутри одной x86, конечно, так делать не будут — только при радикальной смене ISA.

[code07734]

>Как вы себе это представляете?
Постепенно.
Например windows 10 эмулирует x86 на x86-64. Если старые режимы убрать — она продолжит работать.
Linux давно весь перекомпилирован на все новое.

[DistortNeo]

Причём тут Windows, когда это поддержка старых инструкций со стороны процессора?

[code07734]

Я привел пример массовой OS, которой все это <когда это поддержка старых инструкций со стороны процессора?> не нужно!
Real mode работает только в момент запуска.
В amd64 есть все нужные алиасы для работы с половинами и частями регистров, и даже чуть более того.
Если и начинать переделывать x86, то мне кажется(мое мнение) что для начала можно отрезать старые режимы. Там есть часть ISA не попавшая в amd64, но и сейчас занимающая свое место в декодере/микрокоде.
P.S.
Может я чего-то не знаю, и какие-то драйвера до сих пор прыгают в старые режимы. Поправьте кто в курсе, если что не так.

[tyomitch]

Real mode и 32-битный режим на x64 — это совсем разные вещи.

К слову, от поддержки 16-битных приложений в Win64 отказались, даже эмуляцию приделывать не стали.

[code07734]

>Real mode и 32-битный режим на x64 — это совсем разные вещи.
Я знаю и имел ввиду, что пора бы оставить ТОЛЬКО x86-64.

[DistortNeo]

Не надо. 32-битные программы ещё существуют и используются.

[rogoz]

x86-64 полностью поддерживает выполнение x86-32 программ для защищённого режима. Более того, ща лень в документацию лезть, но насколько помню полностью поддерживается выполнение x86-16 программ для защищённого режима (80286 процессор). То есть теоретически 64-битная винда может выполнять программы Windows 3.x без эмуляции, если захочет. Выпилили только режим эмуляции 8086 в 64-битном режиме. Реальный режим, чистый 32-битный защищённый и переход из него в режим эмуляции 8086 остался.

[tyomitch]

То есть теоретически 64-битная винда может выполнять программы Windows 3.x без эмуляции, если захочет.

На самом деле нет: программы для Win16 эмулировались тем же самым ntvdm, потому что Win16 разрешала использовать int 21h даже в защищённом режиме.

[code07734]

>x86-64 полностью поддерживает выполнение x86-32 программ
Я с этим и не спорю. Я изначально говорил что могли бы эти режимы убрать уже.
Там тема была про потенциальную очистку x86.
И насчет полной совместимости, если вы про опкоды то:
Не все инструкции обрели алиасы в x86-64.
Например вот эти: AAA, AAD, AAM, AAS.
Просто опкоды занимают, их и 20 лет назад не использовали практически.

>То есть теоретически 64-битная винда может выполнять программы Windows 3.x без эмуляции
Не уверен что windows 10 может это запустить даже теоретически. Но на практике, если не ошибаюсь, она принудительно не дает процессору ходить в прошлое.
Windows 10 (WoW — Windows On Windows subsystem) программно выполняет x86-32.

[netch80]

Тут таки проблемки. В длинном режиме есть только 64- и 32-битные защищённые, причём со страничной адресацией только PAE (полный 64-битный адрес, 512 элементов на одном уровне). В старом режиме (legacy) есть 16-real, 16-virtual (внутри 32-protected), 16-protected (а-ля 80286) и 32-protected (а-ля 80386) со старой страничной адресацией или с PAE.
Выполнять программы от 3.x можно, да, но это значит регулярное переключение между legacy и long mode, которое может быть только явными действиями, прерывание такого не позволяет => надо держать фактически два варианта кода ядра, отвечающего за управление памятью, прерываниями, режимами и т.п., на общих структурах кода… в принципе возможно, но есть заметный гимор. Например, у вас какие-то данные за пределами 32-битной части, а вы сейчас в legacy/32-protected — что, специально для этого перенастраивать страницу? Ну и переключение недешёвое, на каждый чих его делать, если 1-2 таких 16-битных среди остального 64-битного хозяйства… телушка — полушка, да рубль перевоз.
Вот и получается, что легче вообще сказать «идите нафиг со всей 16-битностью», чем морочиться с этим.

А ещё есть задача стартовать работу процессора… даже последние стартуют в старом добром 16-real. Делать расширенную адресацию без защищённого режима Intel отказывается — слишком много тупой легаси из-за промежуточного подхода стиля 286, и нельзя включить ни страничную адресацию, ни 64-битность без общего protected. BIOSʼы на старте используют хак — переключились в protected, установили границу 4GB сегмента и вернулись в реальный (иногда называется «unreal mode», Intel отказывается его документировать ещё со времён 80386, хотя он в каждом первом BIOS). Смотришь на это и плачешь — по сравнению с каким-нибудь z/Arch: тут тебе и возможность одним рывком отключить виртуальную адресацию в супервизоре без сложных плясок с режимами, и адресация одной командой щёлкается, и виртуализация даже в 4 слоя только чуть-чуть тормозит…

[DistortNeo]

В длинном режиме есть только 64- и 32-битные защищённые,

В длинном режиме есть и 64-, и 32-, и 16-битный режимы. Не нужно переключение между long и legacy. В длинном режиме нет только Virtual 8086.

А причина, по которой Microsoft выпилила поддержку 16-битного режима, написана здесь:
https://docs.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications

The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data.

Ещё говорят, что 16-битные Windows-приложения запускаются под Wine в 64-битных системах. Я, правда, сам это не пробовал делать.

[netch80]

> В длинном режиме есть и 64-, и 32-, и 16-битный режимы. Не нужно переключение между long и legacy.

ok, согласен. Давно не вспоминал, а их документацию читать нетривиально — всё время нужно продираться через слои поправок к собственному тексту :(
Но уже вырезание V8086 означает потерю старого DOS-хозяйства.

> The primary reason is that handles have 32 significant bits on 64-bit Windows.

А что именно из хэндлов и каких не влезло в 16 бит — умолчали. Файлы, например, сюда не будут относиться.

[DistortNeo]

Но уже вырезание V8086 означает потерю старого DOS-хозяйства.

При этом ничто не мешает запускать DOS-программы с помощью эмулятора или внутри виртуальной машины, если не хватает скорости эмулятора (впрочем, это крайне маловероятный сценарий).

А что именно из хэндлов и каких не влезло в 16 бит — умолчали. Файлы, например, сюда не будут относиться.

https://techcommunity.microsoft.com/t5/windows-blog-archive/pushing-the-limits-of-windows-handles/ba-p/723848

[tyomitch]

Разве в Win32 хэндлы были 16-битными?
Но там проблем с их передачей 16-битным приложениям не было.

[DistortNeo]

Были 32-битными, но их значения, видимо, помещались в младшие 16 бит.

[DistortNeo]

Если и начинать переделывать x86, то мне кажется(мое мнение) что для начала можно отрезать старые режимы. Там есть часть ISA не попавшая в amd64, но и сейчас занимающая свое место в декодере/микрокоде.

А вы можете дать оценку, насколько упростится процессорная логика, если эти режимы выпилить? Может быть, в выпиливании вообще нет никакого смысла?

[code07734]

Нет, но сначала это скорее всего окажет приерно никакой эффект.

>Может быть, в выпиливании вообще нет никакого смысла?
А вот по такой логике их так и будет становиться все больше, а смысла выпиливать все так типа и не будет.
Я не могу дать точную оценку, но очень подозрительно что ядро больше чем L3
Мне кажется legacy имеет влияние сильно дальше чем область декодера.
Например, длина avx инструкций — не хорошо для кэша. А длина у них могла быть по меньше, будь больше свободных опкодов

[DistortNeo]

Ну вот посмотрите тут фоточки Zen:
https://en.wikichip.org/wiki/amd/microarchitectures/zen (Die > Core)

Декодер там занимает достаточно небольшую часть. Не получится на нём сэкономить.

[code07734]

Я был там. Тогда я не понимаю как L3 занимает даже меньше чем x86.
Даже 64-битные умножители так много не занимают.
Про x86 часто говорят:
1.Кэши потребляют бОльшую часть энергии
2.Декодер требует мало энергии/площади.
И эти два противоречат.
Как я уже написал, сложность ISA вероятно имеет более глубокие последствия.

[tyomitch]

Linux давно весь перекомпилирован на все новое.

Внезапно, под Linux предостаточно closed-source приложений. А даже когда и open-source, то не всегда можно просто взять и перекомпилировать, особенно если вендор забил на поддержку («исходники у вас в руках, **итесь как хотите»).

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

[code07734]

Интересно). Статью бы по исправлению бинарника в вашем конкретном случае. А что за программма если не секрет?
>Внезапно, под Linux предостаточно closed-source приложений.
Ну я немного утрирую, но бОльшая часть софта идет на amd64.

[tyomitch]

Статью бы по исправлению бинарника в вашем конкретном случае.

Я и сам хотел её написать, и даже просил у начальства разрешения, но мне было велено не разглашать нашу внутреннюю кухню :-/

[Dr_Sigmund]

Например windows 10 эмулирует x86 на x86-64.

В каком смысле «эмулирует»? Инструкции 32-битных процессов по-прежнему выполняются процессором, а не путём программной эмуляции. И даже в виртуальных машинах.
Эмуляция — это Bochs32, например.

[code07734]

Да что же это такое!
Ссылки в порядке увеличения важности
en.wikipedia.org/wiki/WoW64
en.wikipedia.org/wiki/Windows_on_Windows
docs.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications
docs.microsoft.com/en-us/windows/win32/winprog64/wow64-implementation-details

[code07734]

О, нет. Я ошибся. Сами инструкции выполняются самим процессором.
Это только в случае с ARM эмуляция.

[Dr_Sigmund]

Отожъ.

[netch80]

Ну вот через CPUID и делаются пометки типа «мы это ещё поддерживаем» или «ой, тут нету». Периодически слышатся угрозы типа «убьём FPU, надоел, SSE лучше и есть у всех». В каком-нибудь Atom вполне могли бы…

Автор же скорее имел в виду содержимое основного (гарантированного) набора: никому не нужные RCL/RCR, неисправимую кривизну интерфейса BSF, BSR, атомарность XCHG, занятые однобайтные коды под IN, OUT, CMC, STD, INS, OUTS, SCAS (для них всех и трёхбайтный ничего бы не испортил в плане производительности) и прочая и прочая…

[vvvphoenix]

Вся проблема в пользователях, которые могут запустить старинную прогу (бинарник) на новой железке. Вопрос в том насколько громко они будут кричать увидев что то типа Exceprion: Illegal instruction at…

[farafonoff]

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

[vvvphoenix]

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

[X3_Shim]

Валерий, привет (узнал ли? :) ).
Помнится когда осваивали SSE2, была возможность на винде выполнения кода на не поддерживающем его проце. Если я правильно понимаю, перехватывался IllegalInstruction, софтверно выполнялась обработка, код медленно, но работал. Без виртуализации. Вот могу конечно врать, давно уже было однако.

[vvvphoenix]

Привет, Шим. Как сам? Где нынче?

[X3_Shim]

Да вроде не жалуюсь :). Как обычно, Саров. Нынче наше «градообразующее предприятие».

[vvvphoenix]

Надеюсь доеду до вас, когда карантин кончится :)

[X3_Shim]

Вот тут стало очень интересно с какой целью :)

[vvvphoenix]

Давно не был. Соскучился :)

[Sap_ru]

Интересно, когда мы увидим Intel-x64-only процессоры. Система команд там значительно проще с более логичным кодированием. Плюс, возможна более эффективная настройка механизмов кэширования и упреждающего чтения.
За счёт освобождения площади кристалла и упрощения логики до 20% прироста скорости на некоторых задачах может быть. А такой прирост на кристалл сейчас очень долго стоит.
И ниша уже есть — всякого рода сервера и вычислительные системы, где x86 остался только в загрузчике.

[Sap_ru]

Рынок серверов сейчас уже не только и не столько винда.

[DistortNeo]

И каким же образом это скажется на скорости? Просто интересно.

[Sap_ru]

1. Освободиться место на кристалле, которое можно будет использоваться для других целей.
2. Очень сильно упростится время декодирования команд. Оно, конечно, все кэшируется, него там много ограничений и это не на всяком коде работает.
3. Механизмы предсказания и кэширования упростятся. Сейчас приходится идти на компромисс между эффективностью на 32 и 64 битах. Это видно на младших процессорах, где жертвуют производительностью либо того, либо другого.

[DistortNeo]

1. Я не знаю, сколько места занимают декодеры 16- и 32-битных команд, но не думаю, что насколько значительно.

   
   

2. Почему же? Процессор единомоментно работает только в одном режиме. И в любом случае, он разбирает команды на элементарные составляющие.

   
   

3. Но почему? Можете привести конкретные примеры?

   
   

[netch80]

Система команд в x86-64 ничуть не логичнее — такое же извращение, и ещё хуже за счёт REX префиксов. Принципиальное улучшение только в возможности адресоваться по RIP.

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

Но, очевидно, это пока не стоит выделки. Могли бы начиная с какого-то поколения убрать старт через 16-битный реальный режим. Но для этого тогда надо вначале сделать 32- или 64-битный реальный режим! А это они как-то не очень умеют. Да и SMM надо переводить на новые рельсы…

[vvvphoenix]

А майкрософт как же? Будет молча плакать в уголке?