LINUX.ORG.RU

Опубликована система команд Эльбрус

 


1

4

http://elbrus.ru/efficient_elbrus_programming_book_2020-05

Кто хочет написать свой компилятор или доработать gcc/clang/whatever — велкам!

ЗЫ Кто хочет написать новость - тоже велкам.

Перемещено Zhbert из linux-hardware

★★★★★

Последнее исправление: Aceler (всего исправлений: 1)

Ответ на: комментарий от anonymous

Что-то я не помню, что-бы кто-то без особой надобности (Blender там какой-нибудь) запихивал в программу CUDA или OpenCL. OpenCL на Эльбрусах, кстати, заводится, как я понял.

SkyMaverick ★★★★★
()
Ответ на: комментарий от SkyMaverick

Вполне возможно, я деталей реализации не знаю. Из общения с разработчиками я вынес, что llvm нужен ради поддержки большего числа языков, а не оптимизации.

Aceler ★★★★★
() автор топика
Ответ на: комментарий от SkyMaverick

Здрассти, в Blender как раз и применяется OpenCL. Или в Darktable. Везде, где нужна векторная математика, на видеокартах быстрее.

OpenCL на Эльбрусах, кстати, заводится, как я понял.

О, кстати, надо попробовать.

Aceler ★★★★★
() автор топика
Ответ на: комментарий от Aceler

Из общения с разработчиками я вынес, что llvm нужен ради поддержки большего числа языков, а не оптимизации

Я тоже так понял. Последней каплей, наверное, стали новые версии Firefox и Rust соответственно.

SkyMaverick ★★★★★
()
Ответ на: комментарий от Aceler

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

Разработчики говорили о том, что как только они «осилят» оптимизацию команд в llvm для Эльбрус, то
смогут пересобрать gcc последней версии и затем остальной стек программ.

Владимир

anonymous
()
Ответ на: комментарий от Aceler

Здрассти, в Blender как раз и применяется OpenCL

Ну так я к тому и написал, что в каком-нибудь Blender - это оправдано. А в какой-нибудь gzip тоже неплохо параллелится, но запихивать туда OpenCL/CUDA явный overkill и никто этим не заморочится.

SkyMaverick ★★★★★
()
Ответ на: комментарий от anonymous

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

Аэээыыы??? Типа, после компиляции llvm-ом gcc обнаружит в себе способность компилировать бинарники под e2k?

Ты точно с разработчиками общался? :-)

Aceler ★★★★★
() автор топика
Ответ на: комментарий от SkyMaverick

А, в этом смысле. Тогда да.

Aceler ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Разработчики говорили о том, что как только они «осилят» оптимизацию команд в llvm …

Вообще то «знания» типа «одна баба сказала» - «так себе».
Какие реально у разработчиков, занимающихся адаптацией Linux к Эльбрус только им ведомо.

Владимир

anonymous
()
Ответ на: комментарий от Aceler

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

anonymous
()
Ответ на: комментарий от Aceler

Аэээыыы??? Типа, после компиляции llvm-ом gcc обнаружит в себе способность компилировать бинарники под e2k?

Читал статью от разработчиков.
Все дело в том, что C++ на месте не стоит и стандарты плодятся как у кошки котята.
Так вот для того, чтобы пересобрать стек программ нужен последний gcc.
Его собирают с использованием LLVM, но оптимизатора команд в нем под Эльбрус нет.
Когда разработают, то тогда «телега поедет».

Владимир

anonymous
()
Ответ на: комментарий от alexanius

Троллинг тупостью уровня пабликов плоскоземельцев.

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

anonymous
()

… или доработать gcc/clang/whatever — велкам!

С учетом выше сказанного, как можно доработать LLVM не зная архитектуру команд Эльбрус?

Владимир

anonymous
()
Ответ на: комментарий от anonymous

С учетом

С учетом того, что эту тему читают больше человек чем есть Эльбрусов, то до велкам’а как до тайваня раком.

anonymous
()
Ответ на: комментарий от anonymous

С учетом выше сказанного, как можно доработать LLVM не зная архитектуру команд Эльбрус?

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

Владимир

anonymous
()
Ответ на: комментарий от NiTr0

нет. VLIW - примитивная тупая архитектура, где микрокоманды из широкого сразу загружаются на исполнительные устройства. просто, тупо и примитивно. а тот же итаник, когда вдвое разросся вширь (пушо 3 команды за такт стало выглядеть очень уныло по сравнению с дешманским х86 который умел столько же), прилично усложнился - опять-таки ради того самого легаси IA64. пушо никто в здравом уме не будет ломать ABI.

Itanium с самого начала декодировал 6 инструкций. В последних версиях обзавёлся внеочередным исполнением и SMT.

  • 2001 Itanium 1 Merced, decode 6 instr (2 bundles), 6 issue, 9 exec. ports (4ALU/4MEM 2FMA 3BR),.
  • 2002 Itanium 2 McKinley, 11 ports (6ALU/4MEM 2FMA 3BR).
  • 2010 Itanium 2 Tukwilam, FGMT.
  • 2012 Itanium 2 Poulson, 12 issue, 11 ports (6ALU/2MEM 2FMA, 3BR), SMT, OoO.
anonymous
()
Ответ на: комментарий от Aceler

А вот речевые обороты, мммм… :-)

Вот за что, а за это - Боже Царя храни.

crutch_master ★★★★★
()
Ответ на: комментарий от Aceler

Собственно, изначальные заказчики архитектуры, в лице военных, этого и хотели. 2C+, который изготавливается в России по архитектурным нормам, прости господи, 90 нм (300МГц), очень неплохо справляется с задачей распознавания целей в составе радаров.

Только стоить напомнить, что в Э2С+ 4 DSP ядра.

anonymous
()
Ответ на: комментарий от anonymous

как уже писали, для такого есть видеокарты, и уже они разносят эльбрус в пух и прах, до них эльбрусу ещё дальше, чем до x86 в обычных программах

GPU заточен под параллельную обработку, CPU заточен под низкие задержки вычислений.

Условно, если запустить 32 потока на GPU, то они обрабатываются параллельно и результат будет готов в одно и тоже время T для всех потоков. Условно, если запустить 32 итерации на CPU, то результат каждой следующей итерации будет доступен на I * T/32.

# Визуально
  GPU   CPU
0 0123  0
1 0123  0
2 0123  1
3 0123  1
4 0123  2
5 0123  2
6 0123  3
7 0123  3

По-этой причине AMD отказалась от VLIW в GPU, т.к. там не нужно быстро выдавать результат, но надо делать много вычислений.

anonymous
()
Ответ на: комментарий от anonymous

GPU заточен под параллельную обработку, CPU заточен под низкие задержки вычислений.

gpu заточен на независимые вычисления, когда вычисления не надо синхронизировать с другими.

anonymous
()
Ответ на: комментарий от anonymous

gpu заточен на независимые вычисления, когда вычисления не надо синхронизировать с другими.

Именно поэтому потоки можно объединить в группы по 1024 штуки и синхронизировать между собой?

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

Именно поэтому потоки можно объединить в группы по 1024 штуки и синхронизировать между собой?

Не понял вопроса. Зачем синхронизировать то, что не надо синхронизировать?

anonymous
()
Ответ на: комментарий от anonymous

Не понял вопроса. Зачем синхронизировать то, что не надо синхронизировать?

Например когда делаешь редукцию?

anonymous
()
Ответ на: комментарий от anonymous

GPU заточен под параллельную обработку, CPU заточен под низкие задержки вычислений.

Полная чушь. В гпу задержки такие, которые и не снились cpu.

Условно, если запустить 32 потока на GPU, то они обрабатываются параллельно и результат будет готов в одно и тоже время T для всех потоков.

Нет, очевидно. Почитай букварик для начала.

Визуально

Херня херни.

По-этой причине AMD отказалась от VLIW в GPU,

Ещё одна жертва пропаганды. Ни от какого влива амд не отказывалась.

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

Чего?

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

Дак вот, каждый отдельный sm(и то, как это называется у амд) - незасимый и может выполнять что угодно.

Так же, если бы ты читал букварь и узнал бы, что такое конвейеризация - ты бы такой ахинеи не нёс.

Из-за этого sm"у недостаточно одного блока - ему нужны новые блоки до того как завершилось вычисление предыдущего. Нужно ему дополнительных 2-4 блока. Т.е. никакой одновременности нет.

Но даже 2-4 недостаточно - это покроет только задержки самых вычислений. Но другие задержки(в том числе и памяти) это не покроет. Там уже нужно десятки блоков, если не сотни.

# Визуально
  GPU   CPU
0 0123  0123
1 ----  0123
2 0123  0123
3 ----  0123
4 0123  0123
...

Я тебе помог и показал как будет в реальности, а не в твоих фантазиях.

minihic112
()
Ответ на: комментарий от Aceler

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

Полная чушь.

Например, задачах распознавания образов, потокового шифрования по ГОСТ, потокового сжатия и дедупликации.

Ога. Ну схема проста. Берём колхозников, которые не могут ничего написать. Берём их же потуги на эльбрусе - сливают в хлам х86. Потом пытается это оптимизировать. Для х86 берём какой-то мусорный маздай, либо гцц5(что мы и видим в методичке. Схема то уже отлажена) и вот она победа. Ну как победа - с поправкой на частоту.

Как меня выше правильно поправил анонимус, на дворе уже 5-я версия архитектуры e2k, при этом Альт, например, до сих пор собирается для четвёртой. И программы, собранные для v3, запускаются на процессорах v5, хотя официально такой режим, действительно, не рекомендуется.

Подожди, но это ведь и до тебя писали. Ты решил прикинуться шлангом и прибегать сюда с откровениями?

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

Возьмём и ты обречён.

Для Эльбрус-8СВ аналогом от Intel тогда будет Sandy Bridge.

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

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

Нет, очевидно.

То есть отставание современных процессоров e2k от современных процессоров x86 обусловлено техпроцессом, а не архитектурой.

Нет.

Дык. Мы ж всё вынесли в компилятор, он теперь главный.

Да, только никакого компилятора нет и не будет.

По этой причине МЦСТ первое время вообще запрещала публиковать тесты производительности.

Не по этой.

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

Не выйдет, никогда.

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

А, ну если в 2-3 раза - это успех. Правда разница должны быть в десятки и сотни раз, но раз успехом считаются и фентезийные 2-3раза - далеко пойдём.

К тому же, этого никто не будет.

А журналисты раструбят старые данные и МЦСТ будет потом оправдываться.

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

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

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

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

В эльбрусах аппаратная защита указателей. Это не связано с VLIW, реализовать VLIW можно и без этого, это связано с безопасностью, но сказывается и на производительности, а также на сложности портирования ПО с сохранением оптимизаций. К примеру, реализация GC это боль и печаль, Java для E2k делали очень долго. Отсюда и сложности с JIT компиляцией.

Не отсюда. Всё перепутано. Это сложности для реализации ХОТЬ КАКОГО-НИБУДЬ jit"а. Но хоть какой-то никому не нужен. А вот далее начинаются проблемы другие, проблемы, которые никогда не решить.

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

Полная чушь.

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

Одно никак не связано с другим. У тебя проблема не с тем, что jit компилирует медленно, а в том, что результаты его работы - мусор.

minihic112
()
Ответ на: комментарий от anonymous

Ну дак чего ты ждёшь? Беги, показывай. Разоблачай. Чего ты убежал, в угол забился и теперь я слышу потуги вида «да ты лох» как от дошколёнка.

Есть что ответить? Чего не отвечаешь. Не можешь? Обделался. Нужно хоть что-то родить? Решил, что потуги вида «ты не прав!!!!!» прокатит? И все в этом поверят?

minihic112
()
Ответ на: комментарий от anonymous

С учетом выше сказанного, как можно доработать LLVM не зная архитектуру команд Эльбрус?

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

Мило.

Aceler ★★★★★
() автор топика
Ответ на: комментарий от anonymous

С учетом того, что эту тему читают больше человек чем есть Эльбрусов, то до велкам’а как до тайваня раком.

Фигасе популярность у ЛОР-а :-)

Эльбрусов наклепали уже больше 200 000 штук, это не считая военных.

Aceler ★★★★★
() автор топика

Норм тема, эксперты как всегда в своём стиле. На этот раз они не знают, что называется компиляцией

anonymous
()
Ответ на: комментарий от anonymous

Только стоить напомнить, что в Э2С+ 4 DSP ядра.

Нет.

В гражданской версии, которая выпускается на Тайване, 4DSP ядра и частота 500МГц. В военной версии, которая выпускается в России, нет DSP ядер и частота 300МГц.

Aceler ★★★★★
() автор топика
Ответ на: комментарий от Aceler

В гражданской версии, которая выпускается на Тайване, 4DSP ядра и частота 500МГц. В военной версии, которая выпускается в России, нет DSP ядер и частота 300МГц.

Тогда ты ошибся, военным поставляется Э2CМ.

anonymous
()
Ответ на: комментарий от anonymous

А, это да, я наизусть названия не помню, спасибо.

Aceler ★★★★★
() автор топика
Ответ на: комментарий от Aceler

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

А ведь вы правы /вляпался/.

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

SORRY.

Владимир

anonymous
()
Ответ на: комментарий от anonymous

А ведь вы правы /вляпался/.

Архитектуру почитал, а «слона и не приметил».
«Було, було, но такого давно не було».

Владимир

anonymous
()
Ответ на: комментарий от anonymous

Очевидно вычисления в группе потоков.

Группа потоков независимо посчитают и положат результаты в определенное место (оптимально для гпу). Синхронизация (что поделаешь, тут неповезло). Потом «редуктор» свернет эти результаты в один.

anonymous
()
Ответ на: комментарий от Aceler

А не наоборот (я про dsp)?

Логика эльбруса вполне понятна - где реально нужны быстрые вычисления не нужна никакая куда и опенцл, там нужен аппаратный плис или дсп - они считают сигналы (притом гораздо проще/безопасней/быстрее ибо нет большой мороки с загоном этих многогерцев в этот ваш пэка), а большие ядра обеспечивают «медленную работу» - отображение результата, базы данных и прочее, что терпит микросекундную точность/задержки, при этом производительность этих ядер в целом особой роли не играет - отрисовать пользователю план объекта или пару десятков графиков, посчитать медленные данные (пороги/средние и т.п.), посравнивать текущие результаты с ожидаемыми, пукнуть в базу данных события и принять решение о пакарать!11 достаточно и 300Мгц

rukez ★★★★
()
Ответ на: комментарий от rukez

Нет, не наоборот. В военной версии DSP отсутствует. Зато там есть радиационная стойкость :-)

Aceler ★★★★★
() автор топика
Ответ на: комментарий от Aceler

не очевиден тогда смысл наличия дсп в гражданской версии о_О лучше бы воткнули пару мк-ядер для реал-тайм задач, как в биглбоне - тогда можно было бы лепить привычными средствами аппаратную периферию на вход/выход впрочем, как я понимаю, он всёравно в N раз дороже байкала, так что в целом смысл от гражданской версии не особо очевиден (акромя как более дешевого варианта военной для стройбатовских нужд)

rukez ★★★★
()
Ответ на: комментарий от anonymous

как уже писали, для такого есть видеокарты, и уже они разносят эльбрус в пух и прах

А покажи мне отечественные видеоакселераторы. Нет таких? Ну вот и выкручиваемся как можем - с VLIW и DSP.

Aceler ★★★★★
() автор топика
Ответ на: комментарий от SZT

Ты видел что некоторые производители мобилок дают по запросу исходников ядра? Архив с мейнлайн.орг. На, собирай на здоровье, лол. Также и тут будет, дадут тебе ванильные архивы с gnu.org

anonymous
()
Ответ на: комментарий от buratino

«так точно!» – это не команда, но флаг состояния.

anonymous
()
Ответ на: комментарий от anonymous

В мс офис тоже свободные компоненты используются. Zlib тот же

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.