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

V>>В качестве числодробилки хорошо работает, ИИ, на больших циклах типа GC Mark-and-Sweep.
V>>Т.е. где не очень много ветвлений, но много вычислений.
V>>Задачи подобного плана самые нагрузочные сегодня.
S>Для таких задач ещё лучше работает SIMD.

Эльбрус — это и есть один сплошной SIMD:
— большой файл регистров;
— явный параллелизм;
— есть векторные инструкции;

Но параллелизм операций в Эльбрусе выше, чем у самых последних AVX, поэтому архитектурно обычный SIMD сходу сливает.
Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат:
https://habr.com/ru/company/icl_services/blog/558564/

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

SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.

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


S>И для него гораздо проще строить компилятор.

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


V>>Нужно железо. Много.
S>Не обязательно много.

По мне сотни тысяч — это достаточно много.
Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))


V>>В идеале и вовсе облако — с виртуализацией всё ОК с версии проца 16С, т.е. имеющийся облачный софт поверх KVM работает.
S>Да, тоже хороший вариант. Но он всего лишь умножает количество машин на коэффициент оверкоммита.

Ну да, поэтому не миллионы, как если бы персоналок, а сотни тыщ в облаках.


S>Ну, и для более-менее массовости всё же нужно выводить это за пределы лабораторной сетки. Современные реальные студенты разработку ведут не в терминальном классе, а на личных машинах.

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


S>Ограничить их только X-терминалами к университетским компьютерам — не шибко хорошая идея. Только на нашем факультете обучается около 700 человек.
S>Ставить 70 хостов выглядит дороговато — тем более, что собственно исполнение/тестирование программы занимает обычно смешное время, и прекрасно работает через CI/CD системы.

В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы.
А простое редактирование программы толком не занимает вовсе.
Тем более, что программы на ЯВУ можно редактировать/отлаживать на любых совместимых линухах, т.е. локально на той же amdx64-архитектуре в операцонке Эльбрус для amd_x64.
Речь о принципиальной возможности доступа к железу для целей экспериментов.


S>>>Целевой аудитории нужен софт, а не железки.
V>>Необходимая целевая аудитория на данном этапе — потенциальные программеры.
S>Вы смотрите на полшага вперёд.

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


S>Целевая аудитория — это никакие не программеры. Программеры не будут заносить производителю столько денег, сколько нужно.

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

Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д.
Т.е. вопрос заведомо затратный, но неизбежный.


S>Их заносят конечные пользователи. Пользователи заносят деньги в обмен на пользу (однокоренные слова неслучайны).

Пользователями современного топового железа в основном выступают облака.
Современный мир крутится вокруг сервисов.
Собсно, банальности...


S>Пользователи не будут платить деньги за фикции типа "импортозамещение" или "суверенитет" (те, которые будут — тоже есть, но это тупиково-распилочное направление, нам оно неинтересно).

Но будут платить за хостинг сервисов.


S>За что они могут платить? За софт, которого а) нету на конкурентах (примеры можно рассмотреть в мире игровых консолей — см. тж. "эксклюзивы") либо б) работает лучше, чем на конкурентах.

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


S>За то, чтобы исполнять ровно такой же софт, как на конкурентах, чутка медленнее и существенно дороже, чем на конкурентах, пользователи платить не будут. Увы.

Ес-но, если дороже.
А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро.


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

ИМХО, из экосистемы бесполезно пытаться выкидывать отдельные элементы или пытаться рассуждать о сравнительной важности отдельных элементов.


V>>Причём, линукс-программерам традиционно пофик на железо, они не на асме пишут.
S>Эмм, линукс-программеры в широком смысле тут не очень релевантны. Они не дают вклада в популяризацию платформы — потому что их софт так и будет работать чутка медленнее, чем на интеле, за в разы больше денег, чем за интел.

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


S>Интересны разработчики компиляторов. А они как раз "пишут на асме", в некотором смысле.

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

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


V>>При наличии железа, на эту тему пойдут курсовые, дипломные и кандидатские, впрочем, ты и сам эту кухню знаешь.
S>Чтобы ускорить процесс, железо в виде станций, серверов, и облаков, нужно ещё дополнить мотивирующим стимулом.

Небанальность — тоже неплохой стимул. ))
Всегда интересно резвиться в той области, где еще не всё изъезженно.


S>Те самые конкурсы и хакатоны, про которые я тут писал.

Мои дети выигрывали хакатоны, но там всегда на ЯВУ, конкретное железо не принципиально.


S>Вот тогда — да, попрут и курсовые, и дипломные, и кандидатские.

Например, в такой отсталой в деле IT стране, как РФ, разработаны одни из лучших систем в мире в области ИИ.
И в этой области оно продолжает набирать обороты.
Т.е., академический подход в научноёмких областях себя оправдывает.
Тут нам и карты в руки.


S>Это всё не о том. Эта операционка никак не поможет, скажем, напилить дотнетный джит в систему команд Эльбруса.

Эээ...
Ты думал, джит для ARM писали на ARM-ах? ))
Для задач навроде разработки джита нужен вменяемый эмулятор и кросс-компиляция.


S>"Архитектурно-независимая часть" тут не заслуживает упоминания — линукс на то и линукс, что студент можнт освоить произвольный дистрибутив на своём любимом HP или макбуке, а потом сесть за совершенно другую архитектуру и не путаться, где тут grep, а где cat.

Таки, особенности есть в каждой архитектуре Linux.
Семейства Debian, RHEL или openSUSE — это как разные вселенные...
Почти ежедневно с ними работаю, там хватает особенностей в деле настройки рабочего окружения.


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

Верно.
Именно поэтому за основу Эльбрус ОС было взято самое массовое семейство — Debian.
Хотя еще есть достаточно уникальная, но популярная у нас сборка ALT, они тоже поддерживают Эльбрус.


S>>>Это телега впереди лошади. Чипы сами по себе никому не нужны. Нужен софт, который решает прикладные задачи.
V>>В экосистеме линухов почти весь софт доступен в исходниках.
S>И? Это как-то магически сделает существующий софт дружелюбным к VLIW?

Это задача компилятора.


S>Откуда в исходниках какого-нибудь OpenCV возьмутся платформенно-специфичные ветки для Эльбруса

Ниоткуда, компиляция пойдёт по дефолтной ветке.
Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.


S>Откуда в библиотеках GCC возьмутся интринсики Эльбруса, чтобы разработчики могли внести их в исходники OpenCV?

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


S>Чудес-то не бывает.
V>>Продолжайте наблюдения. ))
S>Да уж не первый год в продакт менеджменте работаю.

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


V>>Даташиты процов открыты.
V>>Но без реального железа эти даташиты мало кому интересны.
S>Стоило бы начать хотя бы с эмулятора. Ну, чтобы понять, корректен ли вообще порождаемый джитом код, или нет.

Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты.
Но, согласен, для полного цикла разработки нужно или железо или эмулятор.
Внутренний эмулятор МЦСТ для этих нужд непригоден, он для внутренних целей разработки.
Опенсорсный эмулятор для QEMU разрабатывают прямо сейчас.

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


V>>Ну вот я низкоуровневый программер, мне очень даже интересно погонять некоторые вещи, типа user-space TCP-стека, посмотреть как работают аналоги RDTSC — в прошлых процах из мира x86 (но до сих пор часто встречающихся) были проблемы с этой операцией, которые я в своём коде должен обыгрывать. Без наличия реальной железки я ничего толком не посмотрю. Что мне дадут очередные "просто Линуха" без низкого уровня? Я и так каждый день на них время трачу, мне это не интересно.

S>Ну, в идеале — конечно да. Реальная железка должна стоять в нескольких экземплярах в каждом IT-вузе. Хотя бы — в топ-10 из этих ВУЗов.
S>Но на практике вместо этого у нас — вечные новости из будущего.

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


S>Отсюда и мой скепсис.

И мой многолетний, хотя одному из сыновей я дал год назад совет продолжать работать в МЦСТ (разрабатывает этот проц), т.к. достойная реализация этой темы просто неизбежна, у РФ нет другого выхода. И этот рынок труда явно не натоптан, там не тесно, таких спецов в стране напересчёт.

Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD.
Ну вот сейчас зашевелятся.