Комментарии 385
У Intel было много ISA, как минимум с десяток. Ни одна, кроме x86 не выстрелила, увы.
и одна VLIW-архитектура по-настоящему не взлетела.
Qualcomm Hexagon. Используется, наверное, в половине мобильных устройств по всему миру. А это многие миллиарды девайсов.
Интересно, а в какой момент это стало понятно? Или просто x86 доросла до того, чтобы на ней можно стало делать критически важные (или как там точно) вычисления? Помню, в каком-то поколении Xeon научился откатыааться с синего экрана.
«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.
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 Правда, у этих концепций тогда был бы шанс не дожить до нашего времени — может, он это имел в виду?
Были архитектуры, где правильно выбранный порядок байт упрощал или ускорял работу процессора. Были — где наоборот, замедлял. И были же — те, где на него пофиг было процессору. примеры:
- pdp-11: процессор 16-битный и слова всегда выровнены по 2 байта. на порядок байт в слове пофиг, сделали LE.
- i8080: процессор 8-битный, но читает 16-битные слова всегда как 2 подряд идущих байта. тоже на порядок байтов пофиг, сделали LE
- mc6800 (не путать с mc68000!). 8-битный, порядок байт BE. за что расплата лишним тактом в адресации типа
LDA ADDR,X
, где процессор побайтно читает 16-битное число, прибавляет к нему 8-битный индексный регистр и с полученным адресом выходит на шину прочитать аргумент. порядок байт выбран неправильно (почему — см. ниже) - 6502! идеологически похож на 6800, порядок байт LE. благодаря этому, в описанном в п.3 случае читает сначала младший байт, потом во время чтения старшего — одновременно прибавляет к уже прочитанному индексный регистр. и если нет переноса в старшую часть, то на шину выходит сразу же, не тратя дополнительный такт. порядок байт выбран верно!
ну и соглашусь, что уже в i8086, mc68000 и далее — порядок байт перестал играть какую-либо роль. например архитектура ARMv7A позволяет переключать порядок байт прям в пользовательской программе, инструкциями SETEND BE/LE
.
У PDP-11 не little endian, а PDP endian
"pdp endian" относится только к опциональному FPU. сам PDP-11 без FPU чисто 16-битная машина и соотв-но может быть назван little endian
Ну да — они могут продать дизайн готового ядра а могут — лицензию на архитектуру (задорого и ядро дизайнить самим, Apple и Qualcomm пользуется этой опцией, Samsung вроде пользовался но решил что не надо больше).
Вы имели ввиду risc внутри? Там не arm.
>Qualcomm же выпустила ARM+x86 процессор, где можно на лету аппартаную архитектуру переключать.
Нет, там программная эмуляция и не от qualcomm а от microsoft
Программная эмуляция это 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. Только линковка другая.
Версии ME от 1.x до 5.x использовали ARCTangent-A4 (только 32-битные инструкции), тогда как в версиях от 6.x до 8.x использовался более новый ARCompact (смешанная 32- и 16-битная архитектура набора команд)
Начиная с ME 11, в основе лежит 32-битный x86-совместимый процессор на технологии Intel Quark
Это если вы про en.wikipedia.org/wiki/Project_Denver
— оно живёт в чипсетах, а не процессорах
— с 2015 года оно крутится на x86
— до 2015 года оно работало на ARC, а не на ARM
Консорциум вендоров. То есть куча компаний, которые применяют ARM в своих чипах.
Я верю в философскую теорему о том, что «только открытые системы могут быть устойчивы». ARM — открытая система. Интел -нет
На мой взгляд, little endian гораздо логичнее. Big endian это всего лишь попытка натянуть на АЛУ привычную нам запись чисел слева направо.
Арабы используют другие цифры.
Как и индийцы ;-)
У индийцев, кстати, у каждого языка чуть свои цифры — см. список юникода, например:
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;;;;;
Но важнее то, что у индийцев, которые писали слева направо, позаимствовали арабы, не меняя порядок — младший справа — и затем европейцы, восстановив исходный порядок.
Сам же этот порядок происходит от языка, в котором — за исключением локальных инверсий типа ein zwanzig — во всех мировых языках начинают с самых больших значений (типа «пять миллионов восемьсот тридцать две тысячи...»)
Все действия «в столбик» выполняются от младших разрядов к старшим, так что запись справа налево для арабских чисел намного естественнее.
И ещё, что в древнеанглийском числительные были как в немецком: seofon and twēntiġ; лишь под влиянием понаехавших норманнов англичане перешли на чистый big-endian.
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.»
Но кто сказал, что это хорошо? Язык неолита не очень подходит для современных условий.
Капитан, эта прелесть называется позиционная система счисления.
Например, одно из обоснований выбора big-endian для протоколов ARPAnet было, что пока младшие байты ползут по каналу, раутер уже может по старшим начинать делать поиск в таблицах.
Или: если число записывается в переменное число байт — то big-endian дороже для пишущего (надо вначале размотать, найдя, где старшая часть), но дешевле для читающего (просто по порциям читаем и сдвигаем), little-endian — наоборот. Поэтому выбор форматов [u]leb128 для DWARF — ошибка: надо удешевлять читающий отладчик, а не пишущий линкер: линкер работает один раз, а отладчик читает управляющие структуры по многу раз.
Но сейчас обычная операция это прочитать/записать строку кэша (32-64-128 байт), дальше с ней целиком работать (между АЛУ, регистрами и кэшами параллельные интерфейсы, иначе тупо скорости не хватит), записать обратно. И там порядок байт конкретной операции с машинным словом уже ничего не значит.
Длинная арифметика стиля GMP меняла бы стиль, да — грубо говоря, вместо i от 0 до n-1 идём от n-1 до 0. Но там обычно делают LE массив лимбов, даже если лимбы хранятся в BE.
ЗЫ Мы тут говорим про длинную арифметику, а если операнды влазят в размер регистра, то там разницы нет, так как чтение все равно за раз будет происходить.
Спасибо за уточнение, а то я успел офигеть от первой части. Но давайте тут подробнее. Что вы называете длинной арифметикой и что за «дополнительные телодвижения»?
Вот я складываю числа (без знака, в стиле 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], всё захардкожено…
Ну в упор не вижу разницы. Покажите код, что ли.
for(int i=n-1,…
Переложите их на ассемблерных инструкции. Разница вполне очевидна.А теперь помножьте эти дополнительные операции на на то, как часто это нужно делать (как часто эта функция вызывается)…
Да, очевидна: проверка на 0 (случай BE) на какие-то милликопейки дешевле из-за того, что не надо n хранить в регистре. В отличие от вас, я проверил результат реальным ассемблером. Хотите возражать — начните делать это предметно: покажите команды на выходе обоих вариантов и докажите на листинге, что в LE варианте получается дешевле. А то я тут на каждую вашу реплику «разъедающего сомнения» привожу реальный код, а в ответ получаю ещё одно «не верю» без аргументов. Жду.
Достаточно указывать указателем на конец BE числа, чтоб отпала необходимость складывать с размером.
А если ещё вспомнить, что знаменитая IEN 137, в которой были впервые введены термины little-endian и big-endian, выпущена в 1980, а x86 появилась в реально массовом употреблении на несколько лет позже… увы, Intel виноваты только в одном — что их архитектура оказалась ещё одной сверхуспешной.
Нумерация битов в слове не имеет никакого отношения к порядку байт того же слова в памяти. И что в ibm360 и всех последующих, а также в powerpc нумерация битов со старшего разряда — это конечно дремучий трындец.
То есть вы 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.
Можно пойти против него, но начнутся разрывы в неожиданных местах.
У меня, кстати, лежит плата под iAPX 432. Может дойдут руки пощупать этот процессор в живую.
Какое-то странное у них соревнование — Intel уносится в выси из слоновой кости, AMD ищет явные провалы и затыкает их…
Грубо говоря, при равном размере кэшей, количество промахов будет тем больше, чем больше длина инструкции.Только вот чем проще ISA — тем больше инструкций содержит код. Длинные инструкции CISC в RISC превратятся не в короткие инструкции, а в огромное количество коротких инструкций. И мне почему-то кажется, что код на хорошо спроектированной CISC ISA окажется короче, чем на RISC.
Это отчасти справедливое замечание. Но тут я бы хотел послушать компайлерных людей, ибо самому тяжело сравнивать. Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.
Как минимум Таненбаум писал, что современные компиляторы используют CISC-процессоры фактически как RISC, генерируют только простейшие инструкции. Мои личные наблюдения это подтверждают: и gcc, и llvm для x86 и для ARM генерируют очень похожий код. Из сложного используется только SIMD.
Но Таненбаум прав в том, что как минимум GCC и LLVM они строго SSA-based. Это резко упрощает оптимизацию верхнего уровня, но приводит к тому, что модифицирующие операции, которые являются основной вкусностью CISC для кодера-человека, теряют смысл (совпадение ячейки аргумента и результата надо ещё явно обеспечить), хитрые комбинированные адресации типа @-(Rn) надо явно собирать обратно из возможно разбежавшихся по коду операций… в итоге получается, что переводить результат после оптимизаций SSA в RISC в десятки раз легче, чем в CISC. Если не будет найдено новых моделей работы компилятора, или хотя бы эффективной свёртки после SSA в CISC-операции — то причин строить новые CISC не будет, от слова «совсем».
(Проблемы кэширования и out-of-band исполнения тут, конечно, играют тоже существенную роль. Но сейчас я не о них.)
Чисто теоретически CISC может иметь преимущество, когда ставит в соответствие более частым инструкциям или последовательностям более короткие коды (Huffman, arithmetic). Но проблема будет в том, что это будут команды переменной длины и декодировать их можно будет только последовательно.
Можно собрать лучшее от обоих миров: так, в Thumb-2 команды переменной длины (16 либо 32 бит), но это всё равно RISC ISA, специально оптимизированная под плотность кода. И поскольку длина команды однозначно определяется по старшим битам, то их несложно декодировать параллельно.
PS Да и сам человек (программист) в процессе написания ПО вынужден думать как процессор, а это существенно ограничивает его возможности.
Аналогия программирования: Написание инструкций быстрому, точному, исполнительному но все же «дураку».
На моей памяти таких моментов было несколько. SIMD, многоядерность. И да — каждый из них требовал серьезного перелопачивания всей экосистемы. Ну по крайней мере перекомпиляции. Но каждая такая революция была «бархатной». Происходила постепенно и требовала много времени…
По поводу многоядерности, тут совсем печально, современная вычислительная парадигма (Фон Нейман) не содержит в себе не то что понятия многоядерности, так в ней вообще нет такой сущности как другая точка исполнения команд и изменения данных (поток команд и тд). Соответственно нет никаких механизмов кооперации, синхронизации и распределения решаемой задачи. Наличие одной точки исполнения вообще убило прогресс производительности (в идеале производительность должна линейно зависеть от числа транзисторов).
То что необходимо получить (принципы создания ПО), должно иметь свойство жидкости, заливаемая в любой сосуд принимает его форму. А сейчас мало того что не изменяет форму, так еще и при переносе тащит за собой и часть особенностей предыдущей вычислительной системы.
код на хорошо спроектированной CISC ISA окажется короче, чем на RISC
Проблема в том, что семейство x86 имеет плохо спроектированный ISA.
Только вот чем проще ISA — тем больше инструкций содержит код.
На ARMv7 и ARMv8 количество инструкций сравнимо с x86-64 при более простом ISA. По крайней мере это верно для первого попавшегося примера: https://godbolt.org/z/_m4EBC
Проблема в том, что семейство x86 имеет плохо спроектированный ISA.Почему?
На ARMv7 и ARMv8ARM вообще-то уже давно свернула с RISC-дорожки.
Если не искусственные примеры, то я как-то развлёкся с компиляцией реальной программы (прокси особого сетевого протокола):
-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-байтными, и то нарастание не очень заметное.
Tcpdump тут более сомнительный — глубоко системная программа со специфическими оптимизациями.
Можно сейчас на чём-то повторить, но надо, чтобы оно просто компилировалось (без кучи библиотек), иначе у меня не хватит терпения.
2. Вы про 32-битный. Даже если это было так, они это преимущество сейчас теряют (кроме embedded).
Power9?
>а какая сейчас по сути не может похвастаться ничем, кроме количества ядер и техпроцесса.
ShenWei? хотя может вы и MIPS имели в виду, а может и мультиклет какой.
а в огромное количество коротких инструкций.
«Огромное» количество это сколько?
Что бы не измерять сферических коней в вакууме, давайте на реальных примерах.
Так вот в реальности ARM часто нужно меньше «коротких» RISC инструкций чем х86 «длинных» CISC инструкций.
Вы, кстати, правильно сделали, что взяли «коротких» в кавычки — в ARM длина инструкции не может быть меньше 4 байт, тогда как в x86 — может.
Дело в том, что разработчики архитектуры прагматично подходили к вопросу организации 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.
тут интересный вопрос, что именно делает ARM — RISC'ом. если его называть load/store архитектурой — то всё верно. а c очень уж расплывчатым понятием "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.
в 32-битном режиме с THUMB-2 — длина инструкций 2 или 4 байта.
Самый короткий код сейчас из основных ISA на RISC-V с поддержкой compressed набора. Основной набор у них, как у большинства RISC, из 4-байтовых команд, но они тщательно разобрали реальные шаблоны и зафиксировали их в «сжатом» наборе.
Несжатый у них, у AArch64 — немного длиннее x86.
> Только вот чем проще ISA — тем больше инструкций содержит код.
Так RISC/CISC это не о простоте набора, а о простоте базовой логики одной инструкции. При этом конкретная выполняемая операция может быть нетривиальной, как, например, BFM из ARM.
> Напомните, пожалуйста, какая архитектура способна выдавать высокую производительность в однопотоке
На сейчас это на 100% следствие того, что Intel успел раньше и стал толще. ARM догоняет, но за счёт сокращения подобных утяжелений у него шансы выше.
B Opcode Mode R Src Mode R Dst
нашел в википедии. Ну да — логика за этим есть. Но как расширять набор команд?
ЗЫ Хотя оригинальный pdp-11 и расширяли — добавили команды умножения/деления, вещественные числа…
Другой вопрос, что архитектура тупо перестала быть интересной с новыми ресурсами.
О, кстати. Надо будет как нибудь в следующий раз написать про частоту, длину пайплайна и энергопотребление. Это моя любимая тема. Я ещё помню p4, который работал на 10ГГц и охлаждался жидким азотом :)
Насколько я помню спецификации SVE датируется 2017-2018 годом. Ну то есть можно сказать что именно в этот момент arm стал серьёзно заглядывать на ентерпрайс рынок
Вообще лет 10 уже.
Ветку ARM8 х64, при анонсе разработки в 2011 году позиционировали не больше не меньше, как убийцу блэйд-серверов на х86 архитектуре.
В 2015 или 2016 году, вроде, эти самые серверы таки были выпущены, но что то пошло не так :)
Для серверов же общего назначения широкий SIMD и не нужен.
kingleonfromafrica
ARM серверы в 2015 и в 2020 это две большие разницы.
Тогда не была готова софтверная инфраструктура. Особенно это касалось загрузки, сборки ОС, работы популярных приложений. Лишь недавно стало возможным пользоваться ARM серверами точно так же как и x86, что видно на примере Graviton2. Сейчас можно скачать образ ОС и запустить его на своей ARM системе, без того, чтобы проверять, есть ли поддержка именно вашей платы.
Это всё понятно, но где же тесты сопоставимых по цене/количеству процессоров/цвету корпуса/etc. конфигураций и обзоры их результатов?
Их нет.
Меня это очень удивляет, если что.
Я бы и сам хотел получить сервер с сопоставимой х86 производительностью, но не требующий двух блоков питания с мощностью как у сварочного аппарата ...
Ну, и да, вопрос тротлинга на х86 тоже весьма не приятная вещь — покупая сервер планируешь, что он будет "топить на все деньги", а в реале это всё как то не совсем так получается.
Это конечно вопрос к инженерам, протупившим при реализации системы охлаждения, но это вполне себе повседневная проблема.
Но, реальных решений на ARM как не было, так и нет.
Это всё понятно, но где же тесты сопоставимых по цене/количеству процессоров/цвету корпуса/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 тоже можно купить.
Пример с обзором и тестированием ARM-сервера Huawei очень показателен тем, что ни каких ровно преимуществ у него нет.
При сопоставимой производительности вполне себе сопоставимая потребляемая мощность.
Это близко не обещанные х10 экономии — там о какой либо заметной разнице вообще речь не идет.
Тестирование, замете, выполнено "на поле" ARM. Тестировалось и сравнивалось только то, что на нем вообще запустилось.
Я не хочу тут как то особо ехидничать и понимаю, что проблема "курицы и яйца" имеет место быть, но первое, что мне пришло в голову, это слова представителей Intel про P4 — "это не процессор плохой, это вы программы не правильные под него пишете" на какой то конференции в Москве примерно в 2003 году :)
Решил с вами поделиться новостью.
Май настал)
www.anandtech.com/show/15813/arm-cortex-a78-cortex-x1-cpu-ip-diverging/4
Нет, тоже не сколько хочешь. Если бы это так было — не было бы троттлинга. А они троттлятся тока в путь. Power envelopes никто не отменял для серверов. Но там они связаны скорее с отводом тепла.
Хотя, ЕМНИП, Amazon как раз на ARM дизайнит свои новые процессоры.
Так и для серверов прожоривость тоже не приветствуется. Собственно, поэтому х86 процессоры в топовых серверах тоже редко работают на частотах выше 3 ГГц.
инструкции x86 выполняются за 2-3 такта
Не совсем так.
Мнемоника — это команды которые считывает процессор из памяти, то что мы можем контролировать глазами через экран монитора.
В арм одна машинная мнемоника имеет от одной до семи отдельных инструкций. Каждая инструкция выполняется синхронно с другими, имеет задержку выполнения от двух до четырнадцати тактов. Задержка потока и физическое исполнение — разные вещи. Читать можно быстрее чем будет фиксироваться физическое исполнение — получается 1 такт. Всё ломается с кодами ветвления.
В х86 одна мнемоника может иметь в своём составе сотни инструкций. Всё точно так-же использует конвейер. Та-же задержка, но теперь на каждую инструкцию отдельно. Идеальный код без ветвлений даёт выполнение одной мнемоники за такт. Но первое-же условие перехода — отбрасывает х86 в пещерный век.
Вся разница в энергопотреблении, и в условиях подсчёта.
Для интела удобно считать скорость через инструкции, потому как всегда получается больше чем у арм.
А для арм удобнее считать через мипс, где интел в глубокой жопе.
Для Интел МИПСы не имеют большого значения, т.к. те же AVX512, за счёт своей 512-битности, положат на лопатки любой АРМ с его МИПСами. Интел пошёл другой дорогой — добавляя пакеты инструкций для решения задачи минимальным количеством инструкций, классический процессор эту задачу будет решать десятками-сотнями низкоуровневых инструкций. Выигрывая в МИПСах, но проигрывая в скорости решения задачи. Умножая 256 на 256 бит, Интелу потребуется только одна инструкция, причём все операнды лягут в регистры, а АРМ будет умножать столбиком по 32 на 32 бита с суммированием и сохранением в ОЗУ кэша, т.к. ему даже регистров не хватит для этих 128 байт множителей и результата…
Проверь: две операции умножения AVX512, и после команда ветвления по сравнению результата. Время выполнения должно охладить веру в x86.
Код обязательно в асме вставке, иначе gcc наоптимизирует предварительное вычисление.
Такие операции используются в сложных расчётах типа шифрования с длинным ключом, вычислений с повышенной точностью, там очень много математики и очень мало переходов. Сам процессор всё так же 64-битный, нет и речи по переводу процессора на 512 бит, поэтому ветвление не пострадало. И компилятор, естественно, нужно использовать знакомый с этим набором инструкций, иначе он действительно наоптимизирует.
ARM тут, кстати, поступил умнее — сделал блок, которому можно просто задавать любую размерность, которую осилит на практике — так что код не надо переписывать, если следующий процессор станет поддерживать 512 бит вместо 128.
Новые наборы у Intel для конкретных применений, типа видеокодеков — да, факт, начиная с BMI наборов. Но вы ошибаетесь, отрицая это у ARM: ARM это делает вместе с конкретными вендорами и не вынося на общий доступ, поэтому в публичную документацию это обычно не попадает. Какое-нибудь «Умножая 256 на 256 бит» делается внутри Qualcomm или Apple, и доступно под NDA авторам конкретной библиотеки.
Нереально это, поэтому 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-представление — не фатальная проблема.
Проблема с этим подходом, что он не интегрируется никак в OoO конвейер, не позволяет процессору выбрать, какое АЛУ будет исполнять, и так далее. Поэтому и работать с ним надо более крупными блоками. Например, SHA1 — лучше всего сказать ему «читай с этого адреса», а он дальше будет исполнять. Это уже криптопроцессор :) В чём-то вроде раутера, нацеленного на поддержку 100500 IPSec-соединений, такое точно будет — но в систему общего пользования ставить достаточно неудобно. Уже имеем аналогичный гимор с GPU: пока настроишь, пока данные в него вольёшь…
AES делают потому, что он плохо ложится на обычные команды процессора (приходится или табличками, что чревато атаками через кеш, или же долгими и нудными расчётами мультипликативной обратной величины). А чача хорошо ложится на SIMD, как и SHA-3 в общем-то.
Я не верю, что это проблема интеловской имплементации. Над этим очень умные люди работают и это уже не первое поколение.
А что в итоге? Ну ладно на линпаке (и части BLAS) получается почти двойка… Но на реальных бенчах куда меньше. На большом набор HPC прилаг я видел 8-11%
Посмотрим что у Арма получится с SVE. Но у меня есть твердое убеждение что 256 бит -sweet spot. Нет в природе (существуюзщей базе софта) более длинных векторов.
Реально же одна инструкция даже в идеале выполняется минимум за 2 такта (в первом выбрали из памяти, во втором декодировали и исполнили), полезная же — за минимум 4 (ещё выбрали данные, послали в АЛУ и, если повезёт, на этом же такте записали в выходной регистр). Где вы видите меньше — там качество конвейера, out-of-band блока и прочих, где пока первая команда пишет результат в память, вторая выполняется в АЛУ, третья собирает данные из регистров, четвёртая декодирована и ждёт старта, пятая как раз читается из памяти (пусть другой канал, чем первая пишет результат...)
Показатель IPC (инструкций на такт) у x86 был <=1 только во времена приблизительно до Nehalem (2008). С наступлением Nehalem, Sandy Bridge и последующих, как окончательно закрылись возможности гонки по частоте — Intel и AMD начали оптимизировать именно параллельность в одном ядре, и теперь IPC=5 (то есть, в обратных цифрах, 0.2 такта на команду) не редкость. ARM'у не хватает инженеров, но уже пару лет как IPC=2 реальный тиражируемый результат.
Если бы не этот ROM front end x86 давно превысил бы все разумные пределы. Там же оседают другие элементы ISA -например счетчики. Только этот ROM тоже не маленький и не бесплатный. Но поскольку все это не от хорошей жизни никто никогда не расскажет во что он обходится…
Для x86, в микрокоде очень мало что полезно писать именно отдельными командами. Туда выносятся инициализация/самопроверка, сложные многоступенчатые операции типа входа/выхода VM, анклавов и т.п., обработки денормализованных (где они ещё не исправлены по сравнению с допотопной реализацией 1970-х) или команды, которые нахрен никому не нужны, но надо поддерживать ради легаси (как RCL/RCR). Выносить туда декодинг — они себе не могут позволить: даже если удастся разогнать этот внутренний автомат до 20 ГГц, его не хватит, чтобы успевать разрабатывать столь путаный поток байтов.
Согласен. Всегда говорил, что не надо программистам мозги ассемблером забивать. У них и так есть баги, дедлайны и начальство. :) И компилятора тоже не надо, самый лучший язык — Java :)
откуда вообще взялся CISC
Эта классификация появилась намного позже самого создания «CISC» процессоров.
Поэтому тут для удобства программистов нужен CISC.
Ничем не обоснованное, ложное утверждение. Сколько лет вы программировали на асме?
Я писал под пяток разных ассемблеров и поддерживаю, хоть и частично, утверждение вашего оппонента. Частично — в том смысле, что удобство программиста тут не абсолютно решающий критерий — но крайне важный.
> Эта классификация появилась намного позже самого создания «CISC» процессоров.
Это абсолютно неважно. Подходы не теряют смысл от того, что они никак не названы или названы иначе, чем будут когда-нибудь потом.
Когда компилятор генерирует, грубо говоря, 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).
Вот с этим легаси и живём.
AMD могли бы это исправить, но не захотели (возможно, от бедности) — в результате 64-битная система команд ещё хуже 32-битной
Вероятно, просто на чип не помещалась бы эффективная реализация одновременно двух слишком разных наборов команд.
Ну может я не вижу какого-то трюка, который бы дал частично это совмещать — но слишком уж они разные.
Кстати, слышал, у Intel в P4 и части ранних Core 64-битка была с сильно урезанным конвейером — они впихнули её просто ради формальной поддержки (в результате 32-битка работала заметно быстрее). Опять же, если бы тут было легко совместить — они бы быстрее сделали полноценную реализацию.
Таки больше похоже на то, что авторам было облом слишком радикально менять.
- 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."
Если x86 такой устаревший, почему он такой быстрый?
Если кто не верит, то: lcq2.github.io/x86_iphone
;)
подавляющее большинство новых айфонов имели на борту x86 процессор
… в модеме! Для его RTOS и прошивки обработки сотовых протоколов.
Но не в качестве Application Processor для основной ОС и приложений.
у кого-то в модемах ARM
у кого-то VLIW (Hexagon).
Пользователь разницы не видит. Айфоны так вообще одно время производились с двумя модемами сразу, в аппарате мог быть как Qualcomm так и интел.
ЗЫ: кстати, забавно что интел-модемы «сливали» куалкоммовским. И даже была тяжба на эту тему — обвиняли Apple, что она специально занижает скорость беспроводных соединений у аппаратов с модемом Qualcomm, чтобы они не отличались от таких же, но с модемом интел.
… в модеме! Для его RTOS и прошивки обработки сотовых протоколов.
Ну так это одна из самых главных частей телефона, это напрямую сказывается на комфорте работы пользователя.
у кого-то в модемах ARM
у кого-то VLIW (Hexagon).
Hexagon — это DSP.
В модемах — да, есть прямая конкуренция, причем x86 показал, что он не хуже.
Пользователь разницы не видит.
Вообще-то видят, просто они не знают, кого винить в том, что у него внезапно данные не передаются.
в аппарате мог быть как Qualcomm так и интел.
На стороне сотового оператора много чего видно и статистика есть…
кстати, забавно что интел-модемы «сливали» куалкоммовским.
Это не удивительно, Qualcomm все таки накопил огромную базу кода (я видел части, это кошмар), с кучей условных #ifdef, это крайне сложно переписать по спецификациям.
Посчитал (руками в дизассемблере) среднее заполнение пакета в случайно выбранной функции из примерно 500 инструкций (функция — управляющий алгоритм общего плана, никакой DSP специфики) для VLIW-ядра QDSP6 (оно довольно распространённое кстати, по нескольку в каждом SoC/модеме от Qualcomm), получил 62.5% (2.5 из 4). Интересно, как это соотносится с эффективностью переупорядочения инструкций тем же x86?
Однако у компилятора по идее для этого куда больше ресурсов — больше информации о коде, мягче требования к скорости. В чём загвоздка?
Загвоздка в том, что:
У разных процессоров может быть разное количество функциональных блоков, разные задержки. То есть код получается жёстко привязан к конкретному процессору.
Предсказание ветвлений в современных процессорах — динамическое, тогда как компилятор генерит статический код.
Программы под x86 и так компилируются непозволительно долго. А для 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
VLIW-компилятор не может код после ветвления объединить в бандле с кодом до ветвления
Бранч и будет завершающей операцией в бандле.
Если вы переживаете на счёт потенциально пустых VLIW слотов, то начать вычисление можно спекулятивно. Во VLIW/EPIC процессорах как правило есть механизмы спекулятивного выполнения на уровне ISA.
По сравнению с другими проблемами VLIW, эта совершенно незначительная.
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, уже имела качественный внутренний заполнитель. С тех пор его ещё в разы улучшили.
А теперь представьте себе, что b, c, d — в кэше L1, а a — не в кэше (ждём 300 тактов). Чтение a задерживает не только первый add, но и всех последующих, хотя мы давно могли выполнить операции для c+d. Но стоим ждём…А разве компилятор не может (должен) добавить префетч?
Представьте себе, что этот код — в отдельной функции. Вызываемая функция не знает про необходимость сделать префетч — будем тормозить и ждать.
OK, пусть это часть большой функции. Тогда мы дали префетч тактов 50 назад, а на прочитать из DRAM надо 300. Стоим ждём…
Ну и сами префетчи место занимают — надо их закодировать, адрес предварительно вычислить и тоже его сохранить…
Нет, если сам программист не позаботился об этом, потому что просто не на чем предсказать, когда и как его выполнять. Компилятор получает такие знания при инлайнинге, и то это работает не всегда — адрес может быть следствием вычислений в функции.
По крайней мере сейчас логика префетча включается, AFAIK, только в векторизованных циклах. И то — она обычно работает на ситуацию «строка DRAM уже открыта, надо выбрать следующие 64 байта в этой строке», а не «идём на произвольный другой адрес, на переоткрытии строки теряя 200-300 тактов». Потери такого порядка (самые длительные) компилятору недоступны для понимания и могут быть отработаны только человеком.
И вот тут как раз, если OoO со свободным переупорядочиванием даёт хотя бы 20-30% ускорения, то оно стоит реализации.
Устранить эти задержки очень просто… ставите static RAM. Для этого нужно… ну вот смотрю — 32GB (нормальный объём в 2020 для десктопа, где запускается что-то не только для дома) стоит (2*16) — около 220$. Для SRAM надо будет его (если будет массово производиться в сходных объёмах! а также спроектированы и вылизаны контроллеры и модули памяти) умножить этак на 6-12… возьмём самую оптимистичную цифру (6), получим 1320$. Вы готовы столько платить?
Я думаю, что для зверя типа «рабочая станция» с софтом, который может стоить не меньше — это подъёмно. Но рынок со мной не согласен. У большинства запросов достаточная локальность, чтобы кэш сокращал большинство задержек. Не все, но большинство. Но разница между 1100$ на памяти и, пусть даже, 50$ на OoO-блок — никак не в пользу быстрой памяти…
А также того, что стоит по пути к ней — это кэши и система синхронизации этих кэшей между разными ядрами и процессорами.В интелевских процах какой-то уж совсем забубенный и неконтролируемый программистом, хардверный, хаускипинг. Почему не отдать максимум компилятору или иному софту, а когерентность и синхронизацию кэшей частично похерить, в первую очередь для L1, может, и L2? Поведение станет как минимум более предсказуемым.
Да, компилировать на рабочих станциях станет резко больнее, но для удешевления системника под столом на 10% я бы сам не пожалел время от времени покупать время на сервере для компиляции.
Но разница между 1100$ на памяти и, пусть даже, 50$ на OoO-блок — никак не в пользу быстрой памяти…Но если учесть затраты на программистов, которым нужно больше мозгов и следовательно зарплаты, уже можно подумать. Жаль, интересанты разные :)
Поведение не станет предсказуемым, потому что есть ещё и многоядерность, и работа с памятью ведётся по принципу "вас много, а я одна". Помимо разведения кэшей придётся ещё и разводить память, переходя к NUMA-архитектуре. Кстати, в первых Threadripper именно так и было.
Помимо разведения кэшей придётся ещё и разводить память, переходя к NUMA-архитектуреПочему бы и нет? Каждому ядру свой канал, например. Не понимаю, почему это должно пугать: при программировании для GPU NUMA уже есть, но есть и инструменты, уменьшающие геморрой.
Почему бы и нет? Каждому ядру свой канал, например. Не понимаю, почему это должно пугать: при программировании для GPU NUMA уже есть, но есть и инструменты, уменьшающие геморрой.
А далеко не всегда получается с этим геморроем справиться. Оч сильно от ворклоада зависит.
Оно не станет полностью детерминированным, но станет более предсказуемым, можно будет подогнать данные заранее. Имхо, когда данные ждут в L3 лишние 100 циклов, лучше, чем если проц ждёт данные из памяти 100 циклов.
Собственно, и сейчас ничто не мешает подогнать данные заранее. Просто алгоритмов, которые на 100 тактов вперёд могут однозначно определить, какие данные им понадобятся, не так уж и много. Навскидку — это алгоритмы обработки изображений, не имеющие ветвлений, но они как раз вполне нормально реализуются на GPU. Ну и по своему опыту могут сказать, что расстановка префетчей в реальных алгоритмах — как мёртвому припарка, эффекта практически нет.
Почему бы и нет? Каждому ядру свой канал, например.
Потому что нагрузка на память неравномерная. Например, одно ядро молотит большие матрицы с использованием AVX-512, а другое работает с данными, помещающимися в L2-кэш.
А ещё добавьте сюда обмен данными между памятью и различными устройствами — видеокартой, жёсткими дисками. Оно вообще минуя ядра идёт.
Ну и по своему опыту могут сказать, что расстановка префетчей в реальных алгоритмах — как мёртвому припарка, эффекта практически нет.
Cогласен на 99%. Хардварные префетчеры очень четко отрабатывают простые паттерны доступа. Добавить что то поверх них, как правило не выходит.
Вот например MESI протоколы синхронизации кэшей — везде в обычных книгах описывают только состояния, не упоминая сложность переходов. Действительно, кодеру достаточно понимать базу (достаточно ли?) А реализатору — ещё и сообщения, как они себя ведут (краткий обзор тут). И тут «открылась бездна, звезд полна». Помните, в конце 1990-х были популярны чипсеты от Serverworks? У Intel тогда эта синхронизация была настолько глупо сделана, что на Serverworks система могла работать раза в два быстрее, ничего больше не меняя в железе и софте. Кончилось закономерно — их скупили и алгоритмы применили у себя. У Intel мало разработчиков? Вроде достаточно:) но всё равно работы безумно сложны.
Пока есть возможность двигаться эволюционно, мелкими шажками, продвигаясь от уже реализованного — это будут делать. Что-то принципиально новое вызревает рядом, но ему потребуются десятки лет, чтобы дойти до конкурентного уровня.
У Intel мало разработчиков? Вроде достаточно:) но всё равно работы безумно сложны— Много. И Умных. Но каждый копошится в своем углу. Полную картину вряд ли кто то понимает…
Но если учесть затраты на программистов, которым нужно больше мозгов и следовательно зарплаты, уже можно подумать.
Часто ловлю себя на мысли, что мне уже мозгов не хватает. То ли я стал настолько старым, то ли программирование стало настолько сложнее. Похоже и то, и другое… :(
В интелевских процах какой-то уж совсем забубенный и неконтролируемый программистом, хардверный, хаускипинг.
А уж скока места он занимает — просто кошмар. Но надо сказать, что он адресует много корнер кейсов. Там где простенький анкор AMD зачастую ломается и проседает по производительности, интеловый держится.
«строка DRAM уже открыта, надо выбрать следующие 64 байта в этой строке», а не «идём на произвольный другой адрес, на переоткрытии строки теряя 200-300 тактов». Потери такого порядка (самые длительные) компилятору недоступны для понимания и могут быть отработаны только человеком.
И то не всегда. Мои «любимые» кейсы — вычисления с двойной идексацией. По первому индексу берешь второй из массива (огромного) и ловишь кэш мисс. А потом по этому индексу читаешь данные из другого массива (еще больше). И разумеется ловишь второй. И сделать с этим ничего нельзя. Даже программистов поубивать, потому что код 40 лет назад написан :)
И то — она обычно работает на ситуацию «строка DRAM уже открыта, надо выбрать следующие 64 байта в этой строке»
А разве это не связано с банальным размером кэш-линии? Программа запросила байтик, процессор не нашёл его в кэше, психанул и загрузил burst-ом из памяти сразу 64 байта, так на всякий случай.
Собственно, поэтому и делают автоматический префетч в процессоре (алгоритмы его у разработчиков за ста семью замками, но его существование известно): высокий шанс на использование этих данных и лёгкая доступность, значит, «надо брать».
дохрена
>> сколько времени разрабатывается компилятор?
раньше Qualcomm дорабатывали GCC. Потом перешли на LLVM. Соотв. доработка заключается только в работе над кодогенератором.
>> И самое главное — если в системе добавляются новые инструкции, сколько времени уйдет на перестройку компилятора?
Весь же он перестраиваться не будет…
Но у этой медали есть и оборотная сторона — сегодня вы можете взять, например, Jetson Nano или Zynq UltraScale и сделать на них нечто чумовое, что ни на каких решениях от Интела вы не сделаете, потому что nVidia и Xilinx в комплекте с не Бог весть какими ядрами от ARM предлагают от себя нечто особенное. И пусть те ядра сравнимы с ядрами х86 десятилетней давности, но вы ни десять лет назад, ни сейчас не могли у Интела купить что-то аналогичное в комплексе. Вот в этом и есть настоящий успех ARM.
трижды проклятый х86 как натягивал всех, так и натягивает
Он их «натягивает» примерно по той же причине, по которой стандарт 110В продолжает «натягивать» 220В в США — на него слишком много всего завязано, перейти на любую альтернативу, будь она хоть в три раза эффективнее по энергопотреблению или средней длине кода, очень сложно, долго и дорого.
Не совсем так. Вот я бы купил ноутбук для работы (трёхмерная графика) на ARM, но на них для работы нет ничего — есть только недопланшеты с прикреплённой клавиатурой, для которых максимум — браузер и плеер. Всё, что сложнее — дико лагает, независимо от частоты и количества ядер.
Ну а если заметной экономии не будет — то к чему вообще весь этот спор про системы команд?
К чему спор про ISA — ну, каждому свое. Мне интересна преимущественно скорость исполнения, которая может поменяться при изменении системы команд — энергопотребление на втором плане.
Тут не спорить нужно, а профильные ветки читать, где люди тестами сами занимаются, по крайней мере я так делаю, поскольку сам в тесты не умею )))
занёс некоторым разрабам бенчмарков (которые подумали-подумали и внезапно уменьшили вклад многопотока в общую оценку производительности)А были пруфы на этот счет? Холиварить сейчас не в настроении, но если это действительно не просто вывод интелохейтеров — хотелось бы знать.
На счет злополучного сравнения — я так понимаю, Вы имеете в виду i3-8350K vs 2700X. Давайте вместо него посмотрим на i3-9350KF vs 3700X. Там такое же скромное преобладание интела в однопотоке и огромное преобладание AMD в 8-core. Но еще там есть вкладка с FPS-ами в играх. Видим, что наглову разбитый Intel внезапно показывает себя лучше, чем AMD. Да, я понимаю, что теоретический пик FLOPS'ов у AMD больше. Но подавляющее большинство пользователей не сможет их использовать (у меня не получилось загрузить 6/12 процессор на полную ничем кроме компиляции плюсового проекта). Поэтому то, что оценка Интела лучше, чем AMD (напомню, что она всего лишь +2%) — это как раз то что нужно для подавляющей массы пользователей. А эксперты вместо горения могут проскроллить страницу и посмотреть на результаты конкретных тестов. А если не могут — возможно они просто относятся к подавляющей массе? :)
А давайте.Хмм, это интересно :) Видимо они также учитывают Value for Money и Price. Ну или действительно все поломали. Хотя, согласитесь, что для обычного смертного 8400 за $175 действительно лучше чем 9980XE за $1150.
Плюс утверждение про то, что большинство ради игр берут комп тоже так себе.Верно, еще для серфинга в Интернете, офисных приложений… Сколько ядер они загружают?
фанатизм или подкупЭто возможно, не спорю. А возможно их смутила необходимость восхвалять многоядерный процессор, который чуть ниже проигрывает малоядерному во всех играх.
Так вот, банально, то, что вы не можете нагрузить 6/12 показывает превосходство сего процессора на 4/4.Его превосходство в компилировании плюсового кода. А в браузере, Word'е и большинстве игр 4/4 с +10% однопотока будет лучше.
попытка его использования ведёт к сильному падению производительностиЕМНИП путаете с AVX512.
которую многие оценивают как большой фейл, ибо попытка его использования ведёт к сильному падению производительности, потому что блоки больно горячие и вызывают просадку частот ниже базовой?
Однако многие аплодируют стоя )))
AMD потеряла все полимеры как раз к 2008 году. А Intel добила AMD, выпустив Sandy Bridge с AVX в 2011 году, после чего и наступил застой.
Про Келлера?:)
Нет, не уделывает
Вы тут про обьективность писали.
Так вот — я не сторонник какой-то фирмы.
Обьективно рейтинг по spec примерно такой:
1.Ice Lake
2.zen 2 — apple a11-13
3.skylake-coffelake — cortex-a76 — zen/zen+ apple a10
Ice lake чуть вышел вперед, но у него ядра совсем жирные стали.
Держите, вы уронили
www.anandtech.com/show/15578/cloud-clash-amazon-graviton2-arm-against-intel-and-amd/5
Здесь ice lake и zen 2 в одном тесте. Они действительно оставили ARM вновь позади.
У ARM есть еще cortex a77, и в этом году будет что-то еще.
Armv8 всего 9 лет. А развитие фактичски началось с cortex a72 в 2015 году.
Ну и, повторюсь, Гравитон/Гравитон2 — лишь одна ниша, пусть и довольно большая. Не зря именно в нее уже более пяти лет бьются примерно одни и те же лица, в другие ниши как-то совсем не лезет (помимо, конечно, эмбеда, о чем я выше написал).
forum.ixbt.com/topic.cgi?id=8:25877
Вообще я сначала не понял что за Хобот.
Anandtech или habr я бы больше доверял чем ixbt.
Phoronix еще есть. Есть и другие профессиональные сайты.
Как ixbt верить я не знаю.
P.S.
У меня такое впечатление сложилось об ixbt что:
люди там не то что к IT но и как правило к естественным наукам отношения не имеют. Я помню там какие-то споры что читаешь и понимаешь что оба оппонента даже не знают о чем они спорят.
Я туда больше не хожу.
Информация по теме не найдена
Вы поиском пользовались?
Anandtech или habr я бы больше доверял чем ixbt
Очень зря. Но дело ваше.
Не, все равно на phoronix или anandtech тесты более профессиональные
Как тема называется?
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=
Мне жаль, но я не хочу столько читать.
Я бегло прошелся, тоже самое там что и здесь.
Одни говорят что arm крут, другие наоборот.
Как и у нас здесь с вами.
Один человек выразил странные сомнения что A76 слишком мал по площади чтобы быть таким быстрым. Все так привыкли к огромному по площади x86 что уже и не верят. Что тут поделать.
P.S.
Этот диалог превращается в бесполезный холивар.
На ixbt я просто много насмотрелся когда люди спорят что лучше просто потому что. Без фактов. Оба.
Anandtech'ки довольно подробно делают тесты. На хабре тоже тесты часто качественные да еще и с фидбеком. Ну я тесты не особо часто читаю.
А ixbt чисто обзорный.
Отсюда следует что здесь некоторые люди и сами неплохие тесты проводят.
По железу лучше электронику почитать)
А так я поссылке почитал — и сразу нашел несколько сферически-логических выводов в вакууме.
Мне вот это не нужно даже
>На хоботе лучше про железо обсуждать или читать.
У меня сейчас tablet с клавиатурой на core m3 -7y30(kaby lake). Я знаю что zen2 и ice lake уже быстрее, следовательно когда я буду менять железо, то это будет zen2-3-4/ice-lake/tiger-lake. И не сильно важно какая там сторона на 5% быстрее.
Может вы не так поняли.
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 в среднем по больнице — отличный показатель.
Я так не делаю. Да, пару тестов и все.
Можно самому проверить, иногда.
>Теперь остается узнать, что если ноуты, то каждый производитель реализует систему охлаждения в разных моделях по своему, а именно от неё зависит насколько задушат процессор.
В таблетах выбор на порядок меньше чем в ноутбуках.
Я взял cube mix plus. Не очень удачная вещь)
Но к нему оказалось легко приделать медную пластинку и процессор упал с 90 до 60 градусов. На полные 2.6 работает.
Просто Хабр нынче более модный ресурс, и заметно более программистский (при этом в части ИТ-администрирования хобот все же сильнее и масштабнее ИМХО), к тому же тут нет «совсем уж посторонних ученым людям» форумов типа «Общей истории» (где на хоботе тоже весьма сильные люди были когда-то, хотя и не ВИФ2НЕ конечно), поэтому собеседнику Хабр кажется более лучше.
И, как говорится, почувствуйте разницу во входных трактах (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 инструкций для аналогичного результата.
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.
Все эти ARM платы идут с впаянными процессорами, и предустановленной ОС. Даже на всякие популярные raspberry нельзя поставить альтернативную ОС, или даже собрать mainline linux kernel, что уж говорить о всех других платах.
Это не говоря уже о поддержке периферии. К x86 плате через разные адаптеры можно подключить вообще любую существующую периферию, а arm-платы имеют довольно короткий список совместимого оборудования.
Особенно я бы здесь не доверял huawei, их телефоны идут с залоченым загрузчиком, для которого нет официального анлока. Думаю, что с серверами будет такая же шляпа.
Я понимаю, что это не про ISA, но ISA ведь ничего не стоит без поддержки железа.
Но с тем что впаянные прцессоры -это не айс согласен.
Нормальная система. Для ~90% применений — линукс линуксом, ну стиль местами другой :)
Виртуализация заметно слабее — это хуже, да.
Судя по valgrind, у VTune должно было быть заметно специфической заточки под особенности ОС. Тогда понятно — ради двух кастомеров вспоминать всю специфику — задолбёшься. Или я неверно понял причину?
На raspberry pi3 человек собрал gentoo arm64, я поставил, работает. Каких-то «особых» проблем нет.
Современные x86 по бОльшей части впаянные. Т.к. если я ничего не путаю, стационарники отходят.
Впаянность сокращает свободу сборки готовой системы. Сейчас можно в одну и ту же плату поставить разные процессоры (и наоборот). Кому-то нужно больше памяти, кому-то больше слотов pci-e x16, а кому-то экзотические интерфейсы.
На той же злополучной raspberry pi внутри есть PCIe, но к ней нельзя подключить внешнюю видеокарту, sata контроллер или что-нибудь еще.
В то же время если одноплатники станут со сьемными процессорами — платы у них так и остануться без sata. На серверных платах у ARM как правило не так плохо с переферией.
По поводу gpu: Думаю одноплатники не предназначены пропускать 200 Вт. И с драйверами проблемы были бы.
А так — переходники ваше все)
Raspberry Pi кажется так и не могут поддерживать Gigabit Ethernet.
ACPI и UEFI конечно хорошо, но хочется еще пару sata и пару ethernet.
Что можно с двумя чего с одним нельзя? — Правда интересно.
>Посмотри на десктопный интел, прямо сейчас в днс 114 материнских плат, и 54 процессора. Из них я могу сложить 6156 компьютеров, и почти все будут работать. Кто еще так может?
Ну если считать процессоры с одинаковым числом ядер в пределах 500Mhz как за один(потому что разницы не чувствуется), то 6156 превратится в примерно 1000.
Да, у ARM все еще меньше будет выбор, но я с вами уже и согласился насчет периферии.
А как же инструкции „AMD 3DNow!“, которые AMD сама родила, и сама же не сильно давно убила, перестав поддерживать в процессорах Bulldozer?
А вообще, я думаю, это всё можно причесать, если убрать лишнее из железа и компиляторов, а устаревшие инструкции эмулировать при помощи тех, что остались на программном уровне.
а устаревшие инструкции эмулировать при помощи тех, что остались на программном уровне
Как вы себе это представляете?
Процессор, продающийся с примечанием «ваши старые программы на нём заработают только под новой ОС, где реализована эмуляция старых инструкций»?
Это будет очередной Itanium.
Но внутри одной x86, конечно, так делать не будут — только при радикальной смене ISA.
Постепенно.
Например windows 10 эмулирует x86 на x86-64. Если старые режимы убрать — она продолжит работать.
Linux давно весь перекомпилирован на все новое.
Причём тут Windows, когда это поддержка старых инструкций со стороны процессора?
Real mode работает только в момент запуска.
В amd64 есть все нужные алиасы для работы с половинами и частями регистров, и даже чуть более того.
Если и начинать переделывать x86, то мне кажется(мое мнение) что для начала можно отрезать старые режимы. Там есть часть ISA не попавшая в amd64, но и сейчас занимающая свое место в декодере/микрокоде.
P.S.
Может я чего-то не знаю, и какие-то драйвера до сих пор прыгают в старые режимы. Поправьте кто в курсе, если что не так.
К слову, от поддержки 16-битных приложений в Win64 отказались, даже эмуляцию приделывать не стали.
То есть теоретически 64-битная винда может выполнять программы Windows 3.x без эмуляции, если захочет.
На самом деле нет: программы для Win16 эмулировались тем же самым ntvdm, потому что Win16 разрешала использовать int 21h даже в защищённом режиме.
Я с этим и не спорю. Я изначально говорил что могли бы эти режимы убрать уже.
Там тема была про потенциальную очистку x86.
И насчет полной совместимости, если вы про опкоды то:
Не все инструкции обрели алиасы в x86-64.
Например вот эти: AAA, AAD, AAM, AAS.
Просто опкоды занимают, их и 20 лет назад не использовали практически.
>То есть теоретически 64-битная винда может выполнять программы Windows 3.x без эмуляции
Не уверен что windows 10 может это запустить даже теоретически. Но на практике, если не ошибаюсь, она принудительно не дает процессору ходить в прошлое.
Windows 10 (WoW — Windows On Windows subsystem) программно выполняет x86-32.
Выполнять программы от 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 слоя только чуть-чуть тормозит…
В длинном режиме есть только 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-битных системах. Я, правда, сам это не пробовал делать.
ok, согласен. Давно не вспоминал, а их документацию читать нетривиально — всё время нужно продираться через слои поправок к собственному тексту :(
Но уже вырезание V8086 означает потерю старого DOS-хозяйства.
> The primary reason is that handles have 32 significant bits on 64-bit Windows.
А что именно из хэндлов и каких не влезло в 16 бит — умолчали. Файлы, например, сюда не будут относиться.
Но уже вырезание V8086 означает потерю старого DOS-хозяйства.
При этом ничто не мешает запускать DOS-программы с помощью эмулятора или внутри виртуальной машины, если не хватает скорости эмулятора (впрочем, это крайне маловероятный сценарий).
А что именно из хэндлов и каких не влезло в 16 бит — умолчали. Файлы, например, сюда не будут относиться.
Но там проблем с их передачей 16-битным приложениям не было.
Если и начинать переделывать x86, то мне кажется(мое мнение) что для начала можно отрезать старые режимы. Там есть часть ISA не попавшая в amd64, но и сейчас занимающая свое место в декодере/микрокоде.
А вы можете дать оценку, насколько упростится процессорная логика, если эти режимы выпилить? Может быть, в выпиливании вообще нет никакого смысла?
>Может быть, в выпиливании вообще нет никакого смысла?
А вот по такой логике их так и будет становиться все больше, а смысла выпиливать все так типа и не будет.
Я не могу дать точную оценку, но очень подозрительно что ядро больше чем L3
Мне кажется legacy имеет влияние сильно дальше чем область декодера.
Например, длина avx инструкций — не хорошо для кэша. А длина у них могла быть по меньше, будь больше свободных опкодов
Ну вот посмотрите тут фоточки Zen:
https://en.wikichip.org/wiki/amd/microarchitectures/zen (Die > Core)
Декодер там занимает достаточно небольшую часть. Не получится на нём сэкономить.
Даже 64-битные умножители так много не занимают.
Про x86 часто говорят:
1.Кэши потребляют бОльшую часть энергии
2.Декодер требует мало энергии/площади.
И эти два противоречат.
Как я уже написал, сложность ISA вероятно имеет более глубокие последствия.
Linux давно весь перекомпилирован на все новое.
Внезапно, под Linux предостаточно closed-source приложений. А даже когда и open-source, то не всегда можно просто взять и перекомпилировать, особенно если вендор забил на поддержку («исходники у вас в руках, **итесь как хотите»).
В прошлом году у меня был запоминающийся экспириенс по починке багов в проге для Linux — она была хоть и с открытыми исходниками, но собиралась в какой-то неведомой среде, которую я так и не смог заставить работать. В итоге я отказался от попыток её перекомпилировать, и правил прямо бинарник, добавляя код на место padding между функциями.
>Внезапно, под Linux предостаточно closed-source приложений.
Ну я немного утрирую, но бОльшая часть софта идет на amd64.
Например windows 10 эмулирует x86 на x86-64.
В каком смысле «эмулирует»? Инструкции 32-битных процессов по-прежнему выполняются процессором, а не путём программной эмуляции. И даже в виртуальных машинах.
Эмуляция — это Bochs32, например.
Ссылки в порядке увеличения важности
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
Автор же скорее имел в виду содержимое основного (гарантированного) набора: никому не нужные RCL/RCR, неисправимую кривизну интерфейса BSF, BSR, атомарность XCHG, занятые однобайтные коды под IN, OUT, CMC, STD, INS, OUTS, SCAS (для них всех и трёхбайтный ничего бы не испортил в плане производительности) и прочая и прочая…
Помнится когда осваивали SSE2, была возможность на винде выполнения кода на не поддерживающем его проце. Если я правильно понимаю, перехватывался IllegalInstruction, софтверно выполнялась обработка, код медленно, но работал. Без виртуализации. Вот могу конечно врать, давно уже было однако.
Интересно, когда мы увидим Intel-x64-only процессоры. Система команд там значительно проще с более логичным кодированием. Плюс, возможна более эффективная настройка механизмов кэширования и упреждающего чтения.
За счёт освобождения площади кристалла и упрощения логики до 20% прироста скорости на некоторых задачах может быть. А такой прирост на кристалл сейчас очень долго стоит.
И ниша уже есть — всякого рода сервера и вычислительные системы, где x86 остался только в загрузчике.
И каким же образом это скажется на скорости? Просто интересно.
- Освободиться место на кристалле, которое можно будет использоваться для других целей.
- Очень сильно упростится время декодирования команд. Оно, конечно, все кэшируется, него там много ограничений и это не на всяком коде работает.
- Механизмы предсказания и кэширования упростятся. Сейчас приходится идти на компромисс между эффективностью на 32 и 64 битах. Это видно на младших процессорах, где жертвуют производительностью либо того, либо другого.
Уйти от декодера для старых разрядностей — да, возможно было бы полезно. Но, подозреваю, с переключением режима декодер не-текущего режима тупо обесточивается.
Но, очевидно, это пока не стоит выделки. Могли бы начиная с какого-то поколения убрать старт через 16-битный реальный режим. Но для этого тогда надо вначале сделать 32- или 64-битный реальный режим! А это они как-то не очень умеют. Да и SMM надо переводить на новые рельсы…
ISA ошибок не прощает