Здравствуйте, vdimas, Вы писали:
V>Эльбрус — это и есть один сплошной SIMD:
V>- большой файл регистров;
V>- явный параллелизм;
V>- есть векторные инструкции;
Ну всё таки нет. у SIMD есть офигенное преимущество — single instruction. То есть тайминг всей команды одинаковый. Не бывает так, что пять блоков уже вычислились, а три ещё тупят.

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

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

V>SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
Чего там высокоуровневого? FMADD?
V>Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.
Эффективнее — это если удалось автовекторизовать цепочку вычислений, причём так, чтобы в SIMD варианте такой комбинации не нашлось.
V>Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения.
Взамен давая серъёзные преимущества.
V>ИМХО, сочетание двух подходов может выстрелить, но это дело даже не следующей версии Эльбруса.

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

V>Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))
Для начала надо столько, чтобы они взлетели. Влиять на отрасль — это уже дальний прицел.

V>Будет удобно — будут пользоваться.
Ну так облаков как таковых — как грязи. Было бы желание — был бы госклауд, хоть на основе виртуалок, хоть serverless calculations.
Но желания, как видим, никакого нет.

V>В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы.
V>А простое редактирование программы толком не занимает вовсе.
Редактирование программы нужно делать в нормальной IDE. Я, конечно, в целях самодисциплины университетские лабы писал в Notepad.exe, но там и результаты — смешные. Для Эльбруса нужно не это.

V>Тем более, что программы на ЯВУ можно редактировать/отлаживать на любых совместимых линухах, т.е. локально на той же amdx64-архитектуре в операцонке Эльбрус для amd_x64.
V>Речь о принципиальной возможности доступа к железу для целей экспериментов.
Ещё раз: программы в стиле hello world вообще не нуждаются в эльбрусах, ни физических, ни виртуальных.
Если мы хотим, чтобы взлетел Эльбрус (а не освоить денег на поставках в госучреждения не очень нужных им машин), то отлаживаться будет нужно как минимум на эмуляторе, а лучше — на реальной железке.

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

V>Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д.
V>Т.е. вопрос заведомо затратный, но неизбежный.
Это если подходить с позиций превозмогания. А если подходить с позиций грамотного маркетинга, то можно сэкономить на два-три порядка.

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

V>Но будут платить за хостинг сервисов.
Для того, чтобы они платили за хостинг сервисов на эльбрусах, этот хостинг должен им предлагать что-то такое, чего нет на x86.
Например — более быстрый рендер графики, или более быстрый тренинг НС.
Иначе ничего интересного не получится — пользователи тупо уйдут в хостинг на классике. Если вы надеетесь на то, что прогнивший запад тупо зарежет нам поставки процессоров для отечественных облаков, а в облака МС, оракла и амазона мы не попадём из-за проблем с оплатой — то зря. Просто в эмиратах построят пару датацентров, и прекрасно будут получать железки из США, а деньги из РФ.

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

V>Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом.
Бррр. Вы что-то путаете. Что облака делают хорошо — так это деление 16ядерного процессора между 160 "пользователями". Тот параллелизм, который в SIMD или VLIW, тут непригоден.
Чтобы вам это облако стало выгодно, нужно чтобы ваша задача считалась на эльбрусе эффективнее, чем на интеле. Пока что таких задач — исчезаюше мало.
Ровно потому, что людей, умеющих оптимизировать софт под VLIW, единицы штук в мире.

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

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

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

V>Небанальность — тоже неплохой стимул. ))
V>Всегда интересно резвиться в той области, где еще не всё изъезженно.
Конечно. Но для начала нужна возможность. По факту в ВУЗах нет ни железок, ни эмуляторов. Отсюда имеем эти полторы статьи в год по интересующей теме.

V>Мои дети выигрывали хакатоны, но там всегда на ЯВУ, конкретное железо не принципиально.
Хакатон — он про то, про что организовали. Там есть про всё. Есть такие, где ЯВУ непринципиален, а принципиально использование конкретного API. Есть такие, где принципиально использование ограниченного объёма памяти. В общем — целиком зависит от фантазии авторов и поставленных ими целях.

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

V>Почти ежедневно с ними работаю, там хватает особенностей в деле настройки рабочего окружения.
С точки зрения устройства компилятора и академического интереса — несущественные мелочи.

V>Это задача компилятора.
Повторю вопрос: кто напишет компилятор?

V>Ниоткуда, компиляция пойдёт по дефолтной ветке.
Тогда и производительность будет дефолтная.
V>Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.
Спасибо, я в курсе, как работают макросы в С

V>Зачем?
Эмм, чтобы обойти тупость компилятора.
V>Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь.
Я в курсе. Я же уже показывал на коленках интринсик-код, который рвёт SIMD инструкции, предложенные компилятором.
Автовекторизация работает в очень ограниченных, узких случаях. И это — в случае достаточно тупого SIMD, где пространство вариантов выбора ограничено.
V>А у Эльбруса весь код, считай, SIMD.
В том-то и дело. Вот в оракле закопали довольно много труда в автовекторизатор джавы. И что? Выхлоп по-прежнему очень слабый; шаг вправо-влево — и упс, приплыли.
Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.


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

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

V>Но, согласен, для полного цикла разработки нужно или железо или эмулятор.
V>Опенсорсный эмулятор для QEMU разрабатывают прямо сейчас.
Есть ссылки на этот проект?

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


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


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