Сообщение Re[18]: .Net на эльбрусах от 16.08.2022 0:36
Изменено 16.08.2022 1:00 vdimas
Re[18]: .Net на эльбрусах
Здравствуйте, Sinclair, Вы писали:
V>>Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат:
V>>https://habr.com/ru/company/icl_services/blog/558564/
S>Это значит, что в кодеген компилятора встроили автовекторизацию простых циклов.
Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
Забудь само слово "автовекторизация" когда речь про VLIW.
V>>В общем, у Эльбруса проблема не в архитектуре, а в технологиях производства проца.
S>Ну, так я понял, что идея к тому и сводится, чтобы недостатки технологии обойти достоинствами архитектуры.
В том числе.
Причём, обойти в чувствительной к быстродействию вычислений области — обработке больших массивов данных в режиме жесткого реалтайм.
Например:
http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
V>>SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
S>Чего там высокоуровневого?
Это как вызов подпрограммы над определёнными структурами данных.
V>>Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.
S>Эффективнее — это если удалось автовекторизовать цепочку вычислений, причём так, чтобы в SIMD варианте такой комбинации не нашлось.
"Простая компиляция под Эльбрус" — это и есть твоя "автовекторизация".
Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
V>>Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения.
S>Взамен давая серъёзные преимущества.
Это в теории.
На деле всё плохо:
— у железа ограничено время принятия решения, в отличие от компилятора;
— величина окна просмотра логики ограничена;
— кол-во меток для кеширования ветвлений ограничено, т.е. в достаточно большом цикле никаких верных предсказаний ветвлений может и не быть (даже если цикл мал в исходнике, но вызывает, допустим, достаточно большие подпрограммы).
В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
Они выдают старое за новое.
Комбинируют новые подсистемы графики, контроллеров RAM, слабые ядра с сильными и т.д.
Т.е. делают вид, что что-то делают.
Но не делают ни-че-го.
Зеро.
Тупик происходит уже 10-й год.
V>>Зато намного сложнее писать программы целевым программистам, пытаясь выразить вычисления через весьма ограниченный в разнообразии компромисс-полуускоритель в виде SIMD в традиционных камнях.
S>Это если вручную.
Это даже компиляторами, потому что набор ср-в узок и соблюдённые требования по упакованности данных не так просто автоматически распознать.
Это почему до сих пор (позорище!) инстинстики над SIMD более чем популярны для ручного анонирования — из-за тупости компиляторов.
S>Но вручную и VLIW выписывать не шибко удобнее.
Вручную для VLIW и не требуется.
V>>Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))
S>Для начала надо столько, чтобы они взлетели. Влиять на отрасль — это уже дальний прицел.
Любая техническая экосистема — это система с обратной положительной связью.
V>>Будет удобно — будут пользоваться.
S>Ну так облаков как таковых — как грязи. Было бы желание — был бы госклауд, хоть на основе виртуалок, хоть serverless calculations.
Это всё планировали когда-то на основе Эльбрус 32c, там поддержка LDDR5 и прочие вкусности:
S>Но желания, как видим, никакого нет.
Нет железа.
Имеющиеся 8с, как ни крути, морально устарели.
Нужно было давать пинка разработке 16с, но чего-то телились почти 5 лет еле-еле.
Банальное недофинансирование.
Разворачивать инфраструктуру на 16с можно было бы уже смело давно, будь они в достаточном кол-ве, а там бы поспел и топчик 32с.
V>>В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы.
V>>А простое редактирование программы толком не занимает вовсе.
S>Редактирование программы нужно делать в нормальной IDE.
Любой ноут справляется с любой "нормальной IDE", если это не солюшен на 50+ проектов.
Один-два средних размера проекта в солюшене — ни о чём.
S>Я, конечно, в целях самодисциплины университетские лабы писал в Notepad.exe, но там и результаты — смешные. Для Эльбруса нужно не это.
Эльбрусу пофик, это ж Linux.
Например, сетевой диск монтируется локально как родной, IDE может исполняться локально, а компиляться и отлаживать код может удалённо и еще сверху миллион комбинаторных комбинаций конфигурирования.
Например, особой разницы локальной и удалённой отладки в линухах нет, в обоих случаях идёт общение с отладчиком-серисом одинаковым образом.
V>>Речь о принципиальной возможности доступа к железу для целей экспериментов.
S>Ещё раз: программы в стиле hello world вообще не нуждаются в эльбрусах, ни физических, ни виртуальных.
Программисты зато нуждаются.
У нас же нет аппарата принуждения инженеров.
Мы можем только сделать людям любопытно и смотреть, что из этого выйдет.
S>Если мы хотим, чтобы взлетел Эльбрус (а не освоить денег на поставках в госучреждения не очень нужных им машин), то отлаживаться будет нужно как минимум на эмуляторе, а лучше — на реальной железке.
На реальном железе лучше, конечно.
V>>О коммерческой выгодности проекта в ближайшие годы или десятилетия говорить заведомо бесполезно, ИМХО, — у IT-отрасли слишком большая инерция, слишком большие и длительные вложения требуется, чтобы растолкать какую-нибудь новую тему.
S>Очень малая у неё инерция.
Хотелось бы примеров.
Потому что история показывает ровно обратное.
S>Облака выстрелили в считанные годы — вот только что все строят свои собственные датацентры, и вот уже все ррраз! и уехали в ажур/aws.
Наоборот, линуховоды чуть ли не десяток лет паравиртуализацию в KVM разрабатывали.
И как только допилили до работоспособности — ррраз, и уехало.
Десяток лет, Карл!
А на деле всё-равно не справились.
Первый вменяемый гипервизор с паравиртуализацией Xen для линухов был разработан той самой академкой, а не традиционным программистским сообществом.
Аспирантура психанула, не иначе! ))
Самое забавное, что в Windows аналогичные технологии были готовы лет на ~8 раньше, но жадность фраера сгубила.
Все облака давно могли бы крутиться на виндах еще до середины нулевых... но тогда был слишком триумф Windows, поэтому они гордо просрали все полимеры.
Вот тебе вокруг только одних облаков чудовищная инерция:
— долгая неспособность оперативно разработать вменяемые технологии виртуализации для Linux;
— долгое игнорирование отраслью качественных имеющихся решений на основе операционок MS из-за ценовой политики.
Время... деньги...
S>Или там — вот у нас суперновый чип A1
Архитектура ARM зато не суперновая.
S>экзотический язык программирования и среда разработки
Objective-C экзотический? Ты с какой Луны к нам свалился, что ты делаешь на этом сайте? ))
На моей памяти — весьма популярный язык, т.к. C++ еще не был вменяемым в те годы.
Под маками на Objective-C написано чуть более чем всё с 80-х, когда Джобс основал NeXT, а потом принёс эти наработки в 90-х в Apple.
Оболочка Mac OS X — это переименованная NeXTSTEP.
Cocoa — это перелицованная GUI-среда разработки оттуда же.
Для справки — многие игры под DOS (взять тот же Doom) разрабатывались в среде NeXT.
S>и хооп!
Да не было никакого хооп, что за буйные фантазии? ))
Был iPod + iTunes с 2001-го, потом Apple TV.
В общем, инфраструктура платного распространения ПО и контента не взялась с потолка, а долго рожалась и отлаживалась.
S>сотни тысяч программ в аппсторе, миллиарды оборота.
Ты подумал, что это написано с 0-ля или как понимать этот тон?
Под маками, в отличие от бесконечного зоопарка GUI виндов и линухов, альтернативных вариантов GUI нет.
С одной стороны, никак не сделать шаг вправо-влево.
С другой стороны, твой код не протухает десятилетиями.
Я допускаю, что это всё было экзотикой для тебя лично, т.к. ты в мак-экосистеме не вращался до покупки айфона/айпода или чего там...
Но какой смысл выдавать свои даже не наблюдения, а сугубо эмоциональные ощущения за "аргмент"? ))
Мне приходилось упражняться на Objective-C всю дорогу в 90-х.
Да и не только мне.
Просто вы, дельфийы, джависты, 1С-ники и прочие дотнетчики с точки зрения нормального разработчика были как пришельцы, наши "миры" ранее особо не пересекались.
Нам были неинтересны ваши наработки, а вы принципиально были не способны выполнять нашу работу.
Вы даже плохо представляли, в чём она заключается, какие задачи решаются.
V>>Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д.
V>>Т.е. вопрос заведомо затратный, но неизбежный.
S>Это если подходить с позиций превозмогания. А если подходить с позиций грамотного маркетинга, то можно сэкономить на два-три порядка.
Спасибо, прореагировал в голос.
И отчего же Интел была вынуждена похоронить многомиллиардный Itanium?
Какая-то блоха AMD, которая изначально стырила прям в бинаре архитектуру чипа 8080, спустя 20 лет помножила на ноль ВСЕ вложения Интел в Itanium.
Плохие маркетологи были в Intel? — не думаю.
Думаю, что рынок не всегда делает лучший выбор.
Думаю, что люди предпочитают меньше платить здесь и сейчас, и пофик, что за это они расплатятся лишней платой и завтра, и послезавтра, и всегда.
Не помню точных цифр, не хочу врать... Но как-то попадалось на глаза исследования, утверждалось, что из-за неудачных принятых когда-то решений (которые уже не переиграть) отрасль IT потребляет лишние десятки миллиардов ежегодно. Т.е. IT могло бы обходиться человечеству дешевле и эффективней.
V>>Пользователями современного топового железа в основном выступают облака.
S>Облака тоже не являются никакой самоценностью. Облака — всего лишь инструмент. Они востребованы настолько, насколько востребован софт, крутящийся в облаках.
Ключевое было про топовость.
Эльбрус имеет архитектуру суперкомпьютера, таки.
Так-то есть начальные процы, типа К1891ВМ068.
V>>Но будут платить за хостинг сервисов.
S>Для того, чтобы они платили за хостинг сервисов на эльбрусах, этот хостинг должен им предлагать что-то такое, чего нет на x86.
Надёжность подойдёт?
S>Например — более быстрый рендер графики, или более быстрый тренинг НС.
Или больше безопасности.
S>Иначе ничего интересного не получится — пользователи тупо уйдут в хостинг на классике.
Т.е., наблюдается забавная тенденция — новички валят на облака ажура или aws, а потом, поняв, что к чему, потихоньку валят на альтернативы.
В Азии, к примеру, растут десятки своих крупных игроков и цены там приятней.
Сравнивать доли облачных вычислений надо не в долларах, а в объёмах вычислений.
S>Если вы надеетесь на то, что прогнивший запад тупо зарежет нам поставки процессоров для отечественных облаков, а в облака МС, оракла и амазона мы не попадём из-за проблем с оплатой — то зря. Просто в эмиратах построят пару датацентров, и прекрасно будут получать железки из США, а деньги из РФ.
Странные у тебя фрмулировки насчёт "надеемся".
По факту сложности с оплатой там давно, сложности с железом нам достоверно обещали.
Никакие компромиссные варианты (а они будут, ес-но, на каком-то этапе) не интересуют в стратегическом плане.
От ненадёжных контрагентов придётся уходить.
Да и, учитывая современные ср-ва разворачивания и управления облаками, нет более никаких причин держатся за единицы монополистов:
https://www.cnews.ru/reviews/oblachnye_servisy_2022/interviews/mihail_solovev
https://e.huawei.com/ru/solutions/industries/isp/full-stack-cloud-services
S>В итоге мы опять упираемся в академические исследования и фундаментальные разработки.
И это прекрасно.
V>>Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом.
S>Бррр. Вы что-то путаете. Что облака делают хорошо — так это деление 16ядерного процессора между 160 "пользователями".
Это смотря какими пользователями, какой план/тарифы.
S>Тот параллелизм, который в SIMD или VLIW, тут непригоден.
Я говорил про поточный параллелизм, который не в пересчёте на ядро.
С ядрами в разрабатываемых Эльбрусах всё складывается неплохо — в этой архитектуре делить общую память могут 4 кристалла.
S>Чтобы вам это облако стало выгодно, нужно чтобы ваша задача считалась на эльбрусе эффективнее, чем на интеле.
Такой вариант, что норма прибыли оператора будет заложена в разы меньшая, ты не рассматривал?
V>>Ес-но, если дороже.
V>>А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро.
S>Расскажите про это тем, кто обучает НС.
Я рассказываю это тем, кто всю свою карьеру далёк от эффективных вычислений.
V>>Дотации от гос-ва еще никто не отменял.
S>Но и никто не видел
Эльбрусы делают за счёт минторга, если что.
V>>IT в этом деле как СХ, может быть и убыточным, но позволить отрасли уничтожиться опасно.
S>Жаль, что кроме нас с вами, это мало кто понимает.
Ну еще пара министерств, а так никто.
V>>Плюс VLIW — это хорошее поле именно для академки, там дофига алгоритмов компиляции-оптимизации можно разработать, защитить кучу кандидатских, обложить тысячами дипломных.
V>>Собсно, почему VLIW и не взлетел в мире — слишком большие требования к разработчикам, там околонаучное всё.
V>>Но это и есть наш подход к IT-образованию и он имеет ненулевой шанс "выстрелить".
S>Повторюсь: чтобы он выстрелил, нужны некоторые предварительные шаги. Прямо сейчас, как и в последние 10 лет, я этих шагов не наблюдаю.
Так ты и Objective-C не наблюдал, для тебя это "экзотика", хотя по-факту — обычная экосистема маков.
V>>Это задача компилятора.
S>Повторю вопрос: кто напишет компилятор?
Почему в будущем времени?
Компилятор давно написан и постоянно обновляется.
На сегодня есть полная поддержка стандарта С++14, идёт дальнейшее развитие компилятора.
V>>Ниоткуда, компиляция пойдёт по дефолтной ветке.
S>
Тогда и производительность будет дефолтная.
Это на Интеле будет дефолтная, т.е. с проседанием.
Потому что SIMD — это костыль для убогих технологий прошлой эпохи.
V>>Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.
S>Спасибо, я в курсе, как работают макросы в С
Тогда бы ты не писал то, что писал.
V>>Зачем?
S>Эмм, чтобы обойти тупость компилятора.
Компилятор под amd_x64 тупой не просто так, а потому что автовекторизация в условиях ограничений на лейаут данных — задача не тривиальная.
В отсутствии таких ограничений проблема не существует.
Проблема автовекторизации в С/С++ происходит от того, что данные, которые хранятся в памяти, вынуждены сохранять свой лейаут.
Связано это с независимой компиляцией единиц трансляции, т.е. различные единицы трансляции должны одинаково интерпретировать один и тот же тип в памяти.
Это отрубает целый класс оптимизаций, связанных с переупорядочиванием представления данных в памяти.
Частично с этой проблемой неплохо борются архитектуры с большим файлом регистров и компиляторы, качественно проводящие escape-анализ, т.к. при обнаружении локальности данных (в регистрах или на стеке), руки у компилятора становятся развязаны.
Особенность компилятора под Эльбрус в том, что он лучше оригинального gcc умеет выполнять полную оптимизацию, т.е. использовать технику LTO, т.е. в том числе "замыкать" на уровне бинарного модуля видимость данных и преобразовывать их для достижения лучшей производительности. С включённой техникой LTO одни и те же тесты порой выполняются до 5 раз быстрее — инлайн для VLIW рулит. Неплохие результаты показывается так же PGO. Неплохие в сравнении с традиционными архитектурами.
V>>Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь.
S>Я в курсе. Я же уже показывал на коленках интринсик-код, который рвёт SIMD инструкции, предложенные компилятором.
Что лишь демонстрирует тупиковость этого подхода для классических архитектур.
S>Автовекторизация работает в очень ограниченных, узких случаях. И это — в случае достаточно тупого SIMD, где пространство вариантов выбора ограничено.
Верно. Проблема в ограничениях SIMD-расширений.
V>>А у Эльбруса весь код, считай, SIMD.
S>В том-то и дело.
Дело в меньших ограничениях.
Вернее, в полном отсутствии ограничений.
S>Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.
Эхх...
Потрать как-нить пол-часа:
http://www.mathnet.ru/links/338dc4eb1150dfc71b46111cd7cb9410/itvs662.pdf
И в списке литературы тоже не скучно.
Сорри, но ты здесь вещаешь истины из разряда "не стоит клеить щит из сырой древесины".
V>>Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты.
S> Для этого нужно знать, какие байты корректны, а какие — нет.
Спецификации доступны уже пару лет как, технику тоже давно можно купить.
Разработка джит-компилятора — это несколько слоёв иерархии ТЗ-решение, где для 99% работы целевая архитектура не требуется вовсе.
Курить принципы работы оптимизирующих компиляторов.
V>>Изначально был доступен противоположный эмулятор... вернее, даже не эмулятор, а джиттинг x86/x64 кода в свою систему команд.
S>Он практически бесполезен для обсуждаемой задачи.
Наоборот, стоит задача генерить эффективный VLIW-код и динамический джит с x86/x64 показывает, что такие задачи мы умеем решать на самом что ни на есть мировом уровне.
Ты ведь должен понимать, что это край современного прогресса. ))
Сколько там лет и лярдов потрачено на джит-компиляторы подо всякие байт-коды дотнета, джавы или v8-JS?
Эти задачи выполняются мировыми лидерами.
А тут страна-бензоколонка на удивление легко и непринуждённо справляется с задачами такого рода.
V>>Ну вот сейчас зашевелятся, бо карты открыты — Запад намерен не то, что дружить, а хотя бы просто адекватно с нами общаться только если мы выглядим слабыми.
S>Я вот этого вот "сейчас зашевелятся" жду с 2008.
А я жду с 2014-го.
До этого так, просто пошипели малость...
S>Продолжаем принимать новости из будущего.
Ну... ты просто малость в другой реальности всю карьеру обитаешь.
V>>Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD.
V>>Ну вот сейчас зашевелятся.
S> Ждём с нетерпением.
Де-факто уже в процессе.
Происходит перенос на фабрики Китая.
Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии.
Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус.
V>>Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат:
V>>https://habr.com/ru/company/icl_services/blog/558564/
S>Это значит, что в кодеген компилятора встроили автовекторизацию простых циклов.
Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
Забудь само слово "автовекторизация" когда речь про VLIW.
V>>В общем, у Эльбруса проблема не в архитектуре, а в технологиях производства проца.
S>Ну, так я понял, что идея к тому и сводится, чтобы недостатки технологии обойти достоинствами архитектуры.
В том числе.
Причём, обойти в чувствительной к быстродействию вычислений области — обработке больших массивов данных в режиме жесткого реалтайм.
Например:
http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
V>>SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
S>Чего там высокоуровневого?
Это как вызов подпрограммы над определёнными структурами данных.
V>>Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.
S>Эффективнее — это если удалось автовекторизовать цепочку вычислений, причём так, чтобы в SIMD варианте такой комбинации не нашлось.
"Простая компиляция под Эльбрус" — это и есть твоя "автовекторизация".
Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
V>>Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения.
S>Взамен давая серъёзные преимущества.
Это в теории.
На деле всё плохо:
— у железа ограничено время принятия решения, в отличие от компилятора;
— величина окна просмотра логики ограничена;
— кол-во меток для кеширования ветвлений ограничено, т.е. в достаточно большом цикле никаких верных предсказаний ветвлений может и не быть (даже если цикл мал в исходнике, но вызывает, допустим, достаточно большие подпрограммы).
В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
Они выдают старое за новое.
Комбинируют новые подсистемы графики, контроллеров RAM, слабые ядра с сильными и т.д.
Т.е. делают вид, что что-то делают.
Но не делают ни-че-го.
Зеро.
Тупик происходит уже 10-й год.
V>>Зато намного сложнее писать программы целевым программистам, пытаясь выразить вычисления через весьма ограниченный в разнообразии компромисс-полуускоритель в виде SIMD в традиционных камнях.
S>Это если вручную.
Это даже компиляторами, потому что набор ср-в узок и соблюдённые требования по упакованности данных не так просто автоматически распознать.
Это почему до сих пор (позорище!) инстинстики над SIMD более чем популярны для ручного анонирования — из-за тупости компиляторов.
S>Но вручную и VLIW выписывать не шибко удобнее.
Вручную для VLIW и не требуется.
V>>Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))
S>Для начала надо столько, чтобы они взлетели. Влиять на отрасль — это уже дальний прицел.
Любая техническая экосистема — это система с обратной положительной связью.
V>>Будет удобно — будут пользоваться.
S>Ну так облаков как таковых — как грязи. Было бы желание — был бы госклауд, хоть на основе виртуалок, хоть serverless calculations.
Это всё планировали когда-то на основе Эльбрус 32c, там поддержка LDDR5 и прочие вкусности:
Например, новая память Samsung LPDDR5 6400 может отправлять 51,2 гигабайта данных или примерно 14 видеофайлов в формате Full HD (3,7 ГБ каждый) за секунду.
Планируемые характеристики микропроцессора «Эльбрус-32С»:
производительность — до 3 / 1,5 Тфлоп/с;
количество ядер — 32;
Тактовая частота — 2,5 ГГц;
объем кэш-памяти (L2+L3) — 64 МБ;
ОЗУ — тип DDR5, 170 ГБайт/с, не менее 6 каналов, не менее 2 Тбайт;
интерфейсы: 64 линии PCIe 5.0, Ethernet 10/25/40/50/100 Гбит/с, USB 3.1;
возможность объединения до четырех микропроцессоров на общей памяти;
технология — 7 нм.
S>Но желания, как видим, никакого нет.
Нет железа.
Имеющиеся 8с, как ни крути, морально устарели.
Нужно было давать пинка разработке 16с, но чего-то телились почти 5 лет еле-еле.
Банальное недофинансирование.
Разворачивать инфраструктуру на 16с можно было бы уже смело давно, будь они в достаточном кол-ве, а там бы поспел и топчик 32с.
V>>В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы.
V>>А простое редактирование программы толком не занимает вовсе.
S>Редактирование программы нужно делать в нормальной IDE.
Любой ноут справляется с любой "нормальной IDE", если это не солюшен на 50+ проектов.
Один-два средних размера проекта в солюшене — ни о чём.
S>Я, конечно, в целях самодисциплины университетские лабы писал в Notepad.exe, но там и результаты — смешные. Для Эльбруса нужно не это.
Эльбрусу пофик, это ж Linux.
Например, сетевой диск монтируется локально как родной, IDE может исполняться локально, а компиляться и отлаживать код может удалённо и еще сверху миллион комбинаторных комбинаций конфигурирования.
Например, особой разницы локальной и удалённой отладки в линухах нет, в обоих случаях идёт общение с отладчиком-серисом одинаковым образом.
V>>Речь о принципиальной возможности доступа к железу для целей экспериментов.
S>Ещё раз: программы в стиле hello world вообще не нуждаются в эльбрусах, ни физических, ни виртуальных.
Программисты зато нуждаются.
У нас же нет аппарата принуждения инженеров.
Мы можем только сделать людям любопытно и смотреть, что из этого выйдет.
S>Если мы хотим, чтобы взлетел Эльбрус (а не освоить денег на поставках в госучреждения не очень нужных им машин), то отлаживаться будет нужно как минимум на эмуляторе, а лучше — на реальной железке.
На реальном железе лучше, конечно.
V>>О коммерческой выгодности проекта в ближайшие годы или десятилетия говорить заведомо бесполезно, ИМХО, — у IT-отрасли слишком большая инерция, слишком большие и длительные вложения требуется, чтобы растолкать какую-нибудь новую тему.
S>Очень малая у неё инерция.
Хотелось бы примеров.
Потому что история показывает ровно обратное.
S>Облака выстрелили в считанные годы — вот только что все строят свои собственные датацентры, и вот уже все ррраз! и уехали в ажур/aws.
Наоборот, линуховоды чуть ли не десяток лет паравиртуализацию в KVM разрабатывали.
И как только допилили до работоспособности — ррраз, и уехало.
Десяток лет, Карл!
А на деле всё-равно не справились.
Первый вменяемый гипервизор с паравиртуализацией Xen для линухов был разработан той самой академкой, а не традиционным программистским сообществом.
Аспирантура психанула, не иначе! ))
Самое забавное, что в Windows аналогичные технологии были готовы лет на ~8 раньше, но жадность фраера сгубила.
Все облака давно могли бы крутиться на виндах еще до середины нулевых... но тогда был слишком триумф Windows, поэтому они гордо просрали все полимеры.
Вот тебе вокруг только одних облаков чудовищная инерция:
— долгая неспособность оперативно разработать вменяемые технологии виртуализации для Linux;
— долгое игнорирование отраслью качественных имеющихся решений на основе операционок MS из-за ценовой политики.
Время... деньги...
S>Или там — вот у нас суперновый чип A1
Архитектура ARM зато не суперновая.
Apple Newton или просто Newton — одна из первых серий карманных персональных компьютеров, которая разрабатывалась, производилась и продавалась фирмой Apple Computer. Apple начала разработку платформы в 1987 году и выпустила первые устройства в августе 1993 года.
...
Большинство компьютеров Newton работали на RISC-процессоре ARM 610.
S>экзотический язык программирования и среда разработки
Objective-C экзотический? Ты с какой Луны к нам свалился, что ты делаешь на этом сайте? ))
На моей памяти — весьма популярный язык, т.к. C++ еще не был вменяемым в те годы.
Под маками на Objective-C написано чуть более чем всё с 80-х, когда Джобс основал NeXT, а потом принёс эти наработки в 90-х в Apple.
Оболочка Mac OS X — это переименованная NeXTSTEP.
Cocoa — это перелицованная GUI-среда разработки оттуда же.
Для справки — многие игры под DOS (взять тот же Doom) разрабатывались в среде NeXT.
S>и хооп!
Да не было никакого хооп, что за буйные фантазии? ))
Был iPod + iTunes с 2001-го, потом Apple TV.
В общем, инфраструктура платного распространения ПО и контента не взялась с потолка, а долго рожалась и отлаживалась.
S>сотни тысяч программ в аппсторе, миллиарды оборота.
Ты подумал, что это написано с 0-ля или как понимать этот тон?
Под маками, в отличие от бесконечного зоопарка GUI виндов и линухов, альтернативных вариантов GUI нет.
С одной стороны, никак не сделать шаг вправо-влево.
С другой стороны, твой код не протухает десятилетиями.
Я допускаю, что это всё было экзотикой для тебя лично, т.к. ты в мак-экосистеме не вращался до покупки айфона/айпода или чего там...
Но какой смысл выдавать свои даже не наблюдения, а сугубо эмоциональные ощущения за "аргмент"? ))
Мне приходилось упражняться на Objective-C всю дорогу в 90-х.
Да и не только мне.
Просто вы, дельфийы, джависты, 1С-ники и прочие дотнетчики с точки зрения нормального разработчика были как пришельцы, наши "миры" ранее особо не пересекались.
Нам были неинтересны ваши наработки, а вы принципиально были не способны выполнять нашу работу.
Вы даже плохо представляли, в чём она заключается, какие задачи решаются.
V>>Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д.
V>>Т.е. вопрос заведомо затратный, но неизбежный.
S>Это если подходить с позиций превозмогания. А если подходить с позиций грамотного маркетинга, то можно сэкономить на два-три порядка.
Спасибо, прореагировал в голос.
И отчего же Интел была вынуждена похоронить многомиллиардный Itanium?
Какая-то блоха AMD, которая изначально стырила прям в бинаре архитектуру чипа 8080, спустя 20 лет помножила на ноль ВСЕ вложения Интел в Itanium.
Плохие маркетологи были в Intel? — не думаю.
Думаю, что рынок не всегда делает лучший выбор.
Думаю, что люди предпочитают меньше платить здесь и сейчас, и пофик, что за это они расплатятся лишней платой и завтра, и послезавтра, и всегда.
Не помню точных цифр, не хочу врать... Но как-то попадалось на глаза исследования, утверждалось, что из-за неудачных принятых когда-то решений (которые уже не переиграть) отрасль IT потребляет лишние десятки миллиардов ежегодно. Т.е. IT могло бы обходиться человечеству дешевле и эффективней.
V>>Пользователями современного топового железа в основном выступают облака.
S>Облака тоже не являются никакой самоценностью. Облака — всего лишь инструмент. Они востребованы настолько, насколько востребован софт, крутящийся в облаках.
Ключевое было про топовость.
Эльбрус имеет архитектуру суперкомпьютера, таки.
Так-то есть начальные процы, типа К1891ВМ068.
V>>Но будут платить за хостинг сервисов.
S>Для того, чтобы они платили за хостинг сервисов на эльбрусах, этот хостинг должен им предлагать что-то такое, чего нет на x86.
Надёжность подойдёт?
S>Например — более быстрый рендер графики, или более быстрый тренинг НС.
Или больше безопасности.
S>Иначе ничего интересного не получится — пользователи тупо уйдут в хостинг на классике.
Т.е., наблюдается забавная тенденция — новички валят на облака ажура или aws, а потом, поняв, что к чему, потихоньку валят на альтернативы.
В Азии, к примеру, растут десятки своих крупных игроков и цены там приятней.
Сравнивать доли облачных вычислений надо не в долларах, а в объёмах вычислений.
S>Если вы надеетесь на то, что прогнивший запад тупо зарежет нам поставки процессоров для отечественных облаков, а в облака МС, оракла и амазона мы не попадём из-за проблем с оплатой — то зря. Просто в эмиратах построят пару датацентров, и прекрасно будут получать железки из США, а деньги из РФ.
Странные у тебя фрмулировки насчёт "надеемся".
По факту сложности с оплатой там давно, сложности с железом нам достоверно обещали.
Никакие компромиссные варианты (а они будут, ес-но, на каком-то этапе) не интересуют в стратегическом плане.
От ненадёжных контрагентов придётся уходить.
Да и, учитывая современные ср-ва разворачивания и управления облаками, нет более никаких причин держатся за единицы монополистов:
https://www.cnews.ru/reviews/oblachnye_servisy_2022/interviews/mihail_solovev
https://e.huawei.com/ru/solutions/industries/isp/full-stack-cloud-services
S>В итоге мы опять упираемся в академические исследования и фундаментальные разработки.
И это прекрасно.
V>>Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом.
S>Бррр. Вы что-то путаете. Что облака делают хорошо — так это деление 16ядерного процессора между 160 "пользователями".
Это смотря какими пользователями, какой план/тарифы.
S>Тот параллелизм, который в SIMD или VLIW, тут непригоден.
Я говорил про поточный параллелизм, который не в пересчёте на ядро.
С ядрами в разрабатываемых Эльбрусах всё складывается неплохо — в этой архитектуре делить общую память могут 4 кристалла.
S>Чтобы вам это облако стало выгодно, нужно чтобы ваша задача считалась на эльбрусе эффективнее, чем на интеле.
Такой вариант, что норма прибыли оператора будет заложена в разы меньшая, ты не рассматривал?
V>>Ес-но, если дороже.
V>>А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро.
S>Расскажите про это тем, кто обучает НС.
Я рассказываю это тем, кто всю свою карьеру далёк от эффективных вычислений.
V>>Дотации от гос-ва еще никто не отменял.
S>Но и никто не видел
Эльбрусы делают за счёт минторга, если что.
V>>IT в этом деле как СХ, может быть и убыточным, но позволить отрасли уничтожиться опасно.
S>Жаль, что кроме нас с вами, это мало кто понимает.
Ну еще пара министерств, а так никто.
V>>Плюс VLIW — это хорошее поле именно для академки, там дофига алгоритмов компиляции-оптимизации можно разработать, защитить кучу кандидатских, обложить тысячами дипломных.
V>>Собсно, почему VLIW и не взлетел в мире — слишком большие требования к разработчикам, там околонаучное всё.
V>>Но это и есть наш подход к IT-образованию и он имеет ненулевой шанс "выстрелить".
S>Повторюсь: чтобы он выстрелил, нужны некоторые предварительные шаги. Прямо сейчас, как и в последние 10 лет, я этих шагов не наблюдаю.
Так ты и Objective-C не наблюдал, для тебя это "экзотика", хотя по-факту — обычная экосистема маков.
V>>Это задача компилятора.
S>Повторю вопрос: кто напишет компилятор?
Почему в будущем времени?
Компилятор давно написан и постоянно обновляется.
На сегодня есть полная поддержка стандарта С++14, идёт дальнейшее развитие компилятора.
V>>Ниоткуда, компиляция пойдёт по дефолтной ветке.
S>
Тогда и производительность будет дефолтная. Это на Интеле будет дефолтная, т.е. с проседанием.
Потому что SIMD — это костыль для убогих технологий прошлой эпохи.
V>>Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.
S>Спасибо, я в курсе, как работают макросы в С
Тогда бы ты не писал то, что писал.
V>>Зачем?
S>Эмм, чтобы обойти тупость компилятора.
Компилятор под amd_x64 тупой не просто так, а потому что автовекторизация в условиях ограничений на лейаут данных — задача не тривиальная.
В отсутствии таких ограничений проблема не существует.
Проблема автовекторизации в С/С++ происходит от того, что данные, которые хранятся в памяти, вынуждены сохранять свой лейаут.
Связано это с независимой компиляцией единиц трансляции, т.е. различные единицы трансляции должны одинаково интерпретировать один и тот же тип в памяти.
Это отрубает целый класс оптимизаций, связанных с переупорядочиванием представления данных в памяти.
Частично с этой проблемой неплохо борются архитектуры с большим файлом регистров и компиляторы, качественно проводящие escape-анализ, т.к. при обнаружении локальности данных (в регистрах или на стеке), руки у компилятора становятся развязаны.
Особенность компилятора под Эльбрус в том, что он лучше оригинального gcc умеет выполнять полную оптимизацию, т.е. использовать технику LTO, т.е. в том числе "замыкать" на уровне бинарного модуля видимость данных и преобразовывать их для достижения лучшей производительности. С включённой техникой LTO одни и те же тесты порой выполняются до 5 раз быстрее — инлайн для VLIW рулит. Неплохие результаты показывается так же PGO. Неплохие в сравнении с традиционными архитектурами.
V>>Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь.
S>Я в курсе. Я же уже показывал на коленках интринсик-код, который рвёт SIMD инструкции, предложенные компилятором.
Что лишь демонстрирует тупиковость этого подхода для классических архитектур.
S>Автовекторизация работает в очень ограниченных, узких случаях. И это — в случае достаточно тупого SIMD, где пространство вариантов выбора ограничено.
Верно. Проблема в ограничениях SIMD-расширений.
V>>А у Эльбруса весь код, считай, SIMD.
S>В том-то и дело.
Дело в меньших ограничениях.
Вернее, в полном отсутствии ограничений.
S>Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.
Эхх...
Потрать как-нить пол-часа:
http://www.mathnet.ru/links/338dc4eb1150dfc71b46111cd7cb9410/itvs662.pdf
... коды одной платформы попадают в динамический оптимизатор другой платформы для обеспечения полной программной совместимости. Этот
подход лучше всего реализуется на архитектурах с явным параллелизмом команд и с аппаратной поддержкой процесса двоичной трансляции. Дополнительным преимуществом динамической трансляции является возможность легко преодолевать межпроцедурные и межмодульные границы, выполняя тем самым мощный класс межпроцедурных оптимизаций. В ОДТЭ благодаря адаптивной оптимизации и достаточно хорошей аппаратной поддержке удается выполнять программы, исполняющиеся существенно быстрее, нежели на исходной платформе при той же тактовой частоте.
И в списке литературы тоже не скучно.
Сорри, но ты здесь вещаешь истины из разряда "не стоит клеить щит из сырой древесины".
V>>Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты.
S>
Для этого нужно знать, какие байты корректны, а какие — нет.Спецификации доступны уже пару лет как, технику тоже давно можно купить.
Разработка джит-компилятора — это несколько слоёв иерархии ТЗ-решение, где для 99% работы целевая архитектура не требуется вовсе.
Курить принципы работы оптимизирующих компиляторов.
V>>Изначально был доступен противоположный эмулятор... вернее, даже не эмулятор, а джиттинг x86/x64 кода в свою систему команд.
S>Он практически бесполезен для обсуждаемой задачи.
Наоборот, стоит задача генерить эффективный VLIW-код и динамический джит с x86/x64 показывает, что такие задачи мы умеем решать на самом что ни на есть мировом уровне.
Ты ведь должен понимать, что это край современного прогресса. ))
Сколько там лет и лярдов потрачено на джит-компиляторы подо всякие байт-коды дотнета, джавы или v8-JS?
Эти задачи выполняются мировыми лидерами.
А тут страна-бензоколонка на удивление легко и непринуждённо справляется с задачами такого рода.
V>>Ну вот сейчас зашевелятся, бо карты открыты — Запад намерен не то, что дружить, а хотя бы просто адекватно с нами общаться только если мы выглядим слабыми.
S>Я вот этого вот "сейчас зашевелятся" жду с 2008.
А я жду с 2014-го.
До этого так, просто пошипели малость...
S>Продолжаем принимать новости из будущего.
Ну... ты просто малость в другой реальности всю карьеру обитаешь.
V>>Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD.
V>>Ну вот сейчас зашевелятся.
S>
Ждём с нетерпением.Де-факто уже в процессе.
Происходит перенос на фабрики Китая.
Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии.
Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус.
Re[18]: .Net на эльбрусах
Здравствуйте, Sinclair, Вы писали:
V>>Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат:
V>>https://habr.com/ru/company/icl_services/blog/558564/
S>Это значит, что в кодеген компилятора встроили автовекторизацию простых циклов.
Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
Забудь само слово "автовекторизация" когда речь про VLIW.
V>>В общем, у Эльбруса проблема не в архитектуре, а в технологиях производства проца.
S>Ну, так я понял, что идея к тому и сводится, чтобы недостатки технологии обойти достоинствами архитектуры.
В том числе.
Причём, обойти в чувствительной к быстродействию вычислений области — обработке больших массивов данных в режиме жесткого реалтайм.
Например:
http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
V>>SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
S>Чего там высокоуровневого?
Это как вызов подпрограммы над определёнными структурами данных.
V>>Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.
S>Эффективнее — это если удалось автовекторизовать цепочку вычислений, причём так, чтобы в SIMD варианте такой комбинации не нашлось.
"Простая компиляция под Эльбрус" — это и есть твоя "автовекторизация".
Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
V>>Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения.
S>Взамен давая серъёзные преимущества.
Это в теории.
На деле всё плохо:
— у железа ограничено время принятия решения, в отличие от компилятора;
— величина окна просмотра логики ограничена;
— кол-во меток для кеширования ветвлений ограничено, т.е. в достаточно большом цикле никаких верных предсказаний ветвлений может и не быть (даже если цикл мал в исходнике, но вызывает, допустим, достаточно большие подпрограммы).
В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
Они выдают старое за новое.
Комбинируют новые подсистемы графики, контроллеров RAM, слабые ядра с сильными и т.д.
Т.е. делают вид, что что-то делают.
Но не делают ни-че-го.
Зеро.
Тупик происходит уже 10-й год.
V>>Зато намного сложнее писать программы целевым программистам, пытаясь выразить вычисления через весьма ограниченный в разнообразии компромисс-полуускоритель в виде SIMD в традиционных камнях.
S>Это если вручную.
Это даже компиляторами, потому что набор ср-в узок и соблюдённые требования по упакованности данных не так просто автоматически распознать.
Это почему до сих пор (позорище!) инстинстики над SIMD более чем популярны для ручного анонирования — из-за тупости компиляторов.
S>Но вручную и VLIW выписывать не шибко удобнее.
Вручную для VLIW и не требуется.
V>>Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))
S>Для начала надо столько, чтобы они взлетели. Влиять на отрасль — это уже дальний прицел.
Любая техническая экосистема — это система с обратной положительной связью.
V>>Будет удобно — будут пользоваться.
S>Ну так облаков как таковых — как грязи. Было бы желание — был бы госклауд, хоть на основе виртуалок, хоть serverless calculations.
Это всё планировали когда-то на основе Эльбрус 32c, там поддержка LDDR5 и прочие вкусности:
S>Но желания, как видим, никакого нет.
Нет железа.
Имеющиеся 8с, как ни крути, морально устарели.
Нужно было давать пинка разработке 16с, но чего-то телились почти 5 лет еле-еле.
Банальное недофинансирование.
Разворачивать инфраструктуру на 16с можно было бы уже смело давно, будь они в достаточном кол-ве, а там бы поспел и топчик 32с.
V>>В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы.
V>>А простое редактирование программы толком не занимает вовсе.
S>Редактирование программы нужно делать в нормальной IDE.
Любой ноут справляется с любой "нормальной IDE", если это не солюшен на 50+ проектов.
Один-два средних размера проекта в солюшене — ни о чём.
S>Я, конечно, в целях самодисциплины университетские лабы писал в Notepad.exe, но там и результаты — смешные. Для Эльбруса нужно не это.
Эльбрусу пофик, это ж Linux.
Например, сетевой диск монтируется локально как родной, IDE может исполняться локально, а компиляться и отлаживать код может удалённо и еще сверху миллион комбинаторных комбинаций конфигурирования.
Например, особой разницы локальной и удалённой отладки в линухах нет, в обоих случаях идёт общение с отладчиком-серисом одинаковым образом.
V>>Речь о принципиальной возможности доступа к железу для целей экспериментов.
S>Ещё раз: программы в стиле hello world вообще не нуждаются в эльбрусах, ни физических, ни виртуальных.
Программисты зато нуждаются.
У нас же нет аппарата принуждения инженеров.
Мы можем только сделать людям любопытно и смотреть, что из этого выйдет.
S>Если мы хотим, чтобы взлетел Эльбрус (а не освоить денег на поставках в госучреждения не очень нужных им машин), то отлаживаться будет нужно как минимум на эмуляторе, а лучше — на реальной железке.
На реальном железе лучше, конечно.
V>>О коммерческой выгодности проекта в ближайшие годы или десятилетия говорить заведомо бесполезно, ИМХО, — у IT-отрасли слишком большая инерция, слишком большие и длительные вложения требуется, чтобы растолкать какую-нибудь новую тему.
S>Очень малая у неё инерция.
Хотелось бы примеров.
Потому что история показывает ровно обратное.
S>Облака выстрелили в считанные годы — вот только что все строят свои собственные датацентры, и вот уже все ррраз! и уехали в ажур/aws.
Наоборот, линуховоды чуть ли не десяток лет паравиртуализацию в KVM разрабатывали.
И как только допилили до работоспособности — ррраз, и уехало.
Десяток лет, Карл!
А на деле всё-равно не справились.
Первый вменяемый гипервизор с паравиртуализацией Xen для линухов был разработан той самой академкой, а не традиционным программистским сообществом.
Аспирантура психанула, не иначе! ))
Самое забавное, что в Windows аналогичные технологии были готовы лет на ~8 раньше, но жадность фраера сгубила.
Все облака давно могли бы крутиться на виндах еще до середины нулевых... но тогда был слишком триумф Windows, поэтому они гордо просрали все полимеры.
Вот тебе вокруг только одних облаков чудовищная инерция:
— долгая неспособность оперативно разработать вменяемые технологии виртуализации для Linux;
— долгое игнорирование отраслью качественных имеющихся решений на основе операционок MS из-за ценовой политики.
Время... деньги...
S>Или там — вот у нас суперновый чип A1
Архитектура ARM зато не суперновая.
S>экзотический язык программирования и среда разработки
Objective-C экзотический? Ты с какой Луны к нам свалился, что ты делаешь на этом сайте? ))
На моей памяти — весьма популярный язык, т.к. C++ еще не был вменяемым в те годы.
Под маками на Objective-C написано чуть более чем всё с 80-х, когда Джобс основал NeXT, а потом принёс эти наработки в 90-х в Apple.
Оболочка Mac OS X — это переименованная NeXTSTEP.
Cocoa — это перелицованная GUI-среда оттуда же.
Для справки — многие игры под DOS (взять тот же Doom) разрабатывались в среде NeXT.
S>и хооп!
Да не было никакого хооп, что за буйные фантазии? ))
Был iPod + iTunes с 2001-го, потом Apple TV.
В общем, инфраструктура платного распространения ПО и контента не взялась с потолка, а долго рожалась и отлаживалась.
S>сотни тысяч программ в аппсторе, миллиарды оборота.
Ты подумал, что это написано с 0-ля или как понимать этот тон?
Под маками, в отличие от бесконечного зоопарка GUI виндов и линухов, альтернативных вариантов GUI нет.
С одной стороны, никак не сделать шаг вправо-влево.
С другой стороны, твой код не протухает десятилетиями.
Я допускаю, что это всё было экзотикой для тебя лично, т.к. ты в мак-экосистеме не вращался до покупки айфона/айпода или чего там...
Но какой смысл выдавать свои даже не наблюдения, а сугубо эмоциональные ощущения за "аргмент"? ))
Мне приходилось упражняться на Objective-C всю дорогу в 90-х.
Да и не только мне.
Просто вы, дельфийы, джависты, 1С-ники и прочие дотнетчики с точки зрения нормального разработчика были как пришельцы, наши "миры" ранее особо не пересекались.
Нам были неинтересны ваши наработки, а вы принципиально были не способны выполнять нашу работу.
Вы даже плохо представляли, в чём она заключается, какие задачи решаются.
V>>Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д.
V>>Т.е. вопрос заведомо затратный, но неизбежный.
S>Это если подходить с позиций превозмогания. А если подходить с позиций грамотного маркетинга, то можно сэкономить на два-три порядка.
Спасибо, прореагировал в голос.
И отчего же Интел была вынуждена похоронить многомиллиардный Itanium?
Какая-то блоха AMD, которая изначально стырила прям в бинаре архитектуру чипа 8080, спустя 20 лет помножила на ноль ВСЕ вложения Интел в Itanium.
Плохие маркетологи были в Intel? — не думаю.
Думаю, что рынок не всегда делает лучший выбор.
Думаю, что люди предпочитают меньше платить здесь и сейчас, и пофик, что за это они расплатятся лишней платой и завтра, и послезавтра, и всегда.
Не помню точных цифр, не хочу врать... Но как-то попадалось на глаза исследования, утверждалось, что из-за неудачных принятых когда-то решений (которые уже не переиграть) отрасль IT потребляет лишние десятки миллиардов ежегодно. Т.е. IT могло бы обходиться человечеству дешевле и эффективней.
V>>Пользователями современного топового железа в основном выступают облака.
S>Облака тоже не являются никакой самоценностью. Облака — всего лишь инструмент. Они востребованы настолько, насколько востребован софт, крутящийся в облаках.
Ключевое было про топовость.
Эльбрус имеет архитектуру суперкомпьютера, таки.
Так-то есть начальные процы, типа К1891ВМ068.
V>>Но будут платить за хостинг сервисов.
S>Для того, чтобы они платили за хостинг сервисов на эльбрусах, этот хостинг должен им предлагать что-то такое, чего нет на x86.
Надёжность подойдёт?
S>Например — более быстрый рендер графики, или более быстрый тренинг НС.
Или больше безопасности.
S>Иначе ничего интересного не получится — пользователи тупо уйдут в хостинг на классике.
Т.е., наблюдается забавная тенденция — новички валят на облака ажура или aws, а потом, поняв, что к чему, потихоньку валят на альтернативы.
В Азии, к примеру, растут десятки своих крупных игроков и цены там приятней.
Сравнивать доли облачных вычислений надо не в долларах, а в объёмах вычислений.
S>Если вы надеетесь на то, что прогнивший запад тупо зарежет нам поставки процессоров для отечественных облаков, а в облака МС, оракла и амазона мы не попадём из-за проблем с оплатой — то зря. Просто в эмиратах построят пару датацентров, и прекрасно будут получать железки из США, а деньги из РФ.
Странные у тебя фрмулировки насчёт "надеемся".
По факту сложности с оплатой там давно, сложности с железом нам достоверно обещали.
Никакие компромиссные варианты (а они будут, ес-но, на каком-то этапе) не интересуют в стратегическом плане.
От ненадёжных контрагентов придётся уходить.
Да и, учитывая современные ср-ва разворачивания и управления облаками, нет более никаких причин держатся за единицы монополистов:
https://www.cnews.ru/reviews/oblachnye_servisy_2022/interviews/mihail_solovev
https://e.huawei.com/ru/solutions/industries/isp/full-stack-cloud-services
S>В итоге мы опять упираемся в академические исследования и фундаментальные разработки.
И это прекрасно.
V>>Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом.
S>Бррр. Вы что-то путаете. Что облака делают хорошо — так это деление 16ядерного процессора между 160 "пользователями".
Это смотря какими пользователями, какой план/тарифы.
S>Тот параллелизм, который в SIMD или VLIW, тут непригоден.
Я говорил про поточный параллелизм, который не в пересчёте на ядро.
С ядрами в разрабатываемых Эльбрусах всё складывается неплохо — в этой архитектуре делить общую память могут 4 кристалла.
S>Чтобы вам это облако стало выгодно, нужно чтобы ваша задача считалась на эльбрусе эффективнее, чем на интеле.
Такой вариант, что норма прибыли оператора будет заложена в разы меньшая, ты не рассматривал?
V>>Ес-но, если дороже.
V>>А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро.
S>Расскажите про это тем, кто обучает НС.
Я рассказываю это тем, кто всю свою карьеру далёк от эффективных вычислений.
V>>Дотации от гос-ва еще никто не отменял.
S>Но и никто не видел
Эльбрусы делают за счёт минторга, если что.
V>>IT в этом деле как СХ, может быть и убыточным, но позволить отрасли уничтожиться опасно.
S>Жаль, что кроме нас с вами, это мало кто понимает.
Ну еще пара министерств, а так никто.
V>>Плюс VLIW — это хорошее поле именно для академки, там дофига алгоритмов компиляции-оптимизации можно разработать, защитить кучу кандидатских, обложить тысячами дипломных.
V>>Собсно, почему VLIW и не взлетел в мире — слишком большие требования к разработчикам, там околонаучное всё.
V>>Но это и есть наш подход к IT-образованию и он имеет ненулевой шанс "выстрелить".
S>Повторюсь: чтобы он выстрелил, нужны некоторые предварительные шаги. Прямо сейчас, как и в последние 10 лет, я этих шагов не наблюдаю.
Так ты и Objective-C не наблюдал, для тебя это "экзотика", хотя по-факту — обычная экосистема маков.
V>>Это задача компилятора.
S>Повторю вопрос: кто напишет компилятор?
Почему в будущем времени?
Компилятор давно написан и постоянно обновляется.
На сегодня есть полная поддержка стандарта С++14, идёт дальнейшее развитие компилятора.
V>>Ниоткуда, компиляция пойдёт по дефолтной ветке.
S> Тогда и производительность будет дефолтная.
Это на Интеле будет дефолтная, т.е. с проседанием.
Потому что SIMD — это костыль для убогих технологий прошлой эпохи.
V>>Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.
S>Спасибо, я в курсе, как работают макросы в С
Тогда бы ты не писал то, что писал.
V>>Зачем?
S>Эмм, чтобы обойти тупость компилятора.
Компилятор под amd_x64 тупой не просто так, а потому что автовекторизация в условиях ограничений на лейаут данных — задача не тривиальная.
В отсутствии таких ограничений проблема не существует.
Проблема автовекторизации в С/С++ происходит от того, что данные, которые хранятся в памяти, вынуждены сохранять свой лейаут.
Связано это с независимой компиляцией единиц трансляции, т.е. различные единицы трансляции должны одинаково интерпретировать один и тот же тип в памяти.
Это отрубает целый класс оптимизаций, связанных с переупорядочиванием представления данных в памяти.
Частично с этой проблемой неплохо борются архитектуры с большим файлом регистров и компиляторы, качественно проводящие escape-анализ, т.к. при обнаружении локальности данных (в регистрах или на стеке), руки у компилятора становятся развязаны.
Особенность компилятора под Эльбрус в том, что он лучше оригинального gcc умеет выполнять полную оптимизацию, т.е. использовать технику LTO, т.е. в том числе "замыкать" на уровне бинарного модуля видимость данных и преобразовывать их для достижения лучшей производительности. С включённой техникой LTO одни и те же тесты порой выполняются до 5 раз быстрее — инлайн для VLIW рулит. Неплохие результаты показывается так же PGO. Неплохие в сравнении с традиционными архитектурами.
V>>Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь.
S>Я в курсе. Я же уже показывал на коленках интринсик-код, который рвёт SIMD инструкции, предложенные компилятором.
Что лишь демонстрирует тупиковость этого подхода для классических архитектур.
S>Автовекторизация работает в очень ограниченных, узких случаях. И это — в случае достаточно тупого SIMD, где пространство вариантов выбора ограничено.
Верно. Проблема в ограничениях SIMD-расширений.
V>>А у Эльбруса весь код, считай, SIMD.
S>В том-то и дело.
Дело в меньших ограничениях.
Вернее, в полном отсутствии ограничений.
S>Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.
Эхх...
Потрать как-нить пол-часа:
http://www.mathnet.ru/links/338dc4eb1150dfc71b46111cd7cb9410/itvs662.pdf
И в списке литературы тоже не скучно.
Сорри, но ты здесь вещаешь истины из разряда "не стоит клеить щит из сырой древесины".
V>>Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты.
S> Для этого нужно знать, какие байты корректны, а какие — нет.
Спецификации доступны уже пару лет как, технику тоже давно можно купить.
Разработка джит-компилятора — это несколько слоёв иерархии ТЗ-решение, где для 99% работы целевая архитектура не требуется вовсе.
Курить принципы работы оптимизирующих компиляторов.
V>>Изначально был доступен противоположный эмулятор... вернее, даже не эмулятор, а джиттинг x86/x64 кода в свою систему команд.
S>Он практически бесполезен для обсуждаемой задачи.
Наоборот, стоит задача генерить эффективный VLIW-код и динамический джит с x86/x64 показывает, что такие задачи мы умеем решать на самом что ни на есть мировом уровне.
Ты ведь должен понимать, что это край современного прогресса. ))
Сколько там лет и лярдов потрачено на джит-компиляторы подо всякие байт-коды дотнета, джавы или v8-JS?
Эти задачи выполняются мировыми лидерами.
А тут страна-бензоколонка на удивление легко и непринуждённо справляется с задачами такого рода.
V>>Ну вот сейчас зашевелятся, бо карты открыты — Запад намерен не то, что дружить, а хотя бы просто адекватно с нами общаться только если мы выглядим слабыми.
S>Я вот этого вот "сейчас зашевелятся" жду с 2008.
А я жду с 2014-го.
До этого так, просто пошипели малость...
S>Продолжаем принимать новости из будущего.
Ну... ты просто малость в другой реальности всю карьеру обитаешь.
V>>Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD.
V>>Ну вот сейчас зашевелятся.
S> Ждём с нетерпением.
Де-факто уже в процессе.
Происходит перенос на фабрики Китая.
Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии.
Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус.
V>>Как раз тесты навроде HPL хорошо это показывают, при том что в целочисленной арифметике Эльбрус заметно сливает i7, но показывает в этом тесте в разы лучший результат:
V>>https://habr.com/ru/company/icl_services/blog/558564/
S>Это значит, что в кодеген компилятора встроили автовекторизацию простых циклов.
Это значит, что ты пытаешься имещиеся свои представления натянуть на другие предметные области.
Забудь само слово "автовекторизация" когда речь про VLIW.
V>>В общем, у Эльбруса проблема не в архитектуре, а в технологиях производства проца.
S>Ну, так я понял, что идея к тому и сводится, чтобы недостатки технологии обойти достоинствами архитектуры.
В том числе.
Причём, обойти в чувствительной к быстродействию вычислений области — обработке больших массивов данных в режиме жесткого реалтайм.
Например:
http://mcst.ru/problemy-integracii-universalnykh-yader-arkhitektury-elbrus
Для "бизнес-вычислений", автоматики и прочего продолжают развивать архитектуру SPARC:
http://ineum.ru/yazyki-standarta-iec61131-dlya-vychislitelnykh-kompleksov-na-baze-otechestvennykh-mikroprocessorov-s-arkhitekturoj-sparc
V>>SIMD в традиционных процах — это относительно высокоуровневые команды (помимо "просто большого файла регистров").
S>Чего там высокоуровневого?
Это как вызов подпрограммы над определёнными структурами данных.
V>>Но на все случаи жизни высокоуровневых команд не напасёшься. Эффективней делать то же самое "по-месту", для чего и служит VLIW.
S>Эффективнее — это если удалось автовекторизовать цепочку вычислений, причём так, чтобы в SIMD варианте такой комбинации не нашлось.
"Простая компиляция под Эльбрус" — это и есть твоя "автовекторизация".
Рассуждения об "удалось или нет векторизировать" можно озвучивать только для ограниченных наборов SIMD-инструкций мейнстримовых камней, а для Эльбруса никаких ограничений нет — в одном слове можно объединять десятки команд над упакованными или нет данными.
V>>Да, сперскалярная архитектура потенциально лучше, но этот тот же "компилятор", только в железе, что означает серьёзные ограничения.
S>Взамен давая серъёзные преимущества.
Это в теории.
На деле всё плохо:
— у железа ограничено время принятия решения, в отличие от компилятора;
— величина окна просмотра логики ограничена;
— кол-во меток для кеширования ветвлений ограничено, т.е. в достаточно большом цикле никаких верных предсказаний ветвлений может и не быть (даже если цикл мал в исходнике, но вызывает, допустим, достаточно большие подпрограммы).
В Интел когда-то начали работать на Itanium потому что суперскаляры уже тогда подбирались к своему пределу, а именно — начинали больше тратить ресурсов на управление кодом, чем на полезные вычисления.
И эта прболема никуда не делась — все последние поколения процов Интел — фейк.
Они выдают старое за новое.
Комбинируют новые подсистемы графики, контроллеров RAM, слабые ядра с сильными и т.д.
Т.е. делают вид, что что-то делают.
Но не делают ни-че-го.
Зеро.
Тупик происходит уже 10-й год.
V>>Зато намного сложнее писать программы целевым программистам, пытаясь выразить вычисления через весьма ограниченный в разнообразии компромисс-полуускоритель в виде SIMD в традиционных камнях.
S>Это если вручную.
Это даже компиляторами, потому что набор ср-в узок и соблюдённые требования по упакованности данных не так просто автоматически распознать.
Это почему до сих пор (позорище!) инстинстики над SIMD более чем популярны для ручного анонирования — из-за тупости компиляторов.
S>Но вручную и VLIW выписывать не шибко удобнее.
Вручную для VLIW и не требуется.
V>>Примерно столько требуется Эльбрусов только в РФ, чтобы они стали неотвратимо влиять на отрасль. ))
S>Для начала надо столько, чтобы они взлетели. Влиять на отрасль — это уже дальний прицел.
Любая техническая экосистема — это система с обратной положительной связью.
V>>Будет удобно — будут пользоваться.
S>Ну так облаков как таковых — как грязи. Было бы желание — был бы госклауд, хоть на основе виртуалок, хоть serverless calculations.
Это всё планировали когда-то на основе Эльбрус 32c, там поддержка LDDR5 и прочие вкусности:
Например, новая память Samsung LPDDR5 6400 может отправлять 51,2 гигабайта данных или примерно 14 видеофайлов в формате Full HD (3,7 ГБ каждый) за секунду.
Планируемые характеристики микропроцессора «Эльбрус-32С»:
производительность — до 3 / 1,5 Тфлоп/с;
количество ядер — 32;
Тактовая частота — 2,5 ГГц;
объем кэш-памяти (L2+L3) — 64 МБ;
ОЗУ — тип DDR5, 170 ГБайт/с, не менее 6 каналов, не менее 2 Тбайт;
интерфейсы: 64 линии PCIe 5.0, Ethernet 10/25/40/50/100 Гбит/с, USB 3.1;
возможность объединения до четырех микропроцессоров на общей памяти;
технология — 7 нм.
S>Но желания, как видим, никакого нет.
Нет железа.
Имеющиеся 8с, как ни крути, морально устарели.
Нужно было давать пинка разработке 16с, но чего-то телились почти 5 лет еле-еле.
Банальное недофинансирование.
Разворачивать инфраструктуру на 16с можно было бы уже смело давно, будь они в достаточном кол-ве, а там бы поспел и топчик 32с.
V>>В облаках для обучения коэфициент можно сделать гораздо больше, чем 1:10, т.к. оно именно так — запуск-тектирование лаб и курсовиков занимает смешные ресурсы.
V>>А простое редактирование программы толком не занимает вовсе.
S>Редактирование программы нужно делать в нормальной IDE.
Любой ноут справляется с любой "нормальной IDE", если это не солюшен на 50+ проектов.
Один-два средних размера проекта в солюшене — ни о чём.
S>Я, конечно, в целях самодисциплины университетские лабы писал в Notepad.exe, но там и результаты — смешные. Для Эльбруса нужно не это.
Эльбрусу пофик, это ж Linux.
Например, сетевой диск монтируется локально как родной, IDE может исполняться локально, а компиляться и отлаживать код может удалённо и еще сверху миллион комбинаторных комбинаций конфигурирования.
Например, особой разницы локальной и удалённой отладки в линухах нет, в обоих случаях идёт общение с отладчиком-серисом одинаковым образом.
V>>Речь о принципиальной возможности доступа к железу для целей экспериментов.
S>Ещё раз: программы в стиле hello world вообще не нуждаются в эльбрусах, ни физических, ни виртуальных.
Программисты зато нуждаются.
У нас же нет аппарата принуждения инженеров.
Мы можем только сделать людям любопытно и смотреть, что из этого выйдет.
S>Если мы хотим, чтобы взлетел Эльбрус (а не освоить денег на поставках в госучреждения не очень нужных им машин), то отлаживаться будет нужно как минимум на эмуляторе, а лучше — на реальной железке.
На реальном железе лучше, конечно.
V>>О коммерческой выгодности проекта в ближайшие годы или десятилетия говорить заведомо бесполезно, ИМХО, — у IT-отрасли слишком большая инерция, слишком большие и длительные вложения требуется, чтобы растолкать какую-нибудь новую тему.
S>Очень малая у неё инерция.
Хотелось бы примеров.
Потому что история показывает ровно обратное.
S>Облака выстрелили в считанные годы — вот только что все строят свои собственные датацентры, и вот уже все ррраз! и уехали в ажур/aws.
Наоборот, линуховоды чуть ли не десяток лет паравиртуализацию в KVM разрабатывали.
И как только допилили до работоспособности — ррраз, и уехало.
Десяток лет, Карл!
А на деле всё-равно не справились.
Первый вменяемый гипервизор с паравиртуализацией Xen для линухов был разработан той самой академкой, а не традиционным программистским сообществом.
Аспирантура психанула, не иначе! ))
Самое забавное, что в Windows аналогичные технологии были готовы лет на ~8 раньше, но жадность фраера сгубила.
Все облака давно могли бы крутиться на виндах еще до середины нулевых... но тогда был слишком триумф Windows, поэтому они гордо просрали все полимеры.
Вот тебе вокруг только одних облаков чудовищная инерция:
— долгая неспособность оперативно разработать вменяемые технологии виртуализации для Linux;
— долгое игнорирование отраслью качественных имеющихся решений на основе операционок MS из-за ценовой политики.
Время... деньги...
S>Или там — вот у нас суперновый чип A1
Архитектура ARM зато не суперновая.
Apple Newton или просто Newton — одна из первых серий карманных персональных компьютеров, которая разрабатывалась, производилась и продавалась фирмой Apple Computer. Apple начала разработку платформы в 1987 году и выпустила первые устройства в августе 1993 года.
...
Большинство компьютеров Newton работали на RISC-процессоре ARM 610.
S>экзотический язык программирования и среда разработки
Objective-C экзотический? Ты с какой Луны к нам свалился, что ты делаешь на этом сайте? ))
На моей памяти — весьма популярный язык, т.к. C++ еще не был вменяемым в те годы.
Под маками на Objective-C написано чуть более чем всё с 80-х, когда Джобс основал NeXT, а потом принёс эти наработки в 90-х в Apple.
Оболочка Mac OS X — это переименованная NeXTSTEP.
Cocoa — это перелицованная GUI-среда оттуда же.
Для справки — многие игры под DOS (взять тот же Doom) разрабатывались в среде NeXT.
S>и хооп!
Да не было никакого хооп, что за буйные фантазии? ))
Был iPod + iTunes с 2001-го, потом Apple TV.
В общем, инфраструктура платного распространения ПО и контента не взялась с потолка, а долго рожалась и отлаживалась.
S>сотни тысяч программ в аппсторе, миллиарды оборота.
Ты подумал, что это написано с 0-ля или как понимать этот тон?
Под маками, в отличие от бесконечного зоопарка GUI виндов и линухов, альтернативных вариантов GUI нет.
С одной стороны, никак не сделать шаг вправо-влево.
С другой стороны, твой код не протухает десятилетиями.
Я допускаю, что это всё было экзотикой для тебя лично, т.к. ты в мак-экосистеме не вращался до покупки айфона/айпода или чего там...
Но какой смысл выдавать свои даже не наблюдения, а сугубо эмоциональные ощущения за "аргмент"? ))
Мне приходилось упражняться на Objective-C всю дорогу в 90-х.
Да и не только мне.
Просто вы, дельфийы, джависты, 1С-ники и прочие дотнетчики с точки зрения нормального разработчика были как пришельцы, наши "миры" ранее особо не пересекались.
Нам были неинтересны ваши наработки, а вы принципиально были не способны выполнять нашу работу.
Вы даже плохо представляли, в чём она заключается, какие задачи решаются.
V>>Это вопрос не прибылей, а технологической безопасности страны, в т.ч. в области военки, космоса и т.д.
V>>Т.е. вопрос заведомо затратный, но неизбежный.
S>Это если подходить с позиций превозмогания. А если подходить с позиций грамотного маркетинга, то можно сэкономить на два-три порядка.
Спасибо, прореагировал в голос.
И отчего же Интел была вынуждена похоронить многомиллиардный Itanium?
Какая-то блоха AMD, которая изначально стырила прям в бинаре архитектуру чипа 8080, спустя 20 лет помножила на ноль ВСЕ вложения Интел в Itanium.
Плохие маркетологи были в Intel? — не думаю.
Думаю, что рынок не всегда делает лучший выбор.
Думаю, что люди предпочитают меньше платить здесь и сейчас, и пофик, что за это они расплатятся лишней платой и завтра, и послезавтра, и всегда.
Не помню точных цифр, не хочу врать... Но как-то попадалось на глаза исследования, утверждалось, что из-за неудачных принятых когда-то решений (которые уже не переиграть) отрасль IT потребляет лишние десятки миллиардов ежегодно. Т.е. IT могло бы обходиться человечеству дешевле и эффективней.
V>>Пользователями современного топового железа в основном выступают облака.
S>Облака тоже не являются никакой самоценностью. Облака — всего лишь инструмент. Они востребованы настолько, насколько востребован софт, крутящийся в облаках.
Ключевое было про топовость.
Эльбрус имеет архитектуру суперкомпьютера, таки.
Так-то есть начальные процы, типа К1891ВМ068.
V>>Но будут платить за хостинг сервисов.
S>Для того, чтобы они платили за хостинг сервисов на эльбрусах, этот хостинг должен им предлагать что-то такое, чего нет на x86.
Надёжность подойдёт?
S>Например — более быстрый рендер графики, или более быстрый тренинг НС.
Или больше безопасности.
S>Иначе ничего интересного не получится — пользователи тупо уйдут в хостинг на классике.
Т.е., наблюдается забавная тенденция — новички валят на облака ажура или aws, а потом, поняв, что к чему, потихоньку валят на альтернативы.
В Азии, к примеру, растут десятки своих крупных игроков и цены там приятней.
Сравнивать доли облачных вычислений надо не в долларах, а в объёмах вычислений.
S>Если вы надеетесь на то, что прогнивший запад тупо зарежет нам поставки процессоров для отечественных облаков, а в облака МС, оракла и амазона мы не попадём из-за проблем с оплатой — то зря. Просто в эмиратах построят пару датацентров, и прекрасно будут получать железки из США, а деньги из РФ.
Странные у тебя фрмулировки насчёт "надеемся".
По факту сложности с оплатой там давно, сложности с железом нам достоверно обещали.
Никакие компромиссные варианты (а они будут, ес-но, на каком-то этапе) не интересуют в стратегическом плане.
От ненадёжных контрагентов придётся уходить.
Да и, учитывая современные ср-ва разворачивания и управления облаками, нет более никаких причин держатся за единицы монополистов:
https://www.cnews.ru/reviews/oblachnye_servisy_2022/interviews/mihail_solovev
https://e.huawei.com/ru/solutions/industries/isp/full-stack-cloud-services
S>В итоге мы опять упираемся в академические исследования и фундаментальные разработки.
И это прекрасно.
V>>Облака хороши тем, что могут восполнять недостаток производительности в пересчёте на ядро параллелизмом.
S>Бррр. Вы что-то путаете. Что облака делают хорошо — так это деление 16ядерного процессора между 160 "пользователями".
Это смотря какими пользователями, какой план/тарифы.
S>Тот параллелизм, который в SIMD или VLIW, тут непригоден.
Я говорил про поточный параллелизм, который не в пересчёте на ядро.
С ядрами в разрабатываемых Эльбрусах всё складывается неплохо — в этой архитектуре делить общую память могут 4 кристалла.
S>Чтобы вам это облако стало выгодно, нужно чтобы ваша задача считалась на эльбрусе эффективнее, чем на интеле.
Такой вариант, что норма прибыли оператора будет заложена в разы меньшая, ты не рассматривал?
V>>Ес-но, если дороже.
V>>А насчёт производительности — 99% сервисов больше тормозятся о сервера БД и прочее IO, камни давно уже не являются бутылочным горлышком, т.е. давно обитают в области достаточности произодительности на ядро.
S>Расскажите про это тем, кто обучает НС.
Я рассказываю это тем, кто всю свою карьеру далёк от эффективных вычислений.
V>>Дотации от гос-ва еще никто не отменял.
S>Но и никто не видел
Эльбрусы делают за счёт минторга, если что.
V>>IT в этом деле как СХ, может быть и убыточным, но позволить отрасли уничтожиться опасно.
S>Жаль, что кроме нас с вами, это мало кто понимает.
Ну еще пара министерств, а так никто.
V>>Плюс VLIW — это хорошее поле именно для академки, там дофига алгоритмов компиляции-оптимизации можно разработать, защитить кучу кандидатских, обложить тысячами дипломных.
V>>Собсно, почему VLIW и не взлетел в мире — слишком большие требования к разработчикам, там околонаучное всё.
V>>Но это и есть наш подход к IT-образованию и он имеет ненулевой шанс "выстрелить".
S>Повторюсь: чтобы он выстрелил, нужны некоторые предварительные шаги. Прямо сейчас, как и в последние 10 лет, я этих шагов не наблюдаю.
Так ты и Objective-C не наблюдал, для тебя это "экзотика", хотя по-факту — обычная экосистема маков.
V>>Это задача компилятора.
S>Повторю вопрос: кто напишет компилятор?
Почему в будущем времени?
Компилятор давно написан и постоянно обновляется.
На сегодня есть полная поддержка стандарта С++14, идёт дальнейшее развитие компилятора.
V>>Ниоткуда, компиляция пойдёт по дефолтной ветке.
S>
Тогда и производительность будет дефолтная. Это на Интеле будет дефолтная, т.е. с проседанием.
Потому что SIMD — это костыль для убогих технологий прошлой эпохи.
V>>Да и, при сборке пакетов символами всё настраивается, ненужные ветки кода просто не будут скомпиллированы.
S>Спасибо, я в курсе, как работают макросы в С
Тогда бы ты не писал то, что писал.
V>>Зачем?
S>Эмм, чтобы обойти тупость компилятора.
Компилятор под amd_x64 тупой не просто так, а потому что автовекторизация в условиях ограничений на лейаут данных — задача не тривиальная.
В отсутствии таких ограничений проблема не существует.
Проблема автовекторизации в С/С++ происходит от того, что данные, которые хранятся в памяти, вынуждены сохранять свой лейаут.
Связано это с независимой компиляцией единиц трансляции, т.е. различные единицы трансляции должны одинаково интерпретировать один и тот же тип в памяти.
Это отрубает целый класс оптимизаций, связанных с переупорядочиванием представления данных в памяти.
Частично с этой проблемой неплохо борются архитектуры с большим файлом регистров и компиляторы, качественно проводящие escape-анализ, т.к. при обнаружении локальности данных (в регистрах или на стеке), руки у компилятора становятся развязаны.
Особенность компилятора под Эльбрус в том, что он лучше оригинального gcc умеет выполнять полную оптимизацию, т.е. использовать технику LTO, т.е. в том числе "замыкать" на уровне бинарного модуля видимость данных и преобразовывать их для достижения лучшей производительности. С включённой техникой LTO одни и те же тесты порой выполняются до 5 раз быстрее — инлайн для VLIW рулит. Неплохие результаты показывается так же PGO. Неплохие в сравнении с традиционными архитектурами.
V>>Современные компиляторы пользуют SIMD-инструкции, даже если ты прямо их не вызываешь.
S>Я в курсе. Я же уже показывал на коленках интринсик-код, который рвёт SIMD инструкции, предложенные компилятором.
Что лишь демонстрирует тупиковость этого подхода для классических архитектур.
S>Автовекторизация работает в очень ограниченных, узких случаях. И это — в случае достаточно тупого SIMD, где пространство вариантов выбора ограничено.
Верно. Проблема в ограничениях SIMD-расширений.
V>>А у Эльбруса весь код, считай, SIMD.
S>В том-то и дело.
Дело в меньших ограничениях.
Вернее, в полном отсутствии ограничений.
S>Дотнет же пошёл по пути интринсиков — и там всё прекрасно, т.к. можно в какой-нибудь Array.IndexOf спрятать адскую магию и иметь предсказуемую производительность, и не полагаясь на случайности джита.
Эхх...
Потрать как-нить пол-часа:
http://www.mathnet.ru/links/338dc4eb1150dfc71b46111cd7cb9410/itvs662.pdf
... коды одной платформы попадают в динамический оптимизатор другой платформы для обеспечения полной программной совместимости. Этот
подход лучше всего реализуется на архитектурах с явным параллелизмом команд и с аппаратной поддержкой процесса двоичной трансляции. Дополнительным преимуществом динамической трансляции является возможность легко преодолевать межпроцедурные и межмодульные границы, выполняя тем самым мощный класс межпроцедурных оптимизаций. В ОДТЭ благодаря адаптивной оптимизации и достаточно хорошей аппаратной поддержке удается выполнять программы, исполняющиеся существенно быстрее, нежели на исходной платформе при той же тактовой частоте.
И в списке литературы тоже не скучно.
Сорри, но ты здесь вещаешь истины из разряда "не стоит клеить щит из сырой древесины".
V>>Для проверки сгенерированного кода нужен не эмулятор, а тесты, проверяющие целевые байты.
S>
Для этого нужно знать, какие байты корректны, а какие — нет.Спецификации доступны уже пару лет как, технику тоже давно можно купить.
Разработка джит-компилятора — это несколько слоёв иерархии ТЗ-решение, где для 99% работы целевая архитектура не требуется вовсе.
Курить принципы работы оптимизирующих компиляторов.
V>>Изначально был доступен противоположный эмулятор... вернее, даже не эмулятор, а джиттинг x86/x64 кода в свою систему команд.
S>Он практически бесполезен для обсуждаемой задачи.
Наоборот, стоит задача генерить эффективный VLIW-код и динамический джит с x86/x64 показывает, что такие задачи мы умеем решать на самом что ни на есть мировом уровне.
Ты ведь должен понимать, что это край современного прогресса. ))
Сколько там лет и лярдов потрачено на джит-компиляторы подо всякие байт-коды дотнета, джавы или v8-JS?
Эти задачи выполняются мировыми лидерами.
А тут страна-бензоколонка на удивление легко и непринуждённо справляется с задачами такого рода.
V>>Ну вот сейчас зашевелятся, бо карты открыты — Запад намерен не то, что дружить, а хотя бы просто адекватно с нами общаться только если мы выглядим слабыми.
S>Я вот этого вот "сейчас зашевелятся" жду с 2008.
А я жду с 2014-го.
До этого так, просто пошипели малость...
S>Продолжаем принимать новости из будущего.
Ну... ты просто малость в другой реальности всю карьеру обитаешь.
V>>Никто не мешал вкладывать в Эльбрус ср-ва ранее и давно могли бы выпустить его на хорошем техпроцессе на Тайване, где пол-мира клепает свои процы, та же Apple или AMD.
V>>Ну вот сейчас зашевелятся.
S>
Ждём с нетерпением.Де-факто уже в процессе.
Происходит перенос на фабрики Китая.
Технически это потребовало переразвести на другой техпроцесс реализацию чипа, сейчас на этой стадии.
Но это можно было сделать еще в 2019-м, когда Хуавей предлагал свои мощности под Эльбрус.