Разработчики RISC-V повторят ошибки, допущенные при развитии архитектур Arm и x86

дело в убогости самой идеи

в качестве процессоров общего назначения. Векторные инструкции – почему бы и да?

NVIDIA заявляет, что ускоритель задач машинного зрения в Jetson это VLIW. Инженеры в NVIDIA идиоты?

Речь о CPU, не об ускорителях.

Разве Itanium это VLIW?

Да.

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

Бандлы – попытка обеспечить хоть какую-то обратную совместимость. Эльбрус тоже так делает. У итаника инструкции были 41 бит каждая, что довольно много (у x86 есть куча инструкций по 1 байту), и связаны в 128-битный бандл по 3 штуки, плюс немного метаданных.

С анонса Meltdown прошло уже 6 лет. Хоть один пример эксплуатации подобной дыры был?

Только идиот будет ждать пока ему проэксплуатируют дыру, чтоб её закрыть.

Закрыл ли ты свой анус уже?

Если стоимость закрытия дыры превышает потенциальный ущерб от рисков эксплуатации, то только идиот её будет закрывать. Кстати, ты уже перестал писать код на насквозь дырявом убогоньком недоязычке под названием C?

Капец как Линус постарел в этом видосе ;(

Речь о CPU, не об ускорителях.

Так последние, наверное, 30-40 лет не было коммерчески доступных VLIW процессоров общего назначения. VLIW используется только в специализированных процессорах. VLIW не используют в CPU общего назначения, потому что VLIW вообще не предполагает обратной совместимости, а рынок показал, что пользователям она нужна.

Да.

На самом деле нет.

Бандлы – попытка обеспечить хоть какую-то обратную совместимость. Эльбрус тоже так делает.

Уже просто отслеживание зависимостей и переменная длина групп команд идут вразрез с традиционным пониманием VLIW, где все командные слова одинаковой длины. Можно, конечно, понимать что-то своё под VLIW, но тогда проще придумать новый термин, чтобы не было путаницы. Intel и HP так и сделали, они называют свой подход Explicitly parallel instruction computing (EPIC).

У итаника инструкции были 41 бит каждая, что довольно много (у x86 есть куча инструкций по 1 байту), и связаны в 128-битный бандл по 3 штуки, плюс немного метаданных.

Но ты ведь в курсе, что исполнение не обязательно запускается по три команды за раз? Подразумевается, что не будет зависимостей между командами в группе, но группа и бандл это не одно и то же. Группа может закончится где-то внутри бандла, а может простираться на несколько бандлов.

у x86 есть куча инструкций по 1 байту

Странный аргумент. Во-первых, судя по первой попавшейся статье средняя длина инструкций у x86-64 заметно больше 8 бит. И даже больше 16 бит. И даже больше 32 бит. Во-вторых, нет смысла сравнивать длины инструкций, если они генерируют разный набор эффектов.

Ну тут речь вроде про процессоры общего назначения.

Так процессоров общего назначения на VLIW архитектурах уже несколько десятилетий как нет. Если они вообще когда-либо были.

Так последние, наверное, 30-40 лет не было коммерчески доступных VLIW процессоров общего назначения.

А Intel и МЦСТ об этом знают?

Уже просто отслеживание зависимостей и переменная длина групп команд идут вразрез с традиционным пониманием VLIW,

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

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

Ага, может быть и больше.

Странный аргумент. Во-первых, судя по первой попавшейся статье средняя длина инструкций у x86-64 заметно больше 8 бит. И даже больше 16 бит. И даже больше 32 бит.

Средняя длина в какой выборке? Из всех инструкций вообще или из инструкций, которые выдаются в коде? Потому что, как мы тут недавно выяснили, 90% кода на x86 – примерно 12-13 мнемоник.

Короче, твой аргумент скатывается к определению того, что именно является VLIW: ты считаешь, что Itanium и Эблрус ими не являются, но тогда и спорить не о чем, потому что из твоих слов так же выходит, что VLIW не работают для CPU.

А Intel и МЦСТ об этом знают?

Обе компании используют термин EPIC. Это не случайность.

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

У тебя явное непонимание того, что такое бандл, а что такое группа команд. Это не синонимы.

Ага, может быть и больше.

А может быть и меньше. Возможна группа из одной инструкции. Более того, в бандле, в котором определена группа из одной инструкции, остальные инструкции не обязаны быть nop’ами.

Средняя длина в какой выборке? Из всех инструкций вообще или из инструкций, которые выдаются в коде?

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

тут недавно выяснили, 90% кода на x86 – примерно 12-13 мнемоник.

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

Короче, твой аргумент скатывается к определению того, что именно является VLIW: ты считаешь, что Itanium и Эблрус ими не являются, но тогда и спорить не о чем

Именно. Цель моих сообщений — донести информацию об отличиях VLIW и EPIC. Сам долгое время путал. Теперь хочу, чтобы другие перестали ту же ошибку совершать.

VLIW не работают для CPU

Именно так. Но EPIC вполне работают.
К тому же в последнее время фронт уже не так значим, как остальная часть CPU. Теперь важен не набор инструкций, а кем и как реализован проц. Тот же Jim Keller заявлял, что большая часть блоков Zen уже была в Bulldozer. Но Bulldozer получился провальным, а Zen очень даже неплохим. С ARM аналогичная ситуация. Что, у Apple M1 какая-то другая система команд? Да нет, та же. Однако они размазывают ядра Cortex, когда дело касается производительности.

Так что и Intel, и МЦСТ теоретически могут сделать EPIC-процессоры с хорошей производительностью. Но у Intel нет заинтересованности, а у МЦСТ нет экспертизы. Тем не менее, принципиальных непреодолимых трудностей там нет.

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

Так последние, наверное, 30-40 лет не было коммерчески доступных VLIW процессоров общего назначения.

Transmeta?

Там же нельзя запускать код в родных инструкциях для внутреннего движка. К тому же где-то упоминалось, возможно даже в каком-то интервью Торвальдса, что внутренности прямо совсем не подходят. Вспоминается какое-то ограничение на окно в 64MB, то ли для кода, то ли для данных. Короче, совсем плохо. Не факт, что разные модели были совместимы на уровне родного кода для VLIW движка.

Но тем не менее. А Itanium чем не VLIW?

А Itanium чем не VLIW?

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

Обе компании используют термин EPIC. Это не случайность.

Думаю, тебе стоит рассказать перцам из МЦСТ, что они не VLIW сделали. Потому что:

Микропроцессор «Эльбрус» (1891ВМ4Я) – универсальный микропроцессор с архитектурой «Эльбрус» на основе архитектуры широкого командного слова (VLIW).

Отсюда: http://www.mcst.ru/Elbrus

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

Прости, я не телепат чтобы знать заранее о том, что именно лоровские шизофреники имеют ввиду. Но специально для тебя я набыдлокодил небольшой говноскрипт, считающий среднюю длину инструкции в бинарике. Итак…

Во-первых, судя по первой попавшейся статье средняя длина инструкций у x86-64 заметно больше 8 бит. И даже больше 16 бит. И даже больше 32 бит.

Последнее – ЛПП. Скрипт:

#!/usr/bin/env python3

from os import popen
import sys

if len(sys.argv) != 2:
    print("Provide binary path")
    sys.exit(-1)

binpath = sys.argv[1]
cmd = "objdump -r -j .text -d {} | cut -d: -f2 | cut -d$'\t' -f 2".format(binpath)

ilens = []
ldict = {}
allowed = set(string.digits + 'a' + 'b' + 'c' + 'd' + 'e' + 'f')
with popen(cmd) as output:
    for instr in output:
        instr = instr.strip()
        instr = instr.replace(' ', '')
        l = len(instr)
        # skip invalid output from objdump
        if l == 0:
            continue
        if not (set(instr) <= allowed):
            continue
        l = l * 4    # 4 bits per hex character
        ilens.append(l)
        ldict[l] = ldict.get(l, 0) + 1

avg = sum(ilens) / len(ilens)
print(f"Average instruction length: {avg} bits")

for l,n in ldict.items():
    print(f"Number of {l} bit instructions: {n}")

Результаты на разных прогах:

 △ ~ ./instrlen.py /nix/store/qzp74yjsymgpfmr0shcqdzzcrf90x83c-coreutils-full-9.5/bin/coreutils
Average instruction length: 31.862272649418344 bits
Number of 40 bit instructions: 48979
Number of 56 bit instructions: 26298
Number of 16 bit instructions: 42203
Number of 24 bit instructions: 49934
Number of 8 bit instructions: 9953
Number of 32 bit instructions: 22353
Number of 48 bit instructions: 16300
 ▲ ~ ./instrlen.py /nix/store/7lyjbaz0s8rgy4j4iyxz47gi78w72cm0-librewolf-128.0-2/lib/librewolf/librewolf
Average instruction length: 30.25957125758014 bits
Number of 8 bit instructions: 15486
Number of 16 bit instructions: 25239
Number of 32 bit instructions: 34675
Number of 24 bit instructions: 45895
Number of 40 bit instructions: 24776
Number of 48 bit instructions: 10936
Number of 56 bit instructions: 19275
 ▲ ~ ./instrlen.py /nix/store/06dr82w4336x3iwyik7b4criw3gxbwhs-ghc-9.8.2/lib/ghc-9.8.2/bin/ghc-9.8.2
Average instruction length: 29.644412695634006 bits
Number of 56 bit instructions: 58068
Number of 8 bit instructions: 37035
Number of 32 bit instructions: 77798
Number of 40 bit instructions: 32445
Number of 16 bit instructions: 92952
Number of 48 bit instructions: 15599
Number of 12 bit instructions: 3239
Number of 24 bit instructions: 37032
 ▲ ~ ./instrlen.py /nix/store/sdbyh7alvqicf4m42dl9gynqsb8alxzs-reaper-7.18/opt/REAPER/.reaper-wrapped
Average instruction length: 31.763740057415408 bits
Number of 8 bit instructions: 150371
Number of 40 bit instructions: 408041
Number of 48 bit instructions: 236383
Number of 56 bit instructions: 275544
Number of 32 bit instructions: 292061
Number of 16 bit instructions: 418928
Number of 24 bit instructions: 485239
Number of 12 bit instructions: 71
 ▲ ~ ./instrlen.py /nix/store/rb9n6mhvp93f9kyir6zijajbvprnvp3c-nginx-1.26.1/bin/nginx
Average instruction length: 31.912063492063492 bits
Number of 32 bit instructions: 45594
Number of 16 bit instructions: 42845
Number of 24 bit instructions: 49604
Number of 8 bit instructions: 15590
Number of 56 bit instructions: 32944
Number of 48 bit instructions: 15033
Number of 40 bit instructions: 50389

В общем, средняя длина получается чуть меньше 32 бит. Больше всего инструкций по 2 и 3 байта. Я так прозреваю, в остальных раздутая длина вызвана константами или смещениями.

P.S. хз откуда 12-битные инструкции взялись. Возможно, артефакт из objdump. Но в среднем цифры примерно такие.

на основе архитектуры широкого командного слова (VLIW).

OK, этот пункт отменяем. Мне почему-то помнилось, что они использовали термин EPIC. Возможно, выпячивать боятся из-за потенциальных проблем с названием, если вдруг Intel его зарегистрировал где-нибудь.

Тем не менее, e2k — не VLIW. Точно так же несмотря на то, что в e2k есть многое от SPARC, он не является SPARC.

Последнее – ЛПП. Скрипт:

Ты забыл добавить параметр --insn-width=80, поэтому инструкции длиннее семи байт будут посчитаны твоим ЛПП-скриптом как две отдельные инструкции. Поэтому у тебя нет инструкций длиннее 56 бит. Это как раз 7 байт.

хз откуда 12-битные инструкции взялись

А это ты строчку «fileformatelf64-x86-64» посчитал как инструкцию.

Тем не менее, e2k — не VLIW. Точно так же несмотря на то, что в e2k есть многое от SPARC, он не является SPARC.

Опять же, МЦСТ об этом знают? Потому что они пишут, что сделали VLIW.

А это ты строчку «fileformatelf64-x86-64» посчитал как инструкцию.

Не, это 88 бит.

Ты забыл добавить параметр –insn-width=80, поэтому инструкции длиннее семи байт будут посчитаны твоим ЛПП-скриптом как две отдельные инструкции. Поэтому у тебя нет инструкций длиннее 56 бит. Это как раз 7 байт.

Да, принято. С этим ключом получается всё равно около 32 бит.

Опять же, МЦСТ об этом знают? Потому что они пишут, что сделали VLIW.

В твоей цитате написано, что «на основе», а не что это точно VLIW. У них командные слова (или как это там в их терминологии) — переменной длины. И нет требований к явному отслеживанию зависимостей во время вычислений, проц делает это сам.

Изначальная суть VLIW была в том, чтобы как можно сильнее упростить логику разбора, вычисления зависимостей, а проблемы со ступором конвейера переложить на программиста. Ни в Itanium, ни в e2k такого нет.

С этим ключом получается всё равно около 32 бит.

Если бы всё ещё было меньше 32, ты бы это явно упомянул. Тебе что, так сложно признать такую мелкую ошибку? Что же тогда случится на больших?

Я попробовал посчитать по бинарникам у себя в usr/bin, у которых имя начинается на «a», получилось 34.6257. Но для отдельных бинарников бывает и меньше, хотя меньше 32-х не видел. По всем бинарникам слишком долго ждать результатов.

Когда Arm стала серверной платформой, они повторили все те ошибки, которые Линус видел десятилетием или двумя ранее на x86

Мало ли чего он там видел. Одно дело видеть проблему и другое дело это решить.

В твоей цитате написано, что «на основе», а не что это точно VLIW.

Да, конечно. Ты прямо телепат и знаешь, что они имели ввиду.

Если бы всё ещё было меньше 32, ты бы это явно упомянул.

Ну точно телепат!

Тебе что, так сложно признать такую мелкую ошибку? Что же тогда случится на больших?

Тут нет ошибки. Некоторые бинарники меньше 32, другие больше. У меня разброс от 28 до 35. Среднее получилось ~31.7.

В твоей цитате написано, что «на основе», а не что это точно VLIW.

Да, конечно. Ты прямо телепат и знаешь, что они имели ввиду.

Повторяю ещё раз. В твоей цитате написано, что «на основе», а не что это точно VLIW. Где здесь написано, что я знаю, что они имели в виду?

Может быть, ты сам у них спрашивал, и тебе объяснили, что там именно VLIW? Тогда поделись объяснениями.

Ну точно телепат!

В предыдущем сообщении так громко заявлял: «ЛПП!», а тут так тихонечко: «около 32-х». Мне тут надо было подумать, что ты внезапно остыл до нейтрально-безразличного отношения? Очевидно же, что если бы результаты не изменились, ты бы поспешил об этом заявить погромче.

Тут нет ошибки.

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

Некоторые бинарники меньше 32, другие больше. У меня разброс от 28 до 35. Среднее получилось ~31.7.

Ты что, считаешь среднее средних?

Повторяю ещё раз. В твоей цитате написано, что «на основе», а не что это точно VLIW.

Окей, тогда смотри сюда:

В общепринятой классификации архитектуру «Эльбрус» можно отнести к категории VLIW. Доступ к аппаратным ресурсам процессора базируется на использовании широких команд (ШК). При компиляции каждого фрагмента программы происходит максимальное распараллеливание вычислительного процесса по всему полю возможных вычислительных устройств.

Тыц: https://dev.mcst.ru/book/chapter4.html

Не? Мало?

For implementation and experiments we are going to use Elbrus architecture(a VLIW architecture with tagged memory).

Ссыль: http://www.mcst.ru/files/5239a1/4d0cd8/507c55/000000/gorelov_pact2013.pdf

Всё ещё не VLIW?

Elbrus is a VLIW (Very Long Instruction Word) micropro- cessor architecture. It has several special features including hardware support for full compatibility with IA-32 architecture on the basis of transparent dynamic binary translation

Ссылка: http://www.mcst.ru/doc/syrcose11_submission_16.pdf

Точно не VLIW? Ты уверен?

В предыдущем сообщении так громко заявлял: «ЛПП!», а тут так тихонечко: «около 32-х».

Окей, для такого турбоаутиста как ты я напишу самым понятным образом: твоё утверждение, что «Во-первых, судя по первой попавшейся статье средняя длина инструкций у x86-64 заметно больше 8 бит. <….> И даже больше 32 бит.» – ЛПП, потому что средняя длина всё ещё меньше 32 бит.

Не то, что всё это очень важно для меня лично, но мне нравится кидать в тебя ссылками на то, что Ты Очень Неправ.

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

X86 надоел и примелькался тупо за 40+ лет :) А так оно работает, и работает отлично. В среднем по больнице для массмаркета пока лучше ничего не производят.

Точно не VLIW? Ты уверен?

Да, я всё ещё уверен, что это не VLIW, а EPIC, по причинам, которые описывал выше.

Да, ты убедительно доказал, что в МЦСТ считают, что сделали VLIW.

Что дальше?

для такого турбоаутиста как ты

Ха-ха, скатился до личных оскорблений.

ЛПП, потому что средняя длина всё ещё меньше 32 бит.

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

Ты Очень Неправ

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

Ха-ха, скатился до личных оскорблений.

Тебя никто не оскорблял. Ты выдвинул тут три тезиса:

1. Эльбрус – не VLIW.
2. 8-битные инструкции в коде для x86_64 составляют один процент
3. Средний размер инструкции на x86_64 «даже больше 32 бит»

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

Да, я всё ещё уверен, что это не VLIW, а EPIC, по причинам, которые описывал выше.

Это ты должен чувакам из МЦСТ объяснить. Они, кстати, считают свою архитектуру VLIW И EPIC.

Ты уже убедительно доказал, что твои подсчёты обладают множественными дефектами.

Для грубой оценки пойдёт.

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

Что я считаю, не имеет значения. МЦСТ наклеили на свои процессоры щильдик VLIW, не вижу причин им не верить.

Итаник нефатально отставал от x86. Его убило отсутствие софта и стоимость. А так да, жизнь доказала, что влив для современного софта и ЯП всегда будет хуже x86 сам по себе.

Забавно, он как и Эльбрус юзается исключительно во всяких спец-гос-

Забавно, он как и Эльбрус юзается исключительно во всяких спец-гос-

Итаниум уже нигде не юзается. Его перестали выпускать несколько лет как. Старые системы потихоньку закапывают, потому что одна стойка с x86_64 сейчас вполне может заменить несколько стоек с итаниками.

Ты выдвинул тут три тезиса:

Эльбрус – не VLIW.

Это я выдвигал, да. Ты его не опроверг. Ты опровергал другой, «МЦСТ использует термин EPIC для описания e2k». Его опроверг. (Потом, правда, написал, что всё-таки используют этот термин.)

8-битные инструкции в коде для x86_64 составляют один процент

Это тезис из статьи, на которую ты сам ссылался. Тезис ты не опроверг.

Средний размер инструкции на x86_64 «даже больше 32 бит»

Это тезис из статьи, на которую ты сам ссылался. Тезис ты не опроверг.

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

А ты можешь привести «правильное» определение VLIW? Нет? С чего ты взял тогда, что моё понимание неправильное? Я исхожу из свойств машин, созданием которых и родили термин. И я приводил признаки VLIW, исходя из свойств тех машин. Из чего исходишь ты? У тебя вообще есть понимание, что означает VLIW?

Это ты должен чувакам из МЦСТ объяснить. Они, кстати, считают свою архитектуру VLIW И EPIC.

Ты серьёзно считаешь, что я должен за тебя воевать твою войну? Если тебе нужно, ты иди и объясняй.

Для грубой оценки пойдёт.

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

Что я считаю, не имеет значения. МЦСТ наклеили на свои процессоры щильдик VLIW, не вижу причин им не верить.

Как раз-таки имеет значение. Потому что обсуждение в этом треде идёт не между тобой и МЦСТ, а между тобой и мной. Я пытаюсь тебе объяснить, что твоё понимание искажено, но ты изо всех сил упираешься. Причём уже явно был момент, когда ты использовал термины bundle и group как синонимы, что явно показывает, что ты прямо совсем не понимаешь, о чём вообще речь. И агрессивно не хочешь понимать.

Возвращаясь к тому моменту, с которого всё началось. За твоими высказываниями стоит примерно следующее: (1) Эльбрус 2000 это VLIW; (2) VLIW тупиковая ветвь для CPU, (3) поэтому Эльбрус 2000 это тупиковая направление для CPU. Проблема тут в том, что в термины VLIW в пункте 1 и пункте 2 вкладывается разное. В пункте 2 говорится о классическом понимании VLIW, то есть очень широкое командное слово фиксированного размера, отсутствие обработки hazards (не нашёл русскоязычного аналога термина), выполнение по порядку (in-order). А в пункте 1 под VLIW понимают только то, что в одном широком слове может быть больше одной инструкции. Размер широкого слова не фиксированный, обработка hazards между словами в наличии. Исполнение, правда, in-order. Но вот принципиально ничего не запрещает сделать OoO, хотя для этого и придётся заметно усложнить внутреннюю логику. Новые итерации Эльбрус 2000 могут уменьшать или увеличивать время исполнения отдельных операций в тактах, от этого программы не перестанут работать. В классическом VLIW так не получится сделать.

В итоге твоя позиция эквивалентна не «А⇒B, B⇒C означает A⇒C», а «A⇒B, C⇒D означает A⇒D». Видишь проблему?

за гугли Qualcomm + trustzone, загугли проблемы закрытости росберипай проблемы разгона и питания, почитай и перевари весь ужас платформы

Специально работающее железо в mission critical никто выкидывать не будет, трудятся до сих пор итаники в американских аналогах рос-гос

Слишком много букв. Но я процитирую тебя же:

Тебе что, так сложно признать такую мелкую ошибку? Что же тогда случится на больших?

Ты-то сам давно в зеркало смотрелся? ;)

Слишком много букв.

Теперь твоя позиция предельно ясна.

Но я процитирую тебя же:

Тебе что, так сложно признать такую мелкую ошибку? Что же тогда случится на больших?

Там в списке тезисов по пунктам расписано.

Довела сжв-фашня мужика.

Теперь твоя позиция предельно ясна.

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

Я тебе много раз предлагал описать, что ты понимаешь под конкретным термином. Если у него есть единственно-верное определение, привести его ведь не составило бы труда? Тогда почему ты всячески увиливаешь?

Мамкин прогер, предложи свою архитектуру! Но у теня её нет, угадал?

А что под арм и x86 специально код не оптимизируют? Нельзя ни в компаил тайме ни в динамике оптимизовать следующие вещи:
1) поток данных; то есть упаковать шорты или байты в лонги/вектора, нужно писать специальный векторизованый упакованый код. (компилятор может упаковать только совсем примитивную фигню)
2) тырканье в разные куски массива который не влазит в кэш.

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