Комментарии 49
"По словам гостя, многие люди используют «Эльбрус» даже дома." -:)
У «Эльбруса» компилятор действует от обратного: сначала он анализирует весь код, предполагает, где будут переходы, а после компилирует на основании того, что он знает весь код.
Ну да, ну да...
Сегодня я нажал кнопку 1, и переход пошел в одну сторону, а завтра 0 и переход пошел в противоположную. Но у нас же есть магический компилятор.
ага, и предсказание переходов от Intel идёт нафиг)
Вообще формулировка хорошая, но очень сильно напоминает принцип CLR, CLR тоже "анализирует" код и пытается оптимизировать IL-assembler код. Но как показывает практика, реальность - это то, как вы описали, сегодня пятка зачесалась - поставил новую галку, и вся ветка алгоритма пошла по иному пути...
ага, и предсказание переходов от Intel идёт нафиг)
Они друг другу не противоречат. Profile-guided optimization есть во всех современных компиляторах C/C++. И на Intel бывает дает прирост производительности 5-10%. Firefox, например, насколько я знаю, собирается с PGO.
Динамическое предсказание нормально обработает случай, когда у нас на одних входных данных один паттерн переходов, на других - другой, и нам сегодня приходят одни данные, а завтра другие. Чем поможет компилятор - не понимаю.
Это только когда ветка встречается первый раз, дальше предсказание работает на основе информации в BTB.
Почитайте книгу "Оптимизация ПО, Сборник рецептов" 4 (или новее)
издание. Там достаточно хорошо написано как работает блок предсказания
ветвления в современных процессорах. Так вот, в 99% случаев предсказание
ветвления выбирается исходя из типа операции == и != -. Для условия ==
ветка then с высокой вероятностью будет выполнена. Для != ветка then с
высокой вероятностью не должна выполняться. Собственно говоря всё.
Автору той книги следовало бы поставить "кол" за знание материала. То, о чем Вы говорите называется "статический предсказатель ветвлений", это была первая попытка решить вопрос непрерывного потока инструкций и давно ни где не используется (ну может быть в дешманских микроконтроллера). Предсказатели в современных процессорах весьма навороченные, используют не только статистику, но и нейросети для анализа потока данных, причем не только локальных. Вероятность правильного предсказания достигает 97%.
PS: Тут вот что еще следует отметить. Предсказатель ветвлений это совсем небольшое увеличение производительности. Более существенный прирост дает спекулятивное исполнение, которое зависит от данных предсказателя. И тут мы подходим к широко известным проблемам типа Meltdown и Spectre, правильного решения которым, если я все верно понимаю, принципиально не существует. Т.е. если требуется высокая производительность - будьте готовы сосуществовать с данными поблемами.
В таком случае у меня есть основания полагать, что Вы неверно интерпретировали материал книги. Я прочел другую книгу: The Art of Writing Efficient Programs нашего соотечественника Федора Пикуса. В ней автор достаточно глубоко обсуждает работу предсказателя, описывает системные утилиты для оценки эффективности действий предсказателя, приводит примеры программ и техники "как помочь" предсказателю еще более эффективно исполнять вашу программу. В качестве допа автор показывает на детальном C++ примере как работает Spectre, собсно из-за этого я книгу и купил. :)
А просто разработчикам не надо сачковать и везде расставлять likely/unlikely макросы. :-D
Такое не работает, он предсказывает, например итерационные переходы, типа цикл, от 0 до 100, очевидно, что если I ==6, то следующая ветка будет новая итерации, а не выход из цикла.
Циклы это огромный пласт ПО.
Это так, но это ситуация из мира десктопов к которым эльбрус и правда не готов, но например на сервере где одно и то же нагруженное приложение крутится 24/7 и обрабатывает файлы только определенного размера и форматов. В таких вполне предсказуемых и прогнозируемых применениях бредом уже кажется динамический подход в котором процессор будет анализировать одно и то же месяцами и жечь электричество делая работу о которой никто не просил.
Хотелось бы конечно что бы в будущем эльбрусе было что то средненькое чтоб и так и немножко эдак тоже умело, например что бы команды подготовок не готовили переход как таковой а создавали стек вызовов/переходов, в котором простой как веник бранчпридиктор пометит переходы которые скорее всего не произойдут сверив с историей и начнет толкать в конвеер код который точно или почти точно произойдет. По умолчанию пусть будет считать что точно все произойдет.
Если Вы на сервере непрерывно считаете Фурье (FFT), то все верно, нафиг жечь электричество. Но если у Вас высоконагруженный сервер обработки данных пользователя или СУБД, то без предсказателя и спекулятивного исполнения Вы будете жечь в десятки раз больше электричества. Проблема в данных, которые каждый новый запрос разные.
Причем здесь отдельные алгоритмы. Я говорил о задачах.
Когда собирают программы под десктоп, никто точно не знает с чем и как будет работать условный пользователь. Поэтому программы собираются с максимальным функционалом, а это ветвления и куча подключаемых библиотек, которые возможно не нужны вообще, но из которых эльбрус будет дергать функции в кэш и подготавливать в конвеер постоянно, просто потому что эльбрус так работает и на данный момент не умеет подстраивать поток исполнения.
Сервер - это совсем другое дело. Там нет пользователя запускающего разные программы под свои сегодняшние задачи, там настраивается и поднимается (условно) одно приложение работающее с заранее предорприделенным типом данных - картинками jpg и png размером от 10x10 до 5000x5000 пикселей, простые текстовые данные до 100000 символов или json сообщения. И запускается оно не пару раз в день а один раз и надолго. Здесь можно и нужно заморочится с более тонкой конфигурацией софта перед запуском в продакшн.
Что до СУБД, то запросы как правило тоже делаются из приложения, а пользователю если и предоставляется какой то доступ к ней, то только через API, напрямую какие попало запросы ей не посылаются.
Лично мне бредом кажется, что вы уже который год продолжаете писать одни и те же глупости, хотя можно было бы уже давно погрузиться в тему и разобраться, какие типы нагрузок на серверах бывают, и какие цепи в каких классах микроархитектур вхолостую гоняют электричество. В качестве исходной точки, возьмите такую характеристику, как перформанс на ватт, и сравните показатели Эльбруса и какого-нибудь средненького x86-сервера со сходным техпроцессом. Дальше попробуйте ответить на вопрос, почему так? Это дорога, которая приведёт вас к пониманию множества аспектов характеристик микропроцессоров.
А почему перестали выкладывать на ютуб?
У компании МЦСТ уже сейчас есть процессор, который можно применять в смартфоне, — осталось только произвести.
Тюююю, делов-то... всего лишь запустить линию по производству процессоров 10нм. Это гораздо проще, чем сделать свою подушку безопасности, свой пассажирский самолёт на 200 мест или свой отечественный ЖК 4К телевизор с диагональю 50-70 дюймов.
Хорошая попытка, Эльбрус. Но нет.
Как дела с микроэлектроникой? Плохо.
Интересно бы посмотреть на того дизайнера, который придумал этот логотип "Е|брус". Сразу так много смыслов в него заложено...
«Эльбрус» — наиболее высокопроизводительный микропроцессор из отечественных. Он полностью российский — там нет комплектующих, из-за которых нам могут запретить его использовать, производить или разрабатывать новый, что сегодня очень важно.
Неужели и интерфейсы (DDR, GbE и т.п.) все свои? И блоки ОЗУ? И библиотека standard cells для фабрики тоже своя?
А мне бы хотелось потестить эльбрус. Домой бы я его конечно не купил, но при текущей ситуации альтернатив ему нет.
Забавно смотрятся заголовки "Elбрус, или Как дела с микроэлектроникой в России в 2023 году", когда еще свежи в памяти выступления Б. Бабаяна на центральных каналах в начале 90-х.
В тех выступлениях смысл был, что он уже догнал intel, осталось только перегнать. Какие красивые речи были, прямо не оторваться от телека, причем в эфире рядом сажал других академиков, которые дружных хором ему в студии подпевали. Причем речь шла именно о массовом производстве, типа "Эльбрус в каждый дом". Я стучал по клавишам советских аналогов на К1810ВМ88 и верил: не врут же наши академики, - значит через пару лет все на Эльбрусы пересядем...
Уже потом его риторика стала более умеренной типа ("намерен", "скоро догоним"):
Потом вообще:
А вообще про Эльбрус че нибудь слышно?
Видимо входим в очередной виток спирали истории.
к 2030 году эти современные процессоры превратятся в устареший 8-10 летний хлам
Нельзя не вспомнить
Гость выпуска попал в МЦСТ в 2015 году в качестве специалиста по работе с клиентами и проработал там шесть лет, уволившись в роли начальника отдела проектов по развитию бизнеса.
У начальника отдела проектов хотелось бы, конечно узнать — доведен ли до завершения хотя бы один проект. Тот, ради которого всё и затевалось...
Просто оставлю это https://habr.com/ru/articles/719610/
R2000 это процессор созданный МЦСТ по классической risc out-of-order микроархитектуре со спарковской системой команд. Как видно из статьи он на адекватных тестах сопоставим или лучше эльбрусов. При этом ресурсов подозреваю в него было вложено на порядок меньше. А e2k и VLIW уже пора закопать, они не то что пахнут, а уже труп начал разваливаться на части.
Не нашел там сравнения с эльбрусами, как и адекватных тестов в целом.
https://www.7-cpu.com/ - вот здесь например 8 ядер 2Ггц МЦСТ-R проигрывают в два раза 8С. Но это в целом не важно, любой процессор мцст может максимум выдавать то что максимум может выдать инженеры мцст на данный момент, никакой рязани или интел-ксеон-платинум не будет просто от того что in-order vliw поменяют на out-of-order risc.
Но, что важно, прекрасно знают устройство и того и другого и делают осознанную ставку именно на e2k, полагаю потому что он банально интереснее. И пользователям и разработчикам, и с программной и с аппаратной части, там есть куда рости и огромное поле для фантазий и экспериментов. А спарк кроме военных не интересен никому, для него даже в современных браузерах поддержки нет.
Out-of-order архитектуру можно развивать. VLIW это гроб без ручки, который выпилили, практически ото всюду, где он когда либо был. Можно долго рассуждать почему это так с теоретической точки зрения, но это довольно очевидно, если понимать как работают разные микроархитектуры, прежде всего OoO.
Очевидно, надо делать не то что интересно, а то что эффективно и нужно потребителям/пользователем. Разработка собственных архитектур микропроцессоров в союзе, погибла и проиграла x86, во многом потому, что академики делали то что им "интересно". Условно говоря, RISC против "Сетуни".
Спарк поддерживается гораздо лучше e2k, просто потому, что любое положительное число будет лучше нуля. "Эльбрус" это просто относительно раскрученный бренд, там где дают деньги.
Согласен. Однако, RISC придумали два академика, один из Беркли, второй из Стенфорда. WLIV придумал еще один академик, из Йельского, слегка позаимствовав часть идей у академиков из СССР. Проблема в том, что не всё, что придумывают академики является жизнеспособным и практичным. RISC выстрелил, VLIW - нет. Наши академики уцепились за WLIV и прогадали. То, что VLIW концепция не годная для ЦП общего назначения во всем мире стало понятно и очевидно всем к 2009 году - когда Трансмета не смогла продемонстрировать ровным счетом никакого прогресса, а Интел фактически отказался от Итаниума. Но наши академики ошибку признать не смогли, продолжали (и продолжают) доказывать необходимость и полезность этой идеи для государства и общества, получают финансирование и пилят эти гири, при этом списывая все неудачи на "оптимизирующий" компилятор который никак не могут дописать эти никчёмные программисты (и чему их там в ВУЗах только учат!?). На западе, периодически, академикам по рукам дает "рынок" и вынуждает двигаться в другом направлении. У нас такого "естественного отбора", к сожалению, не сложилось.
Если бы в начале 2000-х МЦСТ сместил акцент в сторону RISC (SPARC), после выпуска первых камней, то у нас сейчас был бы вполне годный и мощный, по современным меркам, процессор на открытой архитектуре с хорошей поддержкой софта и перспективой развития. Вместо этого имеем очень странный нишевой вычислитель на закрытой архитектуре, которую больше некуда улучшать - все дальнейшие улучшения это отказ от VLIW и движение в противоположную сторону. Осталась одна надежда на ЯДРО и их проект микропроцессора на базе RISC-V.
PS: Я не совсем понимаю зачем Макс накатывает на СКИФа. Да, этих камней выпущено не много, но так и Эльбрусов-то тоже почти нет (что такое 10 тыс шт?). Так что и МЦСТ, и Элвис, и Байкал Электроникс, да и все остальные наши разработчики микросхем сейчас сидят в одной тонущей лодке. В место того, что бы грызться за подачки от государства им следовало бы обьединить усилия поприжав амбиции. Ан нет.
По поводу академиков. У меня есть мнение, что там(на западе) получалось в среднем лучше, просто потому, что их академическая наука была в бОльшей степени ориентирована на коммерцию, а не только военных. И поэтому понимала, чем живет индустрия и какие реальные проблемы стоят.
Архитектура же e2k и VLIW(и Эльбрус-3 который не пошел в серию), насколько я понимаю, это детище одного человека - товарища Бабаяна, который в 200х наобещал с три короба, а потом свинтил в Intel(когда вся эта шумиха с Итаником имела место быть).
Не пора ли уже наконец-то сказать "Хватит разврата!" и закопать стюардессу?
По словам Максима, Intel подвержен уязвимостям Spectre и Meltdown за счёт особенностей своей архитектуры, а «Эльбрус» — нет, потому что в нём отсутствует предсказатель переходов. С одной стороны, это минус, потому что процессор из-за этого работает медленнее. С другой — это не допускает уязвимость.
Только вот Э32С будет иметь предсказатель перехода.
Есть чудесная аналогия, что процессор «Эльбрус» — это суперкомпьютер, ужатый в один кристалл, а процессор Intel — это процессор для калькулятора, который разросся до процессора для суперкомпьютера.
Аналогия действительно чудесна. Но по какой-то неведомой причине в Топ 500 что только не стоит, Зеоны, Тредрипперы, Армы и даже кое-где остались СПАРКи но только не Эльбрусы. Странно что он в этом интервью еще на Ядро и RISC-V не пожаловался.
Elбрус, или Как дела с микроэлектроникой в России в 2023 году