Создание экосистемы свободного ПО для процессоров «Эльбрус»

А кроме того, открыл, и, кроме -fno-strict-aliasing и -fno-delete-null-pointer-checks, ничего особо в глаза и не бросается.

А этого типа мало?

Ему можно, и даже нужно это делать. Люди начинают шевелиться, и допиливают стандарт, чтобы его устраивало.

Да нет, авторы стандарта на его мнение тоже клали член. Они вообще в своей особой реальности существуют.

any valid pointer to void can be converted to this type, then converted back to pointer to void, and the result will compare equal to the original pointer

Это на Эльбрусе работает.

А в обратную сторону и на GCC x64 не всегда: https://godbolt.org/z/r57164GKs

1Э8СВ-TmITX, 385 тыс.руб.

• http://mcst.ru/1E8CB-TmITX_TVGI.469555.415

Э2С3-TmITX, 297 тыс.руб.

• https://www.mcst.ru/1E2C3-TmITX_TVGI.469555.480

E8C-mITX, 243 тыс.руб.

• https://www.mcst.ru/E8C-mITX

Ну лол.. ты как раз в strict aliasing вляпался. У тебя UB и дело не в кастах.

Но если тебе так хочется срать в память, держи, я починил: https://godbolt.org/z/arqso9z5G

UPD: вот так работает даже с -O3 https://godbolt.org/z/KnP1P17E7

Видео.

Там как минимум один нолик лишний.

Когда его завезли? Моя память утверждает что давно. Приколы с очередным бинарём, которому не нравится, что в окружении не glibc я ловил буквально на неделе.

Седьмое поколение того, что ни в сказке сказать, ни пером описать, не видел никто и в руках не держал?

Дооо, прогресс.

Восьмое поколение, надо полагать, вмотируют прямо в Cyberdyne Systems 101 серии 800.

Так они только в разработке, поэтому и не держал никто.

E8C-mITX, 243 тыс.руб.

Подешевело, однако. Почти вдвое.

У тебя UB и дело не в кастах.

Так я и пишу, что преобразование из числа UB.

Раз в 5 бы подешевле…

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

Хм. Тогда вот еще кейс. Допустим я своём приложении создал mmap на 64 гигабайта, чтобы заменить всю работу с памятью на ультра-быстрый бамп-аллокатор и больше не морочить голову с malloc/free. Потому что, ну вы знаете, сейчас 2024 год, что мы зря 64-битные архитектуры придумывали. Получается, в таком случае Эльбрус меня больше не защитит? Если освобождение памяти - это просто уменьшение оффсета.

Нет. Если ты уберёшь преобразования из чисел, будет ровно то же.

Смотри тут: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502

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

Будто что-то плохое

Нет. Если ты уберёшь преобразования из чисел, будет ровно то же.

Если я уберу преобразование, то *(int*)(&a-1) определённо UB, так как пытается получить доступ за пределы объекта.

А этого типа мало?

-fno-strict-aliasing для влива, скорее всего, не мало, так как не позволяет осуществить довольно массовые сохранения небольших объектов в регистрах. Но, во первых, ядро есть ядро. А во вторых, с тайпкастами разбираются очень активно. Например, в с++23 ввели std::start_lifetime_as(). А гццшники встали в позу, и сказали «а нам пофиг на стандарт, мы тайпкасты поддерживать не собираемся». Ну и тд. Чтобы влив взлетел, всё это должно устаканиться.

Получается, в таком случае Эльбрус меня больше не защитит?

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

Если освобождение памяти - это просто уменьшение оффсета.

И после получения ранее использованной тоже не защитит.

Если очень хочется выстрелить себе в ногу, это можно сделать.

P.S. Вспомнилось, как на Фортране делали один глобальный огромный массив в COMMON блоке.

Ну и тд. Чтобы влив взлетел, всё это должно устаканиться.

Главное – это верить!

Готов поспорить на штуку баксов, что к 2030 году ни один VLIW чип не обгонит свежий x86 или ARM при аналогичных техпроцессе и потребляемой мощности.

Нет. Объём производства не тот, чтобы стоить так дёшево.

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

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

Но что-то мне подсказывает, что игры с этим процессором уже надоели примерно как чубайс, не так давно. Ибо денег это «нечто» жрет, а результат - малоэффективен.

Готов поспорить на штуку баксов, что к 2030 году ни один VLIW чип не обгонит свежий x86 или ARM при аналогичном техпроцессе и потребляемой мощности.

Если говорить о VLIW, как о системе общего назначения, то можно даже первую цифру менять на 3 и далее по списку. Если говорить о каких-то конкретных задачах, то - возможно. Это эдакий «асик». Как архитектура общего назначения - влив - ущербен. Не бывает чудес.

Главное – это верить!

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

Безусловно. Но VLIW всё это никак не поможет.

Готов поспорить что и любой другой отечественный процессор общего назначения, независимо от архитектуры, не обгонит свежий x86 или ARM при аналогичных техпроцессе и потребляемой мощности. Ни к 2030 ни к 2040 году. Вывод?

Безусловно. Но VLIW всё это никак не поможет.

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

И всё, и не придётся тогда ростелекому ковырять софт под эльбрусы.

Допустим я своём приложении создал mmap на 64 гигабайта, чтобы заменить всю работу с памятью на ультра-быстрый бамп-аллокатор

Отойду немного в сторону, и скажу что он не будет быстрее чем malloc, зря ты так делаешь вообще.

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

Помимо этого защита от неинициализированной памяти.

Однопоточная производительность https://7-cpu.com/:

R2000 @ 2000 MHz: 826 попугаев,  0.41 попугаев/MHz
E-8SV @ 1500 MHz: 1845 попугаев, 1.23 попугаев/MHz
E-16S @ 2000 MHz: 2553 попугаев, 1.27 попугаев/MHz

Вроде производительность на мегагерц у эльбрусов в 3 раза выше, чем у R2000. Про потребление там ничего нет.

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

Нет, не видел.

Надо, всего лишь, чтобы программеры сами осилили современные стандарты.

Во-первых, нет. Во-вторых, программерам это тоже явно не надо. В третьих, VLIW сливает даже в хорошо оптимизированных бенчмарках, авторы которых стандарты явно задрочили до посинения. Вон смотри-ка, Elbrus в режиме x86 уделал сам себя в нативном!

лол как они этого добились? E-16S в режиме эмуляции x86 оказался быстрее самого себя с нативным кодом! 2873 против 2553 попугаев. Нахер там этот VLIW, если x86 эмулировать быстрее выходит? Может проще тогда пойти путём Transmeta, сделать VLIW просто особенностью реализации и эмулировать какой-нибудь ARM?

А разве x86-64 не в сторону широкого слова сейчас двигается? Сейчас в ядре есть несколько параллельных декодеров и их количество увеличилось в свежих архитектурах, эти декодеры питают несколько портов исполнительных устройств. Все это выглядит так что из одного потока инструкций внутри ядра формируются широкие слова и они уже исполняются. ARM-ядра растят производительность за счёт такого же подхода. Коренное различие в том, что у е2к нарезка на слова возложена на компилятор, который в теории может делать более эффективную нарезку, т.к. он оперируя исходным кодом лучше «видит» замысел программиста. Но ему недоступно микроархитектурное состояние ядра и это ограничивает возможности оптимизации раскладки микроопераций по исполнительным устройствам. Если делать нарезку на слова внутри железа ядра, то становится доступным состояние, но зато ядро видит перед собой деревья, но не видит леса

VLIW по-моему ещё в полярисах были и копали крипту лучше чем x86 или arm

VLIW по-моему ещё в полярисах были и копали крипту лучше чем x86 или arm

Конечно. Но речь в треде идёт о CPU, а не о видеокартах. Из видеокарт этот VLIW, кстати, тоже выпердолили к чертям в итоге. Не взлетает!

Где моя штука баксов, бзв?

Там же, где и видеокарты на x86.

Они, кстати, были у Intel, причём аж с фряхой на борту, только в серию не пошли. А жаль..

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

Это такой хитрый план. Представьте себе смету на реверсинжиниринг этой хтонической НЁХ в узком окне времени с тайной подстановкой туда закладок. Повторять каждые 2 года, с выходом каждой новой версии архитектуры.

Это что за казацкий тверк начался? В исходном комменте речь была о чипе. Без разделения на cpu, general purpose cpu, видеокарты и вот это всё

Если кому надо обещанные исходники:

https://dev.mcst.ru/

https://openelbrus.ru/

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

На веб-портал dev.mcst.ru для разработчиков ПО на платформе «Эльбрус» на данный момент опубликованы:
• исходный текст ядра Linux для архитектуры «Эльбрус»;
• исходный текст библиотеки glibc для архитектуры «Эльбрус»;
• набор патчей для оригинальных исходных текстов прикладных пакетов дистрибутива «Эльбрус Линукс».

Также часть данных в компании опубликовали в виде целой кучи отдельных репозиториев: https://git.openelbrus.ru/mcst/osl.

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

Доступны для скачивания исходные тексты и патчи из состава продуктов АО «МЦСТ». Для удалённого доступа к серверам «Эльбрус» следуйте инструкции в данном разделе. В разделе ссылки собраны тематические ресурсы и сообщества, посвящённые платформе «Эльбрус».

совершенно типичный экспириенс

Если будет эмулятор, то можно будет учиться работать с этим железом. А как устроиться на работу, если ты систему в глаза не видел?

В видео же были применения:

• в МВД система МИР (паспорта)
• железнодорожный транспорт

А как устроиться на работу, если ты систему в глаза не видел?

Какую именно систему? Если на уровне «линукс на эльбрусе», так там больше специфики должен привнести собственно линукс, а в остальном можно будет и на месте разобраться. А если уровень хардварной системы «проц + обвязка», так там эмулятор не особо поможет освоить все нюансы железа.

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

А если хочется пооптимизировать софт, то тогда или купить (каналы известны, но дорого, хотя и подешевело) или попросить доступ по ssh и там поработать. Ну или, радикально, устроится если уж не в МЦСТ, то в какую-нибудь Базальт СПО.

Неужели эти паразиты наконец-то перестанут нарушать GPL?

Нееее, место проклятое. Что ни делают, всё жигуль получается.

Жигуль получается потому что при выборе: доработка модели, или набить карман господинам, всегда выбирается второе. От того у нас там сейчас модели разработанные ещё в СССР, когда господинов с их сегодняшними ряхами, попросту не существовало. От того и деньги шли на развитие, а не на новую яхту на лазурном берегу.

Нет, не видел.

Ну здрасьте: https://www.cnews.ru/news/top/2021-05-27_rostelekom_pomozhet_kompaniyam

В третьих, VLIW сливает даже в хорошо оптимизированных бенчмарках, авторы которых стандарты явно задрочили до посинения. Вон смотри-ка

Да это не влив, а эльбрус. А я про влив хотя бы уровня пульсона, где большинство проблем устранено.

Ну здрасьте: https://www.cnews.ru/news/top/2021-05-27_rostelekom_pomozhet_kompaniyam

cnews.ru/

Потому и не видел. И как, за три года он кому-то помог уже?

где большинство проблем устранено.

Только в фантазиях фанатов VLIW.

Вон смотри-ка, Elbrus в режиме x86 уделал сам себя в нативном!

Знакомьтесь - год 2000, проект HP Dynamo. Это эмулятор процессора PA-8000, работающий на этом же процессоре PA-8000, но с технологией JIT. И реальные программы, запускающиеся в эмуляторе - в итоге работают быстрее, чем на голом процессоре. Результаты повышения производительности доходили до +22%, в среднем по тестам получалось +9%.

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

Ну кроме того, что Fiat 124 был разработан не в СССР.

Вон смотри-ка, Elbrus в режиме x86 уделал сам себя в нативном!

Знакомьтесь - год 2000, проект HP Dynamo. Это эмулятор процессора PA-8000, работающий на этом же процессоре PA-8000, но с технологией JIT. И реальные программы, запускающиеся в эмуляторе - в итоге работают быстрее, чем на голом процессоре. Результаты повышения производительности доходили до +22%, в среднем по тестам получалось +9%.

Блин, это ж мечта гентушника! Можно будет одну и ту же прогу компилировать ни один раз, а аж два! Причём подряд!

Впрочем, я так прозреваю, они тот же OoO механизм, который сейчас в процессорах, просто сделали в софте. Оттуда и ускорение.

Только в фантазиях фанатов VLIW.

Да вы бы прочитали ссылку-то про пульсон. Реально ведь работа была огромная проделана. Практически все сталлы побеждены… Ну так, почти. :)

Про потребление написано в одной из ссылок первых ссылок, что я писал на первой странице, на основе данных от МЦСТ.