1) дорого
процессоры и инфраструктура к ним дороже интеловских аналогов, при том что интелы будут побыстрее

2) ПО нужно писать чуть ли не с нуля
сейчас такое время, когда ПО к процессору стоит в 10-100 раз дороже разработки процессора


ммм.
А смысл?

Ни одна железка не имеет памяти на 64 бита адреса.
Максимум что я встречал - на 48 бит.
Остальное используют под виртуальный префикс (ASIC).


16 битная адресация кончилась как кончились 64кб памяти
Та же история постигла 32 битную адресацию когда 4гб памяти перестали быть роскошью, а лазить через виртуальные таблицы стало немодно (точнее, приложение с 32битным указателем не могло кушать больше 4гб иначе, чем костыли ОС; в винде память больше 2гб/3гб (в зависимости от версии обновления емнип) была тупо недоступна одному процессу, под линем похожая история)

полагаю что в ближайшие 20 лет мы не дойдем до объемов, когда память размерами больше 64 бит адресации будет стоить как 8гб оперативы сейчас.

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

Может речь про скользящее регистровое окно?
Реализовать просто, с точки зрения железа, смысл реализовывать такое очень небольшой.
С точки зрения ПО это мало кому нужно. Максимум, будет быстрое переключение контекстов, но конечные пользователи этого не увидят даже.

Это не проц между 386 и 486 ?
авторIntel iAPX 432 Micromainframe — первый 32-разрядный микропроцессор из семейства микропроцессоров компании Intel, анонсированый в 1981 году.

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


Вполне может быть.
Сейчас куда ни плюнь, везде контуры безопасности.
Загрузка с чего попало уже не ведется.
ОС начали защищать ядро уже много лет как. Помню, были версии кривых загрузчиков, которые умели обходить активацию винды. Как я понимаю, сейчас загрузить в секьюрном режиме самодельную ОС без подписи уже невозможно.


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

Жесткие диски всяко медленнее любой оперативки в режиме kernel.
А значит тебе не требуется физическая адресация на уровне регистров процессора такой ширины, как размер предельного жесткого диска. Ты можешь использовать двухуровневую адресацию или трехуровневую или еще какую. Как некоторые кодировки для символов, к примеру, где частые символы занимают 1 байт, а не очень частые могут занимать 20 байт. Это нормально. Вопрос в скорости доступа со стороны процессора.


Емнип, когда речь про ip6, речь шла про рандомные адреса, а не последовательные.
Такие, для которых не будет статических таблиц или правил маршрутизации, привязанных к ip-адресу (а только к домену).

Так-то и ip4 с двухуровневой системой маршрутизации хватит еще лет на 20.
А с трехуровневой на 200.

Номера портов и то раньше закончатся, ибо к ним количество соединений к разным хостам привязано (насколько я понимаю, сейчас нет возможности с одного мастера открыть соединений больше, чем 65к). Принять можно больше, но открыть нельзя.
По крайней мере с ip протоколами.


А смысл? Запускать больше 16 миллионов процессов на одном процессоре?


Таки да.
Но пока процесс не убит, его виртуальное пространство живое, память занята.
Если процессор имеет возможности отслеживания утерянных адресов памяти, он может сообщить об этом в ОС или еще каким-то образом удалять такие записи. И процесс может работать бесконечно долго, имея автоматически сборщик мусора даже при небрежном обращении с памятью.

Я тебе предложил механизм адресации подобной памяти на процессорах с 32 битной адресацией.
Даже с 8 битной и то это возможно.
Даже если размер хранилища (дисков или памяти - не важно) не 128 бит, а много-много раз больше. Бесконечно много, это не важно.

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

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

Вообще не так.
У нас работают достаточно хорошие мозги. Их просто мало, чтобы процессоры стали лучше, чем те.

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


Вот этот момент я не понял. Потому что все тесты в режиме эмуляции x86 на ПО, которое десятилетиями оптимизировалось под интелы.

ИМХО, без перекомпиляции на допиленных компиляторах и работе в нативном режиме любые сравнения бессмысленны.Сберу просто делать больше нечего, как перекомпилировать все созданное ПО под эльбрусы. Плюс, эльбрусы дороже и слабее.


" target="_blank" rel="ugc">https://www.cnews.ru/news/top/2021-12-13_sberbank_vyyavil_katastroficheskoe#22420148]|> https://www.cnews.ru/news/top/2021-12-13_sberbank_vyyavil_katastroficheskoe На других этапах было проведено синтетическое тестирование на основе известных бенчмарков PGbench из пакета PostgreSQL и SPEC CPU 2017, а также прикладное тестирование на основе Java-приложения, реализующего бизнес-логику.ЕМНИП, все эти тесты позволяют делать глубокую оптимизацию через переписывание кода под асм. Сбер вряд ли этим занимался.
А вот интелы и армы - наверняка.

AIR и не позиционировался как проф.комп.
Для этого есть PRO-версии.
Я подумывал его взять, как раз для офисной работы, интернета и впн с рдп. Для всего остального у меня сервера вычислительные есть. Ну и батарейка - мало у кого есть 17 (?) часов работы...


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

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

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

А у GCC или CLANG?Тут как бе вопрос про ядро компилятора или про бэкенд под конкретные таргеты?

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

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

Емнип, у того же АРМ есть "внешний" и "внутренний" компилятор, один на основе GCC, другой на CLANG
А значит, разработчики тоже есть и много.

в СТМ - пять десятков человек

у атмеги емнип десятка два

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



Не является.
И чтобы сделать два компилятора (GCC и CLANG) для эльбруса нужно будет два бэкенда под таргет.
То есть уже хотя бы два человека на постоянку.

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


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

Да тоже не так чтобы все здорово, увы.

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

Не обязательно медленее. VLIW1 это тот же линейный последовательный код.

SIMD и VLIW не одно и то же, мало того, одно другому не мешает.
Кроме видеокарт и SSE есть десятки других расширений, хотя бы новомодный TPU чего стоит. Который ни GPU и VPU, хотя и похож и на одно и на другое.



Intel 8086 (в 1980-85 годах известный как iAPX 86/10) — первый 16-битный микропроцессор компании Intel. Разрабатывался с весны 1976 года

авторx86 (англ. Intel 80x86) — архитектура процессора и одноимённый набор команд, впервые реализованные в процессорах компании Intel.

Название образовано от двух цифр, которыми заканчивались названия процессоров Intel ранних моделей — 8086, 80186, 80286 (i286), 80386 (i386), 80486 (i486). За время своего существования набор команд постоянно расширялся, сохраняя совместимость с предыдущими поколениями.

пентиум - это 80586 проц.
Сделано так потому что номер процессора не может быть товарным знаком. Т.е. любая фирма может ссделать проц и назвать 80486. А назвать пентиумом уже не смогут.



OoO, VLIW, SIMD - неконфликтующие понятия.
Один процессор может содержать все. И даже содержа все плюшки, он может работать в линейном режиме так же неплохо. Просто он будет сильно толще. Тот же OoO как я видел по схемам разводки занимает до 75% площади кремния.


Потому что мейнстрим

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

По сути, почему сбер не выбрал эльбрусы
1) дороже интела
2) медленнее интела
Если бы эльбрусы были бы быстрее раз в 10 в определенных популярных у сбера алгоритмах, то даже при стоимости в 20 раз дороже - сбер брал бы эльбрусы и переписывал бы свое ПО.
Но этого не было.
А еще это совместимость.
И это, похоже, ценится больше, чем все остальное.
Именно поэтому андроид сделали на неповоротливой, голодной и небыстрой жабе, а не православных плюсах.


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

Так что успех можно выделить
1) массовость
2) объем существующего ПО
и уж затем
3) линейная скорость, масштабность
4) стоимость кремния
5) простота разработки ПО


Надстройка.
Это нормально.

Делать каждый раз новый проц, не совместимый с предыдущим - мало кому нужно из потребителей.
Поэтому интел вылез на обратной совместимости.


гуглъ говорит что вообще говоря, размер не ограничен, но вот, к примеру, 15 байт
авторSo what is the longest valid 8086 instruction that isn’t boring and evil? One such example that’s 15 bytes long is below.

lock add DWORD PTR ds:[esi+ecx*4+0x12345678],0xefcdab89

If you want to see it in ODA, try these bytes:

67 66 f0 3e 81 84 8e 78 56 34 12 89 ab cd ef

UPD: Хотя другие пишут что не ограничен через префиксы, сама инструкция не больше 15 байт

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


Тот самый арм, который никому оказался не нужен настолько, что армов в мире больше, чем интелов?

п.с.
что подразумевается под большеконечностью?