LVV>>1. Там без проблем работало 256 кил памяти.
N>4MB. Потому что система виртуальной памяти расширяла адрес до 22 бит.
Я работал еще на 18 бит...
N>Но называть "без проблем" метод выглядывания в огромный мир через крошечное окошко — некорректно.
N>Именно после PDP-11, БЭСМ-6 и ещё ряда похожих машин с такой же проблемой — поняли, насколько это неудобно и неэффективно, и стали делать, что виртуальное пространство заведомо больше физического, причём в разы (чтобы можно было ядру, например, дважды уложить весь RAM на виртуальную память, и ещё оставалось место под устройства).
Ну, виртуальная память современного вида была сделана еще в начале 60 годов, насколько помню. Это как раз в pdp было сделано наоборот.

LVV>>В 2007 году прекратили выпуск — когда у Интел только появились 64-битные системы...
N>1. IA64 — это 2001 год. Да, это другая архитектура, но всё-таки у Intel.
N>2. Были AMD, были Sun SPARC, были 64-битные MIPS. Чуть позже догнала IBM с PPC и S/390.
Я имел ввиду, что оси только появились — когда dec уже все закончила.

Здравствуйте, LaptevVV, Вы писали:

LVV>Я работал еще на 18 бит...
Так тут наверно не еще, а у разных моделей семейства по разному.

LVV>Ну, виртуальная память современного вида была сделана еще в начале 60 годов, насколько помню. Это как раз в pdp было сделано наоборот.
Там маленькое адресное пространство по причине 16-битности, потому и наоборот.

Здравствуйте, netch80, Вы писали:

N>Не поможет, пока в качестве памяти используется DRAM.
N>Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же).
N>Пока есть проблема с DRAM — все эти супер-EPIC (VLIW) будут отставать от Atomʼа.
Время открытия строки не имеет никакого отношения к полосе пропускания. Проблема латентности памяти замечательно решается кэшированием. Кстати кэш — это и есть SRAM, вон АМД пихает по 60МБайт на кристалл — и вроде как их чипы не стоят запредельных денег.
Опять же непонятно, какое отношение это всё имеет к VLIW.

N>Разумеется, рекламные бенчмарки будут на синтетических тестах, когда SIMD перерабатывает потоки данных с тщательно рассчитанными тактировкой и предвыборкой — именно такие тесты вам и рисуют (и кролики ведутся), а потом по отзывам тех, кто это реально применял, Эльбрус на обычных действиях с трудом догоняет пень-три.

N>А Intel и AMD тем временем просто спускаются с горы и овладевают всем стадом, догоняя длину конвейера микроопераций до 200 и выше. Они уже на этом вашем VLIW обожглись и повторять не хотят.

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

N>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~
Ты путаешь тёплое с мягким, то есть процессор общего назначения со специализированной архитектурой. Перепроектировать ничего не нужно, ибо суперскалярные архитектуры фундаментально не отличаются от VLIW.

Здравствуйте, netch80, Вы писали:

N>Я таким URL не доверяю и никому не советую, и слово "брехня" относится скорее к ним.
N>Пусть дадут реальную установку полдесятку действительно независимых экспертов, причём за пределами РФ. Тогда и посмотрим.
А кому это надо?

Здравствуйте, Cyberax, Вы писали:

C>Блобы, которые загружаются в CPU — это реализации управления питанием SSM, настройки всяких турбо-режимов и т.п. Процессор прекрасно работает и без них.

A>>Анализ динамического исполнения, для предсказывания переходов, в реальности представляет собой агрессивные спекулятивные исполнения различных веток глубиной в несколько операторов условного перехода. Реализация подобных вещей есть в VLIW, получается она гораздо проще и дешевле.
C>Не получается.

Не SSM, а скорее SMM.
А спекулятивных вычислений в Эльбрусах чуть ли не в разы больше, чем в x86 — предпочитают так, чем условные переходы. Используется совместно с переименованием регистров.

Здравствуйте, netch80, Вы писали:

V>>Как сам думаешь, ~800млн РУБЛЕЙ — это большие расходы на разработку подобного проца и всей обвязки вокруг него?
V>>ИМХО, это сущие копейки.
N>Слишком много неизвестных, чтобы реально сравнивать.

У меня там инсайд, спрашивай. ))

Здравствуйте, Cyberax, Вы писали:

C>Тут вопрос в чём, 20 лет назад своя архитектура имела смысл. Но сейчас есть RISC-V со свободно лицензированными патентами, есть полностью открытые архитектуры MIPS и SPARC с истёкшими патентами и даже x86 уже свободен по большей части (до SSE3).
C>Можно было бы уже раз пять переделать процессор на один из этих вариантов.

1. Это другие ниши.
2. Один из процов (МЦСТ R1000) и так реализует последнюю спецификацию SPARC.

Ну и, кивание на другие архитектуры бессмысленно.
Как показала практика, в конечном итоге всё упирается в цену.
Взять тот же AVR — взялся из ниоткуда, контора-производитель Atmel на середину 90-х тоже никто и ничто — классическая тёмная лошадка.
Затем появились тонны референсных бордов на нём (где самые известные — линейка Ардуино), и проц стал сверхпопулярен.

Здравствуйте, 0xCAFEDEAD, Вы писали:

CAF>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.

Безопасность, "крутая" технология, распил — отметаем.

Ответ прост — легаси. СССР сделали на нем С-300, тогда других вариантов не было. РФ продолжает делать эти зенитные комплексы, но переносить платформу на другую ISA страшно и затратно. Вот и идет валкое развитие и поддержка.

CAF>>Кстати, а вот зачем нужен этот самый Эльбрус? Зачем городить еще одну архитектуру в промышленных масштабах? Ну инженерам то понятно интересно, но это же вряд ли окупится.

N>Безопасность, "крутая" технология, распил — отметаем.

N>Ответ прост — легаси. СССР сделали на нем С-300, тогда других вариантов не было. РФ продолжает делать эти зенитные комплексы, но переносить платформу на другую ISA страшно и затратно. Вот и идет валкое развитие и поддержка.

э2к это середина двухтысячных, т.е. лет на 20 после с-300.

Здравствуйте, a7d3, Вы писали:

A>>>Анализ динамического исполнения, для предсказывания переходов, в реальности представляет собой агрессивные спекулятивные исполнения различных веток глубиной в несколько операторов условного перехода. Реализация подобных вещей есть в VLIW, получается она гораздо проще и дешевле.
C>>Не получается.
A>Не SSM, а скорее SMM.
Да, перепутал ночью.

A>А спекулятивных вычислений в Эльбрусах чуть ли не в разы больше, чем в x86 — предпочитают так, чем условные переходы. Используется совместно с переименованием регистров.
То есть? VLIW со спекуляцией? Это как?

Здравствуйте, koandrew, Вы писали:

N>>Не поможет, пока в качестве памяти используется DRAM.
N>>Или для DRAM надо операцию смены открытой строки ускорить раз в 30 минимум (фантастика на втором этаже (c)), или выбросить каку и переходить на SRAM (ценник умножить на 10, а в первые 5 лет на 20, плотность упаковки разделить на столько же).
N>>Пока есть проблема с DRAM — все эти супер-EPIC (VLIW) будут отставать от Atomʼа.
K> Время открытия строки не имеет никакого отношения к полосе пропускания.

А откуда взялось про полосу пропускания? Сам придумал?

K>Опять же непонятно, какое отношение это всё имеет к VLIW.

Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе.
У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая.
А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.

А если бы процессор сам просто считал связи команд, он мог бы давно выполнить те, что идут следом и никак не завязаны на те, что застряли.
Не зря в последних процессорах конвейер команд дорос до каких-то страшных цифр типа "97 исходных команд, 224 микрооперации".

K> Кстати кэш — это и есть SRAM,

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

K> вон АМД пихает по 60МБайт на кристалл — и вроде как их чипы не стоят запредельных денег.

Да. Только доступ к кэшу такого размера стоит... обычно что-то типа 20-30 тактов. Цифры от Intel, у остальных может быть ещё хуже.

Ну вот и считай — только дошёл до L3, уже считай 20 тактов потерял. А на оперативку — ещё больше.

K> Проблема латентности памяти замечательно решается кэшированием.

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

N>>Осталось собрать 100500 рот сильных программистов, которые перепроектируют весь софт на SIMD... OH SHI~
K> Ты путаешь тёплое с мягким, то есть процессор общего назначения со специализированной архитектурой.

Я не путаю, это тебе так хочется читать.

K> Перепроектировать ничего не нужно, ибо суперскалярные архитектуры фундаментально не отличаются от VLIW.

Какие-то "суперскалярные архитектуры" от теоретического VLIW где-то на Марсе — может, и не отличаются. Но я о них тут не говорю.
А вот out-of-order суперскалярность и EPIC несовместимы на уровне принципов.

Здравствуйте, Gt_, Вы писали:

N>>Конечно, отзывы должны быть реальные, а не из заведомо агитационного источника, и чтобы тестеров было несколько и они имели опыт поиска спрятанных граблей. По вашей ссылке же информации около нуля и повторить её нереально (и не только из-за закрытости железа).
N>>Ваше "макнули" и "украинское" как раз показывает отсутствие аргументов у вас.

Gt_>но согласись, мой аргумент с реальным тестом заметно весомей твоего наброса "по отзывам тех, кто это реально применял" (тм)

Не-а. Потому что нет реального теста. Есть странная писулька от агит-сайта, которая даже на уровне теста содержит <1/10 от того, что должно быть.

Представь себе, что ты даёшь железку на Эльбрусе на тест, например, команде тестов с какого-нибудь overclockers.ru, phoronix.com, 3dnews.ru, IXBT.
Да они его со всех сторон оближут и протестируют всё, что можно. Там не будет одной несчастной программы (ладно, двух, обе очень специальные и из одной области), которая ещё непонятно почему выбрана и как собрана. Только в явных задачах на производительность будет минимум десяток разных тестов, а лучше два. Linpack, ffmpeg, zip/unzip, 7z параллельный... Будут тесты чего-то нелёгкого поверх scipy, pandas и аналогов. Будет подсчитана какая-нибудь несложная нейросетка на полсуток расчёта, и сравнено, тот же результат расчёта, или отличается (что покажет на тонкие различия в реализации плавучки).
И, разумеется, будет проверка скорости на уровне "сколько грузится ОС", "сколько выполняется какой-нибудь find /usr/lib | wc" и т.п.
Для каждой софтины будет проверено несколько вариантов компиляции (как минимум, с базовой оптимизацией, с максимизацией скорости и минимизацией объёма).
Будет взят компилятор, измерена его работа (а это очень серьёзно — специфика GCC, Clang такова, что там огромное количество нечислового манипулирования мелкими порциями данных, развесистый доступ по ссылкам...), в разных режимах оптимизации. Будут указаны размеры исполняемых файлов, библиотек, проанализировано, на что потрачены основные ресурсы, какое соотношение объёмов служебных частей (типа прологов/эпилогов функций) и основных, не видно ли каких-то тупых ляпов в коде, насколько эффективны распределения регистров и т.п.
Я намеренно всё это писал только по памяти, профессиональный сравниватель с ходу может этот список как минимум в 2 раза толще написать посреди ночи с закрытыми глазами.

И где это по ссылке? Ах да, два пакета газовой динамики (причём почему газовой динамики и почему выбраны именно эти два?), причём даже не указано, как сравнивались результаты расчётов (может, там в выходных данных вообще ничего похожего на правду). Агитка — она и есть агитка, и пригодна только для сельского туалета.

N>>Частично оно Spectre подвержено, но это уже не Meltdown (который был самой тяжёлой формой).
Gt_>этих форм миллион, еще один вид — foreshadow. при этом у ibm power та же фигня. когда им сбоку присобачат защиту памяти на подобии тагов эльбруса разрыв еще сократиться.

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

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, a7d3, Вы писали:

A>>А спекулятивных вычислений в Эльбрусах чуть ли не в разы больше, чем в x86 — предпочитают так, чем условные переходы. Используется совместно с переименованием регистров.
C>То есть? VLIW со спекуляцией? Это как?

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

Здравствуйте, netch80, Вы писали:

N>А вот out-of-order суперскалярность и EPIC несовместимы на уровне принципов.

Можно подумать нет реордеринга на этапе компиляции широких инструкций VLIW/EPIC.
Т.е. весь тот out-of-order, что делается у x86 в режиме исполнения, в случае VLIW выполняется компилятором. И в x86 и в VLIW это все дает множество микроинструкций на выходе, но вот у компилятора времени ощутимо больше на более глубокий анализ кода, соответственно, окно анализа шире.

Если же совсем утрировано, то load'ы поднимаются наверх, а store сдигаются вниз. Если промахнулись по взаимозависимостям, то в Эльбрусах включается «компенсирующий код».

N>Не-а. Потому что нет реального теста. Есть странная писулька от агит-сайта, которая даже на уровне теста содержит <1/10 от того, что должно быть.

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

N>Теги в стиле Эльбруса как раз ничего не стоят по сравнению с общими затратами на выборку и интерпретацию.
N>А насколько Эльбрус подвержен всему Meltdown-like семейству, опять же, тебе не скажут.

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

N>Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе.
N>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая.
N>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.

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

Здравствуйте, Gt_, Вы писали:


N>>Самое прямое. Только не к VLIW в целом, а к EPIC, который в Эльбрусе.
N>>У тебя пачка команд (в его терминах — "широкая команда"), которую надо выполнить, прежде чем приступать к следующей. Процессор не имеет права и не будет исполнять следующую ШК, пока не закончена предыдущая.
N>>А теперь у тебя одна команда из предыдущей ШК ждёт чего-то из оперативки, в кэше данных нет. Всё, все встали, даже те, кому давно ничего не нужно, ждут одного отставшего.

Gt_>булшит. во первых э2к не просто выполняет команды спекулятивно, он выполнят несколько спекулятивных веток одновременно. кроме этого компилятор положит в префеч патерн необходимых данных сильно раньше, чем дойдет до исполнения ШК. компилятор заранее знает все, что может понадобится.

А ты не работал там случаем?

Здравствуйте, a7d3, Вы писали:

C>>То есть? VLIW со спекуляцией? Это как?
A>Технически никакой сложности — считать две-три ветки в рамках одной длинной инструкции разными микрокомандами.
VLIW на то и VLIW, что имеет очень длинные инструкции. Для спекуляции их надо будет разбирать на микроинструкции, планировать их и т.д.

Нет, можно конечно. Но зачем??

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

CAF>>>Эльбрус существует в промышленных масштабах?
W>>Интел с аналогичной архитектурой.
CAF>IA-64 ? так ее и закрыли, проект скорее всего не окупился. Зачем еще раз так делать?
IA-64 навернулся потому что ему была подложена свинья в виде AMD64
То есть технологию делали из расчета грядущего перехода с x86, на это рассчитывали и технари и что наверно важнее — бизнесменеджмент. И они как изначально таргетировали IA64 как неизбежность для своего уже имеющегося рынка, и исходя из этого планировали свои бизнес процессы, и проявили стандартную для большой корпорации неповоротливость когда внезапно выскочил конкурент в виде AMD64.

Здравствуйте, ononim, Вы писали:

CAF>>>>Эльбрус существует в промышленных масштабах?
W>>>Интел с аналогичной архитектурой.
CAF>>IA-64 ? так ее и закрыли, проект скорее всего не окупился. Зачем еще раз так делать?
O>IA-64 навернулся потому что ему была подложена свинья в виде AMD64
O>То есть технологию делали из расчета грядущего перехода с x86, на это рассчитывали и технари и что наверно важнее — бизнесменеджмент. И они как изначально таргетировали IA64 как неизбежность для своего уже имеющегося рынка, и исходя из этого планировали свои бизнес процессы, и проявили стандартную для большой корпорации неповоротливость когда внезапно выскочил конкурент в виде AMD64.

Не совсем. Во время Merced, на конец 90-х интел-совместимые x86-процессоры делали и Cyrix, и AMD, весьма успешно. И хотелось интеловцам такой процессор, чтобы и 64-битный и конкуренты не смогли повторить. А рынок посмотрел на стоимость интелевского решения и сказал, что уж лучше инициатива x86_64, оно же Amd64. Отторжение рынком Merced произошло еще на этапе идей и начала производства этого железа в кристаллах, из-за попыток монополизировать сектор.