МЦСТ раскрыл исходные коды компонентов Linux, системных библиотек и ПО для платформы «Эльбрус»

на том же сете инструкций.

На сколько процентов должен отличаться набор инструкций чтобы его можно было называть «своим»? Должны ли отличаться названия мнемоник, опкоды или то и другое?

Это я к тому,что у «обычных» процов, не vliw, затруднительно придумать что-то особенное,отличное от других. Можно инструкцию помещения данных в регистр назвать load вместо move,можно назначить ей другой двоичный опкод, но смысл-то ее от этого не поменяется. Как и большинства других основных используемых инструкций. И даже если начать придумывать что-то достаточно экзотическое то всё что смысл имеет - уже придумано и где-нибудь внедрено.

Вышенаписанный абзац наиболее очевиден тем кто достаточно долго и много имел дело с микроконтроллерами. После вдумчивого изучения первых одного-двух - остальные осваиваются легко и быстро по аналогии,ибо различия по большей части «косметические».

Так что вопрос не в том,как инструкции называть,а в том насколько эффективно они будут реализованы в кристалле.

Кстати - эффективность это вопрос отдельный. Её можно мерить очень по-разному. И совершенно не факт что самый быстрый проц окажется самым экономически выгодным. Вон у Интела самый мощный проц стоит около полусотни тысяч рублей. И что-то не видно чтобы его массово закупали ни в офисные ни в домашние компы. Потому что нет экономического смысла тратить на это лишние деньги. Для этих компов покупают куда более скромные процессоры. Вот и нам надо бы ориентироваться не на топовые процы,а на самые массовые. Я кстати не смог сходу нагуглить - каких именно процов Интел продает больше всего.

На сколько процентов должен отличаться набор инструкций чтобы его можно было называть «своим»? Должны ли отличаться названия мнемоник, опкоды или то и другое?

А никто толком не знает. Но ARM и RISC-V друг от друга отличаются достаточно, чтобы никто не пытался засудить реализующих RISC-V (ну, до сих пор).

Так что вопрос не в том,как инструкции называть,а в том насколько эффективно они будут реализованы в кристалле.

С точки зрения закона какой instruction set ты реализуешь. Если этот IS похож на ARM, тебе придется им заплатить.

Вот и нам надо бы ориентироваться не на топовые процы,а на самые массовые.

К этому всё и идёт

https://stimul.online/articles/interview/iz-kolei-arm-k-zvezdam-nad-elbrusom/

Кстати, цикл «Автоматизация программирования в СССР»

Обзор забытых теоретических результатов

https://www.youtube.com/watch?v=0bTdplAlGYg

Трансляторы

https://www.youtube.com/watch?v=Q2ErYDuVAWo

Есть над чем подумать.

Очень странно слышать «массовые процессоры» от компании, которая их даже свободно не продает. RISC-V можно купить буквально где угодно, Эльбрус только после проверок и согласований. И если будет готовая партия, да.

Лицензирование ядер «Эльбрус». Ссылка на интервью Покровского выше.

Да, я читал, но это совсем упоротая история: лицензирование МЦСТшных ядер, поддержки которых нет в Linux, которые проигрывают ARM по энергоэффективности и завязаны на подсанкционного вендора. Я понимаю что парни немного на своей волне, но куда именно они хотят их продать? В Китае куча своих разработок, в Европу их сейчас просто не пустят. Осваивать таджикский рынок? Так они свой освоить не могут.

Развивающиеся рынки Африки, Латинской Америки, Ближнего Востока, Средней и Юго-Восточной Азии.

За энергоэффективность, в том числе в гибридных процессорах, будут отвечать ядра RISC-V, о чём также было сказано.

Развивающиеся рынки Африки, Латинской Америки, Ближнего Востока, Средней и Юго-Восточной Азии.

Африка разве что.

Иран сотоварищи никак не поможет с TSMC. Средняя Азия это Таджикистан с Туркменестаном, которым все это не факт что интересно. И Казахстан, которому вряд ли захочется санкционных рисков.

Юго-Восточная Азия это Япония, Китай и Индия. Япония выпадает по очевидным причинам, Китай вот уже два года как показывает насколько сильно им интересно видеть конкуретнов у себя на рынке (hint: вообще не интересно), Индия пилит свои RISC-V и им и так нормально.

За энергоэффективность, в том числе в гибридных процессорах, будут отвечать ядра RISC-V, о чём также было сказано.

В это я верю, только к Эльбрусу это никакого отношения не имеет.

Создаётся альтернатива х86 и ARM из e2k и RISC-V для желающих избежать зависимости от западных технологий. Хороший для освоения рынок. Особенно, когда есть уже готовые решения.

Остаётся выяснить зачем миру «русский risc-v» при наличии у них своего :) И каким боком тут arm…

Затем, зачем и раньше. Готовые решения.

https://cloudbear.ru/products.html

https://syntacore.com/products

Они ещё не под санкциями?

Создаётся альтернатива х86 и ARM из e2k и RISC-V для желающих избежать зависимости от западных технологий. Хороший для освоения рынок. Особенно, когда есть уже готовые решения.

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

Санкции касаются западных разработок, а это «доморощенные».

Как альтернатива х86-64.

Как альтернатива х86-64.

Так его производить не могут. Поцоны говорят: мы короче его начнем экспортировать, а все остальные его пропушат в TSMC и тот его печатать будет. В этом блестящем плане есть большая дыра: чтобы начать его пушить в TSMC, его надо сперва продать. Чтобы его продать, его надо произвести. Чтобы его произвести, нужен TSMC. Видишь проблему?

Эта история просто очень напоминает Сухой Суперджет – чуваки сделали в общем-то неплохой самолет, только вот запчасти к нему надо было ждать по полгода и никто к такому готов не был.

Санкции касаются как импорта технологий, так и экспорта. Ничто не мешает обвинить указанные компании в работе на оборонку и наложить на них санкции. Кроме того мне просто непонятно откуда вообще появилась мысль, что МЦСТ собирается разрабатывать процессоры на risc-v или как-то интегрировать эту архитектуру в Эльбрусы, т.к. не очень понятно зачем это нужно, причём как самому МЦСТ, так и всем остальным, ибо готовых предложений на risc-v и без МЦСТ вагон и маленькая тележка. Если такие выводы делаются на основании заявлений Покровского, то я бы заявления этого человека, являющегося ярым защитником концепции «международного разделения труда» и который и к МЦСТ-то не имеет никакого отношения, смело делил бы на два. Или есть какие-то более определённые сведения на этот счёт?

В статье прямым текстом сказано

И российская компания МЦСТ, в принципе, может идти в этом же направлении — предложить своим партнерам и заказчикам использовать технологии микропроцессоров «Эльбрус». Сразу оговорюсь: это мое предположение, а не позиция МЦСТ.

Идея лицензировать «Эльбрус» вполне рабочая.

Идея лицензировать «Эльбрус» вполне рабочая.

Она рабочая в мире, где любой экспорт не накрывает санкциями через два месяца. В мире, где накрывается, это буквальная аналогия sucide by cop.

Седьмое поколение «Эльбрус» уже существует на ПЛИС. Фабрика для разработки не потребовалась.

https://www.youtube.com/watch?v=O2VcGGbualY

CloudBEAR и Syntacore свои RISC-V ядра также разрабатывали и лицензировали.

Про лицензирование собственных ядер – это понятно. Меня вопрос «гибридных процессоров» интересует. Это откуда?

Собственных технологий санкции не касаются.

Но следует иметь в виду, что рынок центральных процессоров общего применения уже много лет стагнирует. А рынок специализированных процессоров, в разработке которых комбинируется использование самых различных ядер разных архитектур, развивается, напротив, стремительно. Так что на ближайшую перспективу не видно прямого противопоставления линий развития на основе «Эльбрус» и на основе RISC-V, а напротив, скорее всего, будет увеличиваться взаимное проникновение этих решений друг в друга. При этом процессоры x86 будут постепенно терять долю рынка.

Собственных технологий санкции не касаются.

Ну да, конечно…

Фантазии Покровского.

Они их не касаются, потому что их нет. РФ не экспортирует технологии, кроме ядерной энергетики. На которые, санкции как раз начинают вводить.

И RISC-V собственной разработки и «Эльбрус» имеются. Есть что лицензировать.

CloudBEAR и Syntacore свои RISC-V ядра также разрабатывали и лицензировали.

Синтакор как раз делает все правильно – он пилит свои дизайны и нарабатывает компетенции, ориентируясь на заказчиков, которым он хотя бы продать может. Причем синтакору будет проще, потому что он может сделать прокси-компанию Брахман и Копыта в Индии, заключить контракт с TSMC через неё и спокойно печатать, добавив процентов 15% за молчание индусам. У МЦСТ так не получится.

СнК с разными типами ядер давно данность. Концепция процессора с комбинацией из энергоэффективных и производительных ядер тоже. Гибридный «Эльбрус» уже был.

http://mcst.ru/Elbrus-2C-plus

Только в 2С+ родные ядра дополнялись dsp-ядрами от Элвиса, причём эксперимент признан неудачным, т.к. заказчик так и не научился с ними работать. А из вашей с Покровским концепции выходит что родныя ядра Эльбруса будут дополняться обычными ядрами risc-v, что в свете эволюции собственной эльбрусовской архитектуры выглядит по меньшей мере странно.

Заказчик с ними работал

https://www.vega-gaz.ru/about/news/newsitem/FQ92JDY8AS5W57DS

Если у них был этот процессор - не значит что они пользовались всеми его возможностями.

Ключевое слово – «работал»

Да и работает

https://ipmce.ru/projects/semeystvo-bortovykh-tsifrovykh-vychislitelnykh-mashin-btsvm/

Если этот IS похож на ARM, тебе придется им заплатить.

Вот я и поинтересовался - как определяется «похожесть»? Гонорарами юристов?

А то ведь патенты - штука такая. Кто-то там патентовал скруглённые углы у корпуса смартфона. Так и тут: «у вас используется наша инструкция mov - это нарушение нашего патента,платите охренилиард денег».

РФ не экспортирует технологии, кроме ядерной энергетики.

Ядерную таки нет.

А вот кое-что другое таки немножечько да. Через третьи страны под сcанкцыями РФ.

Не, ну может где-то и работает, свечку, как говорится, не держал… Факт в том что в МЦСТ от подобного подхода отказались ввиду его невостребованности, и больше подобных процессоров они не делали. К тому же это ведь были специализированные ядра, тут хотя бы понятно зачем они их встраивали, а какой смысл делать гибрид из е2к и risc-v? Чтобы в качестве ядер общего назначения использовать risc-v, а в качестве DSP использовать теперь уже родные эльбрусовские ядра? :) Так в МЦСТ вроде и свои ядра нацелились развивать в сторону ОоО, и не факт что после всех доработок они вообще сгодятся на роль DSP… Для экономичности, по аналогии с интеловскими e-cores? Но как по мне, то из всей той критики что адресуется Эльбрусам, их энергопотребление стоит на последнем месте. Вообще ни разу не слышал, чтобы кто-то на это жаловался. Кроме того я себе слабо представляю как на столь разнотипных ядрах вообще может что-либо работать, ведь тут ядра будут отличаться не только функционально (как в интелах), но и архитектурно… В общем как по мне, то идея создания гибрида из е2k и risc-v довольно странная. Я бы даже сказал подозрительная.

Ядерную таки нет.

Ещё как да, РФ строит несколько АЭС по заказу других стран.

РФ строит несколько АЭС по заказу других стран.

Давайте вам дядя Федя поставит вытяжку на кухне? А вы после этого будете решать уравнение Навье–Стокса с веселыми граничьными условиями, сделаете на коленке такие же вытяжки соседям и т.д.? Ну вы понели (с)

Давайте вам дядя Федя поставит вытяжку на кухне? А вы после этого будете решать уравнение Навье–Стокса с веселыми граничьными условиями, сделаете на коленке такие же вытяжки соседям и т.д.? Ну вы понели (с)

Я правильно понимаю что ты сейчас АЭС с вытяжкой сравнил?

Я правильно понимаю что ты сейчас АЭС с вытяжкой сравнил?

Типа хинт: АЭС таки немножечько сложнее вытяжки, там одним Навье–Стоксом не обойдешься.

Типа хинт: АЭС таки немножечько сложнее вытяжки, там одним Навье–Стоксом не обойдешься.

Ну вот видишь, а то паясничать начал.

Вы для начала соседям сделайте сами что-нибудь смешное, например, вытяжку. А потом расскажете за экспорт технологий. Если захочете (c)

Неумелая попытка выдать желаемое за действительное. АРМ уже нацелился на рынок высокопроизводительных систем и Риск5 идёт туда же.

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

Удивительное дело, пока мучали эльбрус, тот же Интел, на который всегда смотрели, успел развить и похоронить несколько концептов, у нас же вцепились во влив мёртвой хваткой.

идея создания гибрида из е2k и risc-v довольно странная

Нельзя просто так взять и закрыть тему влив, надо чтобы заказчик в лице вышестоящего начальства сам это сделал. Причины я описывал выше по треду.

МЦСТ не может сказать, что влив это плохо, если такое ими будет сказано, руководство МЦСТ посадят за вредительство, потому что они тридцать лет развивали вредительскую архитектуру тратя на неё государственные деньги. Поэтому МЦСТ всегда будет заявлять, что влив это зашибись.

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

Развитие техники в России вообще редко обусловлено вопросами эффективности и прогресса

В общем как по мне, то идея создания гибрида из е2k и risc-v довольно странная. Я бы даже сказал подозрительная.

Делай раз: гибрид E2K + RISC-V

Делай два: порт всего на RISC-V, все довольны

Делай три: «Ой, чет RISC-V хорошо получился, давайте закопаем E2K»

Где в указанной вами статье указано, что DSP реально используется?

Нигде, он опять выдает желаемое за действительное. Вам обоим это свойственно, но я за правду, а не против личностей.

Для БЦВМ Э4 было принято решение разработать цифровой сопроцессор обработки сигналов (ЦСОС) на базе МНМ с ПЛИС и АЦП, вынесенным на мезонинный модуль стандарта FPGA Mezzanine Card (FMC).

То есть вместо использования встроенного DSP они сделали внешний модуль. Могли, конечно, оба использовать, но чет акцент на модуле есть, а на DSP внутри прекрасного эльбруса нет.

Типа хинт: АЭС таки немножечько сложнее вытяжки, там одним Навье–Стоксом не обойдешься.

Ну вот видишь, а то паясничать начал.

И шо ж вам таки надо все разжовывать?

Поставка готового изделия и обучение его эксплуатации не значит, что эксплуатант научиццо сам производить изделие. И, тем более, не поимеет полный цикл его производства и эксплуатации.

Где в указанной вами статье указано, что DSP реально используется?

Его часом не для ГАК делали?

// Кто угадает правильный ответ, тот уедет на сэмь лет (с)

Поставка готового изделия и обучение его эксплуатации не значит, что эксплуатант научиццо сам производить изделие. И, тем более, не поимеет полный цикл его производства и эксплуатации.

Ну вот видишь, сам придумал, сам оскорбился. Никто же не утверждал что РФ учит людей строит АЭС, правда?

Никто же не утверждал что РФ учит людей строит АЭС, правда?

Экспорт технологий именно про это.

Экспорт технологий именно про это.

Про строительство АЭС? А, ну ладно тогда.

Экспорт технологий именно про это.

Про строительство АЭС?

Ойц, а шо ж ви сразу не сказали за строительство?

Экспорт технологий это именно за научить, да.

Экспорт технологий это именно за научить, да.

Да-да, научить строить АЭС. Других технологий там нет. Окей-окей, бро, ты победил.

Да-да, научить строить АЭС. Других технологий там нет.

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

«Эльбрус», как альтернатива х86-64, никуда не денется. RISC-V уже вытесняет ARM из микроконтроллеров.

Приводил пример БЦВМ на Эльбрус-2С+ и 4С, где и в случае 4С потребовалась дополнительная установка DSP сопроцессора. Хотя, в большинстве случаев производительности 4С уже хватало, но не в этом.

https://ipmce.ru/projects/semeystvo-bortovykh-tsifrovykh-vychislitelnykh-mashin-btsvm/

В дальнейшем, в МЦСТ разрабатывали гибридные процессоры (1С+, 2С3) уже с видеоядрами, как более универсальные для всех видов применения.

Свежий пример это процессорный модуль МП21 для БЦВМ и ПЛК

http://www.sm1820.ru/2024/01/16/mp21/

И вычислительный модуль 1Э2С3-TmITX для рабочих станций

http://www.mcst.ru/1E2C3-TmITX_TVGI.469555.480

А арм уже вытесняет х86

Делай три: «Ой, чет RISC-V хорошо получился, давайте закопаем E2K»

Ага, вот-вот. И что-то мне подсказывает, что подобные идеи проистекают вовсе не из МЦСТ, а скорее из лагеря лоббистов risc-v, дабы создать иллюзию единодушного согласия общества в перспективности и безальтернативности risc-v и нежизнеспособности и бесперспективности Эльбрусов. Знаю я одного блогера, так вот он тоже всю дорогу мечтает об объединении risc-v и e2k в одном процессоре.

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

Для этого у МЦСТ есть Спарки. Если Эльбрусы до сих пор не выбросили, значит заказчика они устраивают.

Для этого у МЦСТ есть Спарки. Если Эльбрусы до сих пор не выбросили, значит заказчика они устраивают.

Древние спарки всё еще не выбросили и продолжают развивать, в том числе серверную линейку. Значит далеко не всех заказчиков устраивают прекрасные эльбрусы.

Тем не менее где-то проскакивала инфа (возможно просто слух) будто бы на Спарках в МЦСТ поставили крест и больше развивать их не будут.

Поползновения такие имеются.

Делать три не обязательно, есть задачи, которые хорошо ложатся на влив (DSP, криптография).
SoC это различные ядра для различных задач.

Интересно, Linux поддерживает работу на системе, состоящей из абсолютно разных архитектур? Или как минимум, чип в котором ядро Эльбрус + RISC-V

Я такие SoC знаю море, но там Linux лишь на какой то одной архитектуре, например MIPS ARM или PowerPC, а второй кластер ядер что то иное

Да собственно Эльбрус-2С+ таким и был, я даже пытался тыкать DSP из его состава

ПАК «Капля» (E2K+ARM+NMC4)

http://energo.bmstu.ru/news/2023/05/12/пак-«капля»

http://www.mcst.ru/4E8CB-MSWTX_TVGI.469555.448

https://www.module.ru/products/2-moduli/nm-card

На спарках все поставили крест. Несмотря на открытые сорцы, никакого интереса у сообщества не возникло. Аналогичная история была с МИПСом. Также были и другие открытые, но не взлетевшие платформы.

Это уже не поползновения, а наметившийся тренд. Х86 выдавливается армом, и уже не только Эппл. А риск5 наступает на пятки арму и разработка новых, всё более производительных ядер ведётся с нарастающей интенсивностью.

Пока ещё нет

https://youtu.be/jVFqWTyif4k?t=1128

Цитата из видео - вот когда они сделают для серверов… И мое дополнение - в очередной раз скажем, что обделались и отстали, не увидели современных тенденций. Ничего необычного. Никогда такого не было и вот опять.

Я за свою жизнь уже столько раз видел.

Что мешает вам увидеть эти тенденции и занять перспективную нишу.

НИИЭТ сегодня опять/снова выкатил еще один МК двухъядерный на RISC-V под 200 МГц

Должен же под 300 МГц быть и работать в паре с «Эльбрусом».

Отсутствие нескольких миллиардов долларов и связей в правительстве

Разрабатывать это не мешает. Искать инвесторов тоже, если направление перспективное. Или поучаствовать в составе уже действующей команды, «Ядро» например. От причитаний ничего не изменится.

Кстати, вечером в куплете

МЦСТ раскрыл исходные коды компонентов Linux, системных библиотек и ПО для платформы «Эльбрус» (комментарий)

Утром в газете

https://t.me/elbrus_pc_test/339

Рабочая станция «1Э2С3» собственной персоной

http://www.mcst.ru/1E2C3_TVGI.466256.022

И пусть никто не уйдет обиженным.

По Европе доставляете?

Ну, насчет МИПСа у кЕтатайцефф есть другое мнение :) — https://en.wikipedia.org/wiki/Loongson

Китайцев много и всех их надо чем-то занять. У нас другая ситуация.

Loongarch такой же RISC как ARM. Идейная основа у них одинаковая.

MIPS - это самая примитивная реализация RISC идей. Поэтому проиграла конкурентную борьбу.

В ARM много всяких улучшений, которых в RISC не было. Причём 32-бит ARM более интересный, потому что имеет включение инструкций по флагам (в e2k есть подобное с предикатами), в 64-бит ARM (AArch64) лишь несколько инструкций таких оставили. Наверное потому, что компиляторы так и не научились эту фичу эффективно использовать. Но если писать ассемблерный код вручную, то было очень удобно.

RISC-V это попытка продать MIPS заново, точнее подсадить всех на него как халяву. Плохо то, что никаких выводов из провала MIPS не сделали и повторили его недостатки.

Так вот Loongarch таки получше будет, чем MIPS и даже RISC-V. Хотя получился каким-то «академическим проектом», похоже набор инструкций составляли люди, которые далеки от практики. Поэтому добавили много всего, что использоваться не будет. И про некоторые инструкции наоборот забыли.

Будут процессоры на сравнимых частотах, будут компиляторы, — тогда и посмотрим, что «более интересно», а что нет. Живого Loongarch я не видел, и как используют инструкции с флагами ARM — тоже.

Писать код для RISC руками — дело последнее. В свое время я решил, помнится, «оптимизировать» внутренний цикл шифрования ГОСТом для Альфы. Уложил простую замену в 16 инструкций. Потом посмотрел, что делает компилятор С. Получил 15 инструкций и более эффективно. После этого я завязал писать что-то серьезное кроме учебных задач на ассемблерах RISC.

В 32-бит ARM даже три фичи, что пропали в AArch64:

1. условное выполнение команд по флагам
2. сохранение/загрузка регистров пачкой, в AArch64 осталось лишь по паре за раз
3. thumb режим

Видимо решили сделать шаг назад к Reduced, возможно это упростило процессор.

Вот мой рейтинг RISC архитектур:

MIPS: г-но
RISC-V: то же г-но, зато бесплатно
Loongarch: не так уж и плохо, но запашок MIPS остался
AArch64: 64-бит, но урезанный по фичам в сравнении с 32-бит ARM
ARM: самое навороченное

Кстати есть еще бесплатный OpenRISC, о котором никто не знает (RISC-V не был первым открытым). Но китайцы производят для всяких мелких девайсов. Возможно неплохо распространён, но его даже в спеках прямо не указывают, просто как 32-бит RISC. И еще может быть множество закрытых RISC, о которых совсем ничего не известно.

По Европе доставляете?

В составе изделий?

Этот рейтинг предпочтения на основании чего? Вкусов? Производительности? Простоты написания компилятора? Количества имеющегося ПО?

Опенриск известен давно, как и перелицовки спарка и мипса, но не взлетел. Даже движуха вокруг него какая-то была, но затихла.

Сложно судить, я думал, что проект оказался не слишком обещающим

От most Reduced до most Advanced. Производительность прямо не зависит от набора инструкций, зависит от реализации в железе (количество транзисторов и техпроцесса), но если набор инструкций примитивный как у первых в списке, то влияние будет и на производительность.

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

Ну тогда еще Альфу в Reduced запиши. Она была первой :)

Другое дело что у слишком редуцированнх архитектур возможности улучшения компилятора быстро закончатся

А это не есть плохо, КМК. Если процессор в сорок инструкций способен сделать то же самое по производительности, что и процессор в восемьдесят инструкций, то нахрена вторые сорок второму процессору? Это, конечно, очень грубое обобщение, я понимаю, что шина, предвыборка, конвейеры итд... Но! Внешнему наблюдателю это все более-менее параллельно. В 90х годах у нас в «Анкее» чего только не было, в диапазоне от Вакса до AS/400 и Тандема. Так вот, при сравнении Интеллов и младших альф с DECsystem на MIPS, MIPS почему-то выигрывал. Общее было мнение, что «шустрая машинка». У нас на ней корпоративный документооборот крутился.

Так вот, при сравнении Интеллов и младших альф с DECsystem на MIPS

Думаю тут случай сравнения архитектур разных категорий и цены (потребительские и рабочие станции). Возможно и разрядности, Интелы были 16-битные еще? Я ведь и написал что зависит от реализации в железе. В итоге история показала что слишком Reduced проигрывает.

Ну в 1997-то? Четверки, кое где пни уже попадались. Ну цены меня тогда не сильно интересовали. Я прекрасно понимал, что на то, что стоит у меня на столе, мне много лет тогда работать надо было. А всего-то кластер из двух младших альф под разработку.

Ну 32-бит, но персоналки. Интел тогда еще не успел наворотить сложных конвейеров, но уже начинал.

Ну все крупные производители тогда и сервера уже делали многопроцессорные на интелах. Типа шина EISA, два пенька... :)

Всё же вы сравниваете CISC и RISC. В гибели MIPS скорее всего привело развитие архитектуры ARM, когда это стало давать преимущество и MIPS перестали покупать. Сначала MIPS вытеснили в нишу дешевых микроконтроллеров, но ARM пришел и в эту нишу.

Арм изначально вышел из ниши дешёвых микроконтроллеров, а мипс умер на sgi

Гибель MIPS несколько преувеличена. См. роутеры от D-Link, например. Мой DWR-980 вполне себе имеет в пузе MIPS.

Мне не интересно в данном контексте сравнивать архитектуры, я лишь говорю, что «говно» с Вашей точки зрения не есть всегда «говно» с пользовательской. Пользователю пофиг, лишь бы за его задачами машинка успевала.

Сначала MIPS вытеснили в нишу дешевых микроконтроллеров, но ARM пришел и в эту нишу.

Тут вопрос тиража и цены этих микроконтроллеров. Пришел в нишу — не значит занял ее полностью.

В рутерах давно уже армы

Арм изначально вышел из ниши дешёвых микроконтроллеров

Всё верно, ARM улучшался и улучшался, постепенно захватывал новые ниши. Микроконтроллеры, промышленное оборудование, смартфоны, сервера, персональные компьютеры. MIPS выгнали в микроконтроллеры, а потом пришли и туда со специальными моделями Cortex-M.

Гибель MIPS несколько преувеличена. См. роутеры от D-Link, например. Мой DWR-980 вполне себе имеет в пузе MIPS.

У меня тоже роутер на MIPS есть. Но он дешевый. По лицензиям MIPS еще долго могут штамповать или использовать складские запасы. Тут факт что некогда топовая архитектура скатилась до использования в самых дешевых устройствах и нигде она больше не нужна.

Сейчас, наверное, да. Но, вот в моем MIPS. И ниччо, работает. :)

Ну вот мой был топовым в свое время. Типа ADSL, WAN и LTE (с гнездом для симкарты). Дешевым не назовешь.

Не только лишь

https://www.youtube.com/watch?v=-UxnQyokM9M&t=2269s

С нативной AltLinux, поддерживающей расширения loongarch64

https://www.altlinux.org/Ports/loongarch64

Не говоря уже про Комдив-32 и 64, но это отдельная тема.

Это все хорошо. А где компушку-то с этим камнем купить можно?

Это все хорошо. А где компушку-то с этим камнем купить можно?

На али продают.

Которые показаны в видео

https://servers.norsi-trans.ru/catalog/servers/loongson/

Могу дать ссылку на магазин, где продают х86. Нам-то что с того? Китайцы молодцы, но камень закрытый. Хотят - продают, а хотят нет.

Если вы в плане того, что когда х86 станет совсем трудно приобрести, пересядем на Китай? Да, так и будет.

Также прошивки с поддержкой New World

https://github.com/loongson/Firmware

На примере платы платы LS3A5000-7A2000-EVB

https://rutube.ru/video/5ed8f626d074255c911c336603b37236/

Ну есть и хорошо. Мне на жизненном пути пока не попадались. Я люблю «все, что не Интел». Увижу — посмотрю с интересом.

Я люблю «все, что не Интел».

• Гиви, ты памидор любишь?

• Покушить да, а так нэт.

// Музыкой навеяло.

Работа такая, приходится любить и крепко

Альт сделали нативную поддержку loongarch64, в ранее приведённом видео об этом детально рассказано. И поддерживают актуальное состояние.

Ну типа того. :)

Китайцы молодцы, но камень закрытый.

Поддержка архитектуры есть в GCC. Документация для процессора есть, но не совсем полная, и это кривой перевод с китайского. Тем не менее, камень куда более открытый, чем e2k.

Если интересно, то вот тесты процессора Loongson 3A6000

https://habr.com/ru/companies/icl_group/articles/784642/

И небольшой обзор изделий на его основе

https://habr.com/ru/companies/selectel/articles/807433/

Закрытый в том же смысле, что и х86. Мы не можем его произвести, а купить только если его продадут. Попадет китайцам вожжа свернуть производство и всё.

Импортозамещение - заместили Интел на Китай.

Китайцы молодцы - взяли мипс и переработали. Выбросили ненужное, добавили нужное и вот уже получили камень сравнимый с топовыми х86. А в России так не могут, потому что в России Эльбрус

В России есть «Комдив», также созданный на базе MIPS32/64. У Loongson есть существенный недостаток по сравнению с «Эльбрус» это отсутствие поддержки х86-64 для поэтапной миграции с одной платформы на другую. Хорошо, что есть «Эльбрус».

У Loongson есть существенный недостаток по сравнению с «Эльбрус» это отсутствие поддержки х86-64 для поэтапной миграции с одной платформы на другую.

Ой не уверен я, что это недостаток.

Во-первых, эта самая бинарная трансляция усложняет систему в целом.

А во-вторых, был ряд историй, когда вылезали «тестеры», заявлявшие, что Эльбрус дико тормозит… а потом выяснялось, что запускали они свои тесты в том самом режиме трансляции. Поскольку нужное им ПО существует только для x86, а отдуваться у них за это должен, конечно, Эльбрус.

А можно сделать прогноз, когда рынок России завалят эльбрусами? Или хотя бы все-все госучреждения пересадят на него? )

Я выше давал ссылку на статью, где было такое предположение:

что в 2024 году Эльбрусы, Байкалы и прочие чипы, требующие техпроцесса тоньше 90 нм, полностью перейдут на соответствующий техпроцесс континентальной китайской фабрики, скорее всего SMIC, а массовый их выпуск, скорее всего, придётся на 2025-26 годы.
Представлен МП21 -- одноплатный компьютер на базе процессора «Эльбрус-2С3» (комментарий)

Но видел и такое интервью, где предлагают перейти к бесфабричной модели, типа как arm, торговать лицензией и поддержкой, перед этим всех ‘подсадив’ на эльбрусы.

*Глава Ассоциации российских разработчиков и производителей электроники Иван Покровский

Совместимость с х86-64 решила ключевую проблему с запуском проприетарных ОС, приложений и драйверов на платформе «Эльбрус», ввиду отсутствия возможности их переноса в нативный режим.

Долгое время 1С:Бухгалтерия в МЦСТ на «Эльбрусе» работала в режиме трансляции х86-64, который оказался настоящим подспорьем.

Например, сейчас ввиду сложности портирования браузеров, выручает режим трансляции RTC.

https://t.me/ElbrusMCST/47

Когда будет массовое производство.

А во-вторых, был ряд историй, когда вылезали «тестеры», заявлявшие, что Эльбрус дико тормозит… а потом выяснялось, что запускали они свои тесты в том самом режиме трансляции. Поскольку нужное им ПО существует только для x86, а отдуваться у них за это должен, конечно, Эльбрус.

Лулз в том что недавно постили бенчмарки, где софт в эмуляции работает быстрее чем нативно.

Ничего удивительного, так как это 7-Zip, который годами оптимизировался для х86-64. Поэтому в режиме двоичной трансляции и работает лучше. Давно известный нюанс.

Да, в составе системного блока.

Чтобы проводить поэтапную миграцию, надо всего-то

1. Чтобы он был
2. Чтобы он был кому-то нужен

Пока что всё идёт к тому, что будем портировать на китайцев без х86. Хорошо, что есть Эльбрус

Когда будет массовое производство.

А когда оно будет? Вот в 2022 была новость о том, что TSMC отвалился, и только обсуждалось (!), что производится процессоры будут в Китае.

Так они уже производятся? Удалось договориться? Какие-то подвижки в этом направлении есть?

А почему его не было до 2022? Я щупал системник с Эльбрусом в Я.Музее еще в 2018, кажется, оно уже тогда было условно готово. Что мешало?

Комдив совсем не в кассу. Это стойкий чип для спецприменения со спецосью багет. Хотя и на него уже поругивались за недостаточную производительность

Он есть

https://t.me/elbrus_pc_test/339

Ой ли

https://ibb.co/hL44510

Что на счет моего вопроса о производстве?

Ничего.

Ничего.

Ясно. То есть, никакого производства нет, иначе ты бы радостно забросал меня ссылками.

Как обычно, «скоро» и «будет».

Смирись.

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

Чорд. Мну аж прослезился. За державу обидно, да.

Вы не поверите, но у PPC нет никакой поддержки Motorola 68000, у x86 нет никакой поддержки PPC, а у ARM нет средств поддержки x86. И это никак не помешало одной известной фирме сделать сначала Розетту, а потом Розетту 2. и сменить уже 5 процессоров. Я уж не говорю о том, что средств поддержки VAX у альфы тоже не было, а тулза для бинарной трансляции программ для VAX в альфовые — была. Так что это сомнительное достоинство.

Это конкурентное преимущество.

Отнюдь. Вот когда gcc с clang'ом научатся генерить код для Эльбруса «искаропки», тогда и поговорим о конкуренции.

Технически ничто не мешает. Они прикрутили бэкенд от LCC к LLVM внешним интерфейсом, но поскольку исходники не открыты, LLVM с этими костылями и патчами мягко послали их. У LLVM все задачи компилятора должны решаться самим проектом LLVM, а закрытый бекенд противоречит принципам открытого ПО.

Короче, вот когда откроют - тогда и поговорим.

Собственно

https://t.me/ElbrusMCST/37

Добавлю к предыдущему посту: https://habr.com/ru/articles/739394/

Еще раз — «искаропки». Насколько мне известно, компилятор для эльбруса закрыт.

И что? Хочу собрать что-то кроссом для Эльбруса не вставая с любимого кресла.

Так и я про то же. Пока пусть играют в своей песочнице.

Хочу собрать что-то кроссом для Эльбруса не вставая с любимого кресла.

Зачем кросс? Нет никаких проблем собирать нативно.

МЦСТ раскрыл исходные коды компонентов Linux, системных библиотек и ПО для платформы «Эльбрус» (комментарий)

Жду когда появится поддержка «искаропки» :)

Потому что Эльбрус объективно не шибко быстрый. Если подходить к вопросу серьезно, то все дистрибутивы для слабых процессоров собираются кросс-компиляцией. Например, дистры под малину тоже так собираются - берется очень мощная машина и молотит кроссом все пакеты.

https://www.youtube.com/watch?v=bKR939cyhT4

Жду когда появится поддержка «искаропки»

Из какой такой каропке?

Еще несколько лет назад шелл на e2k раздавали всем желающим. Твори, выдумывай, пробуй (с)

Прочитай вот это.

И чо?

Тыж вроде не тролль и не идиот. Не прикидывайся. :) Все ж тут обсудили, и из какой коробки, и почему в этой коробке поддержки e2k как-то не наблюдается.

Тыж вроде не тролль и не идиот.

Не, у мну другой диагноз. Проще пристрелить, да.

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

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

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

DOOM на гирогоризонте/вертиканте? Забавно-с. Херр фон Браун крутиццо в гробу как этот ваш гироскоп, да.

Программу полета вы в гироскоп будете вносить?

К гироскопам полагалось во времена оные некое аналоговое (механическое) программное устройство. Чо-то мне поцсказывает, что DOOM посложнее будет.

Тут надо с чего попроще начинать, например, с часов с кукушькой, механических пианин и т.д.

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

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

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

Зависит от полезной нагрузки. Ну вы понели.

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

А то. Успеет этот ваш линакс загрузиться до того как условный краснополь/еxcalibur долетит до точки, где ему пора корректироваться?

Потому что Эльбрус объективно не шибко быстрый.

Это lcc небыстрый, если задать ему -O2/O3.

На встречавшихся машинах e2k было столько ядер, что достаточно сказать make -j24, чтобы не думать о таких мелочах. И таки distcc никто не отменял, да.

Попадет китайцам вожжа свернуть производство и всё.

Ну прямо точь в точь как с Intel и AMD. :)

А во-вторых, был ряд историй, когда вылезали «тестеры», заявлявшие, что Эльбрус дико тормозит… а потом выяснялось, что запускали они свои тесты в том самом режиме трансляции. Поскольку нужное им ПО существует только для x86, а отдуваться у них за это должен, конечно, Эльбрус.

Ну так это уже недостаток ума знаний у тестеров...

Я-то думал

«Ну да!... Конечно!..» ©

Еще несколько лет назад шелл на e2k раздавали всем желающим. Твори, выдумывай, пробуй (с)

Ну, так нечестно! Вы предлагаете то, что доступно, а им хочется «чего-то другого!», недоступного... :)

Это lcc небыстрый, если задать ему -O2/O3.

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

и вот уже получили камень сравнимый с топовыми х86

Не фантазируйте, он уступает даже Эльбрусу при использовании всех ядер на обоих.

У Loongson есть существенный недостаток по сравнению с «Эльбрус» это отсутствие поддержки х86-64 для поэтапной миграции с одной платформы на другую.

Но китайцы это уже решают, добавили дополнительные инструкции для ускорения эмуляции x86.

Еще несколько лет назад шелл на e2k раздавали всем желающим. Твори, выдумывай, пробуй (с)

Ну, так нечестно! Вы предлагаете то, что доступно,

Это не я. Шелл предлагали из домена .ch. Золотая жила для тщей майоров, и не говорите.

Ну вы понели.

Ну да, вы её только на картинке видели.

А то. Успеет этот ваш линакс загрузиться …

Зачем ему там загружаться? GPS/Glonass они наверное на патефон принимают.

Ваша бредятина скучна.

Я могу напомнить много фирм, свернувших производство когда-то успешных камней.

Ну вы понели.

Ну да, вы её только на картинке видели.

Поцчему на картинке?

Движок Фау-2 ручьками приходилось щупать. Не помню только, оригинальный немецкий или ужэ наша реплика.

А мне зачем?? :)

Я имел в виду, что не только китайцам может что-нибудь куда-нибудь попасть...

Мы на это никак не влияем и повлиять не может, а посему и волноваться особого смысла нет. :)

Не то что бы «не шибко быстрый». Была хорошая статья на Хабре про методы оптимизации для Эльбруса на примере решения краевой задачи. Если ему индекс в массиве поменять с int на long, так перформанс уже там раза в три подскакивает, ЕМНП. Если к «уникальному процессору» приложить «уникального программиста», то результат может быть вполне хорошим на определенном классе задач. Байты молотить он может хорошо, а вот на задачах компиляции, где сплошной поиск по таблицам и переходы в конечных автоматах, так процессор проигрывает от слова «совсем», как я понимаю.

индекс в массиве поменять с int на long

Только наоборот, long на int.

В 5,4 раза

https://habr.com/ru/articles/647165/

У этого автора есть и более прикладная статья

https://habr.com/ru/articles/563308/

Не знаний, а скорее, добросовестности (хотя сами они так не считают).

Если мы рассматриваем импортозамещение как замещение импорта из стран запада на импорт из Китая, то да.

Если мы замещаем импорт отечественной продукцией, то капризы иностранных держав нас не затрагивают. Но за такую точку зрения записывают в ципсо

Да мало ли что там «считают они сами...

Тут вон тоже много кто чего „считает“. ;)

Комдив 1890ВМ108, 1890ВМ118 и графический процессор 1890ВМ128 в том числе и для гражданского применения разрабатывались.

Меня никто никуда не записывает. Ну, разве что, какая-то мелочь всё в «клоуны» вербует... ;)

Ну а так-то стоит такую возможность (спорадическое «схлопывание» товарных линеек) иметь в виду, и как-то включать в свои планы, и подстраховываться.

Ни разу не встречал даже упоминания об этом...

https://habrastorage.org/getpro/habr/upload_files/22f/472/776/22f472776219b7880fb46b04caa3632d.jpg

Ещё начиная с процессоров предыдущего поколения

https://www.niisi.ru/aryashev_komdiv642017.pdf

Все пройдут по этому пути, так или иначе.

Кстати, «Комдив» собирались объединить с RISC-V

Совместная работа НИИСИ и компании MIPS над новыми версиями процессоров с архитектурой MIPS и расширениями к ISA позволит объединить экосистемы MIPS, КОМДИВ и RISC-V 64-bit, сформировать стек новых расширений RISC-V.

https://www.electronics.ru/files/article_pdf/8/article_8867_562.pdf

Еще несколько лет назад шелл на e2k раздавали всем желающим.

И сейчас функционирует, пополнившись дополнительными серверами с ОС Эльбрус, Альт и Астра

https://elbrus.kurisa.ch/

И официальным вариантом

https://dev.mcst.ru/access/

Ну почему все? АРМы вот не идут и неплохо существуют. Даже не только на мобилках, но теперь и на Маках, и есть попытки в серверный сегмент залезть.

Кто-то выше, кажется, gns, сказал «Мне интересно, всё, что не x86». Я под этим подписываюсь. Нет, я не хочу x86 закопать, пусть живёт. Я хочу, чтобы десктоп или сервер были не обязательно x86, чтобы был выбор.

Эмуляция x86 в процессоре это позиционирование себя как догоняющего, этакий ReactOS на аппаратном уровне. Лоббирование же своей собственной системы команд куда более интересный путь. Но да, для этого и уровень открытости надо ещё сильнее поднять (может, не сейчас, может, когда вопрос с техпроцессами будет решён, это уже детали), и много ещё чего потребуется.

https://elbrus.kurisa.ch/

«Поскольку администратор будет в отпуске с 11 июля по 2 августа, запросы, поступившие в этот период, будут обработаны только после 2 августа».

Прям что-то напомнило ‘прохладные’ истории из Германии: 🙂

Я реально не понимаю, как люди в принципе могут настолько х***о планировать, чтобы была ситуация типа «б*я хочу жрать в три часа ночи, а в холодильнике пусто».

https://dev.mcst.ru/access/:

Внимание! В связи с большим наплывом желающих получить удаленный доступ к Эльбрусу, мы вынуждены временно приостановить выдачу доступа для новых пользователей. Все запросы поступившие до 10.07.2024 будут обработаны в ближайшее время.

а им хочется «чего-то другого!»

Есть и такое

https://gitflic.ru/project/e2khome/llvm-project-e-2-k

https://gitflic.ru/project/e2khome/lccrt

https://ce.mentality.rip/

https://git.mentality.rip/OpenE2K/qemu-e2k

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

Замечательная новость

Ну вот, а злые языки утверждали, что «Эльбрус» никому не нужен. Теперь от желающих отбоя нет.

Да мало ли что там «считают они сами…

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

Большое количество крупных разработчиков долгое время жило в реальности, что есть одна ОС (Windows) и одна система команд (x86, разве что поколения разные). Им это здорово облегчало жизнь.

Потом в части ОС начались изменения (не только в России, но и во всём мире, у нас этот процесс просто оказался форсирован – администрация условного Мюнхена может сначала входить, потом выходить, потом снова замечательно входить и возможно даже получать от этого некий профит, я не знаю – у нас всё жёстче, входить и выходить некогда).

И у крупных разработчиков началось. Сначала отрицание: «профессионалы выбирают Windows, эти ваши лялепсы студенческие поделки для прыщедрочеров». Потом гнев: «Ааа, госорганы занимаются попилами и откатами, заставляют нас переходить на этот ваш линукс»! В истории ЛОРа можно найти множество высказываний и по первому, и по второму. Сейчас уже сколько-нибудь серьёзные игроки либо дошли до принятия, либо занимаются торгом уровня «перейдём, но не сейчас, ну или вайн поставим». Понятно, что кто дошёл до торга – дойдёт и до принятия, это вопрос времени. Тем более, если говорить про энтерпрайз, значительная часть его написана на Java, у которой с линуксом проблем нет.

С железом и Эльбрусами в частности намного сложнее. В случае с Эльбрусами, в частности потому, что взять и купить для своей системы 100 Эльбрусов даже солидной фирме куда сложнее, чем 100 интелов (политкорректно выражаюсь, да). И процесс тут запоздал. А с другой стороны сверху подгоняют. Ну и начинают люди сочетать отрицание с торгом. Искренне считают, что если есть процессор, который идёт на замену интелам, он ДОЛЖЕН работать на x86, то, что у него ещё какая-то система команд есть, это им совсем не интересно. Вот из таких убеждений и проистекают тесты, о которых я писал.

Они плохо видят. Но при их весе и количестве это пока не их проблемы.

Ой, я, кажется, накаркал…

Совместимость ARM на Apple с х86-64, например. Чтобы поэтапно мигрировать, как и в случае «Эльбрус». Qualcomm опять же со Snapdragon X Elite.

Ой, я, кажется, накаркал…

ЛОР-эффект.

// От десанта с ЛОРа еще никому не легчало (c) //

Это было бы так, но Эппл сменил 5 процессоров, а его пользователи этого даже почти не заметили. Как покупали новый макбук этого года и там «все работало», так и продолжают это делать, и там «все работает». Ну да, Мак — не сервер, инфраструктуры за ним почти нет. Но пользователям действительно не интересно, какая там в пузе система команд.

Я вон купил M1, поставил туда рулилку гитарным комбиком, так макбук мне сказал: ща все будет, только Розетту включу. Ну включил, и все стало. Dixitque Apple fiat ARM! Et facta est ARM :) А перед этим еще три раза так говорил.

А все эти «проистекания» или от маркетинга производителей, которых жаба давит терять рынок, или от нежелания, или невозможности оплачивать новую разработку для новой платформы.

… Эппл сменил 5 процессоров, а его пользователи этого даже почти не заметили.

Что-то подсказывает, что с Виндовс так тихо и незаметно не будет.

Ну тем лучше. Что-то с памятью моей стало, только первый мегабайт помню... :) Как и предупреждал, собственно.

Но моя ошибка не меняет сути высказывания — под Эльбрус надо точить каждую задачу, а остальные процессоры более-менее хорошо справляются со всеми. А если заточить определенную задачу для каждого специально, то и там остается пространство для улучшения производительности. Это не значит, что парни и девушки с интела не затачивают компиляторы под себя. ИшшоКак!

Эльбрус — отличный процессор. От других. :) Все как-то работают хорошо в среднем и отлично при приложении сил. А эльбрус в среднем работает так себе и хорошо при оптимизации. Затрата на доведение программ до ума уж сильно большая получается.

Ну... На ARMе-то чуть не Surface уже сделали. Там тоже процесс идет довольно быстрыми темпами. ДА и ноутбуки на ARM заявили уже примерно все. Софт без x86х инлайнов в коде должен перенестись бесшовно. Ну а остальное доточить недолго.

Ну да, тот же Эппл пакует сейчас все в fat binary, типа два кодовых сегмента, для ARM и для X86. Где хочешь, там и запускай. Да, работает не всегда. Тот же Емакс, который при компиляции вливает себе в пузо дофига лиспа имеет процессорно-зависимый сегмент данных. Ну да, колдунство не работает. Но лично у меня на маке емакс один такой.

Сурфейс тоже будет на арме, никуда не денется.

Софт без x86х инлайнов в коде должен перенестись бесшовно. Ну а остальное доточить недолго.

Не факт, что не-микрософтоский софт будут успевать пересобирать под ARM. Кстати, среди знакомых вендузятнегов энтузиазма насчот ARM нет.

Я и не против, путь будет. Я как-то подержал в руках Сурфейс, давно правда. Мне понравилось. Не купил бы, но удобно и красиво.

У моих коллег спокойное к этому отношение. Винда давно на АРМе есть, еще с PocketPC. Я ж тоже сейчас винду «импортозамещаю» методом написания ядерного кода для Линукс. У нас команда двухплатформенная. Даже вот думаю «Windows Internals» на старости лет почитать :)

Маковский софт тоже тормозит. Я отслеживаю, что творится на традиционном для Мака рынке — музыка и дизайн, так тот же GuitarPro переписали мухой, многоканальную звукозапись — тоже, Есть «тормоза». Ямаха вон с Tascam'om не может никак разродиться на нативный софт для своего железа для M1... Видать, пока «никому не надо» :)

У моих коллег спокойное к этому отношение. Винда давно на АРМе есть, еще с PocketPC.

Программеры понимают, что происходит, поэтому спокойные. У прикладных юзеров наблюдаю настороженность типа «что еще выкинет MS?».

Этот вопрос обсуждался в узких кругах и пришли к тому, что по мере портирования различного ПО, с каждой новой версией оптимизирующего компилятора, «ручной оптимизации» требуется всё меньше. То есть, количество со временем переходит в качество.

Так ведь получается по результатам той же статьи про решения дифура, что одного компилятора для Эльбруса не достаточно, для него и писать надо немного по-другому. А столько кода не напортируешься.

То есть, количество со временем переходит в качество.

Тащемта, может пора этот вопрос тогда уже и в ширнармассах обсуждать? Методом раздачи компилятора всем желающим, например.

Так и статье уже несколько лет.

И что, что-то изменилось? Самому новому Эльбрусу тоже уже года четыре или больше. И то его нет, потому как TSMC.

Неоднократно обновлялся компилятор, вышел Эльбрус 6 поколения, а те кто не хотел заниматься онанизмом оптимизацией пришли к методу «запинать толпой»

https://www.youtube.com/watch?v=-3rNcjoIR2I

Я не понял про «запинать толпой», если честно. Я посмотрел только раздел «выводы», на большее времени нет, извините. Потом посмотрю полностью и выскажусь. Пока слишком много предположений рождается из таких выводов.

Решить вопрос качества, количеством ядер.

может пора этот вопрос тогда уже и в ширнармассах обсуждать

Что и делается, тем или другим способом.

на большее времени нет

Для этого и существует сервис «краткого пересказа», https://300.ya.ru/v_XQgxa0qK. Но в данном случае, краткий пересказ уж очень краток ) - три небольших абзаца от 20 минутного видео.

Главное, чтобы кристалл в стойку помещался

Внезапно https://rscgroup.ru/product/rsc-tornado-servers/tqn310e/

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

// Акцент у дамы по ссылке весьма занимательный.

Я-я, зер гут.

Ну, я ж ведь не дурак, по четвертому-то разу на Ваши ссылки смотреть. Вы мне про Фому, я я Вам про Ерему. Компилятор в студию! Бинутилс в студию! Полное описание процессора в студию! А это все ВАше «вокруг да около» и «только для избранных» оставьте себе. Не пойду я в вашу песочницу, мне своих хватает. Вот пока вы будете обсуждать методы оптимизации «узким кругом», круг ваш ну никак не расширится. И ничего кроме срача здесь и пары толковых статей на Хабре в год на выходе не будет.

И да, остаюсь во мнении, что Эльбрус не способен эффективно исполнить произвольно взятый с гитхаба код. Ну, по крайней мере, для интела «запас по оптимизации» для произвольно взятого кода — ну раза полтора. Ну два. А для Эльбруса, как Вы сами заметили — семь-восемь раз. И то на счетных задачах силами очень толковых программистов, которых вы дополнительно в своем узком кругу вырастить не сумеете. А на задачах компиляции, подозреваю, запаса и вовсе нет, как показали эксперименты Сбербанка с Джавой.

Кстати, интересно сравнить время компиляции ядра линукса, например, а не краевую задачу методом конечных элементов.

Слишком кратко. :)

Кстати, интересно сравнить время компиляции ядра линукса, например, а не краевую задачу методом конечных элементов.

Компилятор lcc медленный. Это осбенность VLIW компиляторов — в этой архитектуре на него вся надежда. Поэтому не надо сравнивать время компиляции, компиляторы под VLIW всегда будут медленнее компиляторов под x86_64.

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

http://ftp.altlinux.org/pub/people/mike/elbrus/docs/elbrus_prog/html/chapter10.html

Методы оптимизации, как и их обсуждение, итак выносятся на широкую публику.

Комментарии МЦСТ к тестированию СБЕР

http://www.mcst.ru/files/61c195/f2dece/61d641/e4549f/sber_kommentariy_mtsst.pdf

У Газпромбанка с «Эльбрус» проблем не возникло.

Меня интересует не время компиляции как таковое, а «запас по оптимизации» для произвольно взятого кода на классе задач. Счетную задачу оптимизировать можно. А задачу компиляции, то есть, по-сути, поиск по таблице и проход по конечному автомату, и так много раз, — нет. А с «производительностью в среднем» у Эльбруса плохо. Ну вот и приехали.

Разработчик неосознанно оптимизирует свой код под ту платформу, на которой сидит он сам. Это было очень заметно, когда я сидел на RPi4 в качестве десктопа. Поэтому тут всё равно сравнение будет не очень.

Но в целом, кто бы занялся :-)

Я сменил в жизни штук шесть платформ. Для определенной ОС писал, конечно. Для VMS надо писать не так, как для UNIX. Но вот так, что бы для конкретного процессора... Ну ассемблерные вставки, разве что. Всегда было требование портабельности в той или иной степени.

У Газпромбанка с «Эльбрус» проблем не возникло.

Ну, может быть, Эльбрус уложился в их технические требования. Такое возможно. А, может быть, просто «политика». :(

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

К такому выводу можно прийти, зная историю МЦСТ. Эмулятор процессора Эльбрус еще на СПАРКах они еще в 90е как-то сделали, и змулятор x86го у них появился раньше нативного компилятора, насколько можно предположить.

… сначала нативный компилятор получает из трехадресеного кода из AST нечто интелоподобное, а потом кусками бинарного эмулятора генерит окончательный код.

Зачем тогда вообще lcc? Генерим код x86_64 чем угодно -> пропускаем через lintel -> profit!

Можно заключить то, что режим двоичной трансляции на «Эльбрус», по крайней мере в данном случае работает весьма эффективно и не сильно уступает нативному.

Примерно такие же заявления мы слышали в своё время от трансметы, поэтому там не бились лбом о компилятор, а просто транслировали х86.

И где теперь эта Transmeta.

«К чему этот долгий и мучительный путь?» — подумал он и вылил бутылку пива в унитаз... :)

Ну так на открытом рынке-то и Эльбрус там же уже был бы...

Это верно. Но верно и обратное — нативный режим особого выигрыша не дает. А вот это уже сильно хуже.

Теорэма о независимости от промежуточного представления? Забавно-с.

Ну вот в силу этого я и предположил, что компилятор устроен именно так, что транслирует в конечные команды нечто похожее на x86. Если прочитать вышеприведенную статью на Хабре про e2k-бекенд для llvm и про родство компиляторов и двоичного транслятора, то еще больше как-то утверждаешься в этом мнении. А если еще учесть ограниченный человеческий ресурс разработчиков, то ничего другого и придумать нельзя.

Если бы мну в децтве учился математике вместо думать за баб-с, то сформулировал бы пердположение типа такого:

Есть группа преобразований алгоритма, оставляющая инвариантным результат его выполнения. Для любого представления алгоритма можно найти преобразование, приводящее его к виду, дающему минимальное время исполнения на данной железке. То есть неважно, представили алгоритм в виде машинного кода x86_64, или в виде псевдокода на выходе clang или фронт-энда lcc – все равно он преобразуется в машинный код e2k единственного предельного вида (с точностью до остаточной группы преобразований, не меняющих время выполнения).

Как-то так в изложении нематематика.

Примерно такие же заявления мы слышали в своё время от трансметы, поэтому там не бились лбом о компилятор, а просто транслировали х86.

Там разве не собирались выполнять всякую вендопоцприетарщину без исходников?

Э, батенька, завязывай с обобщениями. А то мы с тобой сейчас до теории вычислимости, теории категорий и монад договортмся. :) А я с собакой гуляю, вот покурить присел. До утра курить придется.

Здесь речь не об этом, а о глобальном экстремуме. Собранное для чего-то и собранное для Эльбруса в общем случае не делает разницы при исполнении на Эльбрусе.

Кроме некоторых случаев особо провальных или особо выигрышных для Эльбруса.

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

Нативный режим в любом случае даёт выигрыш ввиду отсутствия накладных расходов на трансляцию и резервирования 1-2 ядер под неё.

Более того, эффективность режима трансляции зависит и от количества запусков приложения, так как там реализована многопроходная оптимизация.

Это неудивительно, что написано для х86-64 и будет хорошо работать в этом режиме.

Более того, в приведённом примере наглядно показано, как без оптимизаций за счёт количества ядер решается поставленная задача.

Если оптимизировать, то разница по сравнению с х86-64 может достигать порядка, за счёт архитектурного превосходства «Эльбрус».

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

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

А то мы с тобой сейчас до теории вычислимости, теории категорий и монад договортмся.

Поручик, давайте что ли про баб-с?

Поручик, давайте что ли про баб-с?

Спорили тут как-то бабы об архитектурном превосходстве... ;)

Здесь речь не об этом, а о глобальном экстремуме. Собранное для чего-то и собранное для Эльбруса в общем случае не делает разницы при исполнении на Эльбрусе.

Поэтому наивный вопрос: в этом случае достигается максимально возможная для данного алгоритма производительность?

И встаёт вопрос - а нужен ли такой сверхумный компилятор, если от него прока не слишком много?

Что-то подсказывает, что бОльшей части компилятора, генерящей оптимизированный машинный код e2k, все равно, из чего его генерить. Вопрос: эта часть общая для бэкенда lcc и для lintel?

Мну не математик-программист, чтобы это обсуждать.

Может быть стоило просто исходники исправить, чтобы и обычный компилятор их переварил к виду удобному для Эльбруса?

clang/clang++ в среднем такое же время исполнения дает, как и lcc. Потому что бэкенд у них один и тот же.

// Кстати, у фронтенда clang более внятные сообщения об ашыпках. Например, при вызове члена класса, неявно объявленного как private, clang++ так и пишет. А lcc в простоте своей говорит «член не доступен».

Поэтому наивный вопрос:

Вопрос не имеет смысла.

Вопрос: эта часть общая для бэкенда lcc и для lintel?

Это ровным счётом ничего не меняет

clang/clang++ в среднем такое

И чё?

Это на форуме. :)

Ну, кстати, интересно бы было иметь jit-компилятр арма на эльбрусе. И сравнить.

Запас по оптимизации, заметим, --ручной, на счетных задачах продемонстрирован. Окей. А что с задачами управления, реальным временем и тд? Как е2к себя ведет на анализе трафика, например? Чот нигде нет данных.

А что с задачами управления, реальным временем и тд? Как е2к себя ведет на анализе трафика, например?

И почему мне всё это вдруг напомнило старый анекдот про японскую бензопилу и суровых сибирских лесорубов??.. ;) :))

Только пила не японская :)

Вопрос не имеет смысла.

Если вам ужэ таки все понятно, объясните популярно для прикладников?

Только пила не японская :)

И мужыки ужэ не те, а то бы огого.

«Эльбрус» обходил «Байкал», не помогли даже покупные ARM ядра.

«Эльбрус» используют для аналитики

http://www.mcst.ru/files/603669/c9dece/610e79/90a70b/210216_elbrus_tech_day._3logic_group_graviton.pdf

http://www.mcst.ru/files/61c194/72dece/615141/e4549f/balabanov_m__3logic_vnedrenie_pak_pautina.pdf

Наоборот, «Эльбрус» и создавался для обработки больших массивов данных.

Ээээмммм... «Бузина и дядька»?? :)))

«Дядька по бузину».

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

ПАК «Паутина» на «Эльбрус» (вторая ссылка), в режиме 24/7 используется, 85 регионов, 587 4-процессорных серверов.

Например, в «Распадской угольной компании» для аналитики тоже.

https://permkrai.ru/news/v-stolitse-prikamya-na-molodezhnom-forume-3-sentyabrya-permskom-periode-vystupit-gruppa-moya-mishel/

Поправил ссылку

https://permkrai.ru/news/videoserver-permskoy-it-kompanii-vnedren-v-sistemu-bezopasnosti-krupnogo-proizvoditelya-uglya/