The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Представлены новые материнские платы на восьмиядерном процес..., opennews (?), 05-Май-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


2. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Аноним (2), 05-Май-20, 11:17 
Патч попкорн из этой темы https://www.opennet.ru/opennews/art.shtml?num=52877 на него ставится?
Ответить | Правка | Наверх | Cообщить модератору

24. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Аноним (24), 05-Май-20, 11:40 
Насколько я знаю, МЦСТ даже не смотрит в сторону поддержки Эльбруса в LLVM.
Ответить | Правка | Наверх | Cообщить модератору

34. "Представлены новые материнские платы на восьмиядерном процес..."  +1 +/
Сообщение от Аноним (2), 05-Май-20, 12:03 
Ясно понятно вещь в себе.
Ответить | Правка | Наверх | Cообщить модератору

282. "Представлены новые материнские платы на восьмиядерном процес..."  +5 +/
Сообщение от erthink (ok), 05-Май-20, 17:37 
> Насколько я знаю, МЦСТ даже не смотрит в сторону поддержки Эльбруса в LLVM.

Внутренняя архитектура LLVM буквально ортогональна VLIW (поперек).
Т.е. само IR-представление внутри LLVM ориентировано на "узкие" команды, а многие виды оптимизаций бесполезны и даже вредны.
Чтобы "поддержать" E2K в LLVM требуется примерно написать оптимизатор и кодогенератор заново.
Технически это реализуемо, хотя с практической точки зрения крайне сомнительно = распыление усилий и частичное дублирование работы.

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

Поддержка других/всяческих языков использующих LLVM для генерации кода возможна через генерацию промежуточного C-кода, в том числе посредством https://github.com/JuliaComputing/llvm-cbe (умирающий проект) и https://github.com/vnmakarov/mir (перспектива).
Думаю в обозримом будущем ситуация не изменится.
Если кому-то это требуется/интересно, то я рекомендую смотреть в сторону участия в разработке MIR JIT (улучшение интеграции с LLVM, а также https://github.com/vnmakarov/mir/issues/47 (мне пока некогда)).

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

416. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Аноним (119), 05-Май-20, 21:47 
> Внутренняя архитектура LLVM буквально ортогональна VLIW (поперек).

Конечно, именно поэтому там есть поддержка IA-64.

Ответить | Правка | Наверх | Cообщить модератору

454. "Представлены новые материнские платы на восьмиядерном процес..."  +6 +/
Сообщение от erthink (ok), 05-Май-20, 23:34 
> Конечно, именно поэтому там есть поддержка IA-64.

Господа ихпёрты, а вы когда последний раз проверяли наличие поддержки IA-64 в LLVM ?
Например вот здесь https://github.com/llvm/llvm-project/tree/master/llvm/lib/Ta... ;)

Для справки:
- Поддержку IA64 выпилили еще в ходе разработки 2.6, т.е. почти 12 лет назад.
- Это был экспериментальный (т.е. глючный) бэкенд, с негодным (мягко говоря) качеством генерируемого кода.
- Собственно народ не сразу, но осознал что пилить много и в другую сторону, в том числе поэтому и бросили.

Ответить | Правка | Наверх | Cообщить модератору

460. "Представлены новые материнские платы на восьмиядерном процес..."  +3 +/
Сообщение от erthink (ok), 06-Май-20, 00:20 
Заинтересовался и решил выяснить какой была поддержка IA-64 в LLVM, ибо с git это очень просто.

Так вот, поддержка IA-64 была ликвидирована коммитом https://github.com/llvm/llvm-project/commit/17151155ed8f83dc... от 24 июля 2009, т.е. я чуть ошибся - не 12, но почти 11 лет назад.

Внимания заслуживает содержание README (фактически TODO), по которому можно оценить готовность бэкенда IA64 = https://github.com/llvm/llvm-project/blob/cdd405d8047793f07d...

Мне там нравится пункт "instruction scheduling", который повторен дважды.

---
Короче, был некий "пшык" (aka PoC), который мог генерировать код для ограниченных случаев и примерно без какой-либо оптимизации реально связанной с VLIW.

Ответить | Правка | К родителю #416 | Наверх | Cообщить модератору

614. "Представлены новые материнские платы на восьмиядерном процес..."  +1 +/
Сообщение от Аноним (614), 06-Май-20, 20:09 
ATI GPU которые имеют кодовое название Terascale (всякие HD3xxx-HD6xxx) имеют VLIW архитектуру, сейчас mesa драйвер компилирует шейдеры в бинарные коды для GPU чаше всего как раз посредством LLVM (хотя для AMD недавно напилили еще и ACO). Так вот, пытались LLVM использовать для старых GPU от AMD и не шмогли, сказали что LLVM ну никак не ложится на VLIW, нормально там можно сделать только для RISC и CISC.
Ответить | Правка | К родителю #416 | Наверх | Cообщить модератору

619. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Michael Shigorinemail (ok), 06-Май-20, 20:45 
> Так вот, пытались LLVM использовать для старых GPU от AMD
> и не шмогли, сказали что LLVM ну никак не ложится на VLIW,
> нормально там можно сделать только для RISC и CISC.

Здесь года три назад в одном обсуждении Devuan был наш соотечественник, который на спор с коллегами из AMD очень сильно разогнал radeonsi (с которым они долго бились без особого результата).

Возможно, и у Intel как-то так же с компилятором не вытанцовывалось...

Ответить | Правка | Наверх | Cообщить модератору

502. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Аномсис (?), 06-Май-20, 06:13 
Тоже самое когда-то говорили и разработчики Мультиклета. А потом взяли и перешли на создание компилятора под LLVM.
И у них вроде всё получается.

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

Из преимуществ -- разработчикам Мультиклета не надо пилить свой компилятор языка C/C++ и они всегда имеют поддержку самого последнего стандарта, который поддерживает clang. Плюс теоретическая поддержка всех остальных LLVM языков.
А разрабатывать им надо только генератор(под свою архитектуру) и оптимизатор LLVM кода, без привязки к конкретному языку и его стандарту. То есть в данном случае труд не "распылён", а наоборот используется максимально эффективно, так как они не разрабатывают повторно то, что за них разрабатывают уже другие.

Разработчикам же Эльбруса надо самим следить за реализацией всех стандартов C/C++ в своём компиляторе. Плюс самим писать компиляторы для других языков, особенно, если они не на C/C++.

То, что LLWM не подходит для VLIW -- это просто отговорка.
Если подумать, то всегда можно найти решение, которое будет не хуже разработки собственного компилятора с нуля. Но это будет выгодней.

Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

547. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Michael Shigorinemail (ok), 06-Май-20, 13:32 
> Разработчикам же Эльбруса надо самим следить за реализацией всех
> стандартов C/C++ в своём компиляторе.

Нет, у них фронтэнд лицензированный от Edison Data Group.

> То, что LLWM не подходит для VLIW -- это просто отговорка.

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

Ну и см. #288.

Ответить | Правка | Наверх | Cообщить модератору

580. "Представлены новые материнские платы на восьмиядерном процес..."  +2 +/
Сообщение от erthink (ok), 06-Май-20, 16:31 
> То, что LLWM не подходит для VLIW -- это просто отговорка.

Никто не спорит с тем, что:
- "было-бы здорово" использовать фронтенд С++ и прочие наработки LLVM.
- есть технологическая возможность добавить в LLVM поддержку E2K.

Однако, на практике есть масса неожиданных "но".
Фактически необходимо "женится на LLVM", причем когда "родители невесты" (в лице сообщества и спонсоров) как минимум не в восторге от этой идеи.
Придется не только ресерчить и разрабатывать собственный оптимизатор, но и убеждать всех остальных контрибьторов принимать соответствующие изменения (некоторые вещи на практике становятся челленджем на несколько лет).

Технически тоже не всё просто. В обмен на готовый фронтенд нужно полностью погружаться в потроха LLVM, полностью от них зависеть или рядом выстраивать свою инфраструктуру (структуры данных и алгоритмы).
Всё это при том, что многие подходы/алгоритмы/структуры буквально ортогональны.

Собственно, поэтому мне кажется что интеграция через MIR JIT имеет хорошую перспективу - там площадь взаимодействия в разы меньше, плюс возможна JIT-кодогенерация как таковая.

Ответить | Правка | К родителю #502 | Наверх | Cообщить модератору

507. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Lex (??), 06-Май-20, 06:33 
Разве суть LLVM не в этом ?
Всм, множество языков «дробятся» до подобия стандартизированного ассемблера под абстрактную машину и, далее, оно уже оптимизируется под конкретную архитектуру и генерируется код.
Разве в таком случае написание оптимизатора и кодогенератора под конкретную архитектуру является чем-то уникальным и невероятным ?
Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

527. "Представлены новые материнские платы на восьмиядерном процес..."  +2 +/
Сообщение от llolik (ok), 06-Май-20, 09:00 
> Разве в таком случае написание оптимизатора и кодогенератора под конкретную архитектуру является чем-то уникальным и невероятным ?

Так вот этот "стандартный ассемблер" сильно неудобен для VLIW. Таким образом придётся снова написать lcc, оставив от него в сущности только фронт.

Как я понял, МЦСТ немного по другому пути, они решили этот самый "стандартный ассемблер" (IR, если точней) транслировать в IR для lcc и так собирать окончательный бинарник. Как я понял из их выступлений (где-то у Горшенина на youtube, номер видео честно не помню), у них есть работающий PoC, но пилить там ещё много.
ЕМНИП основной мотив, зачем за это взялись - Rust и соответственно Firefox, а не задача поддержать LLVM, как таковой.

Ответить | Правка | Наверх | Cообщить модератору

549. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Michael Shigorinemail (ok), 06-Май-20, 13:36 
> Всм, множество языков «дробятся» до подобия стандартизированного
> ассемблера под абстрактную машину

Как минимум когда-то в gcc (2.95, что ли) им недоставало высокоуровневой информации о циклах для сколь-нибудь осмысленной их конвейеризации уже на уровне оптимизатора.  Возможно, с llvm та же проблема.

Ответить | Правка | К родителю #507 | Наверх | Cообщить модератору

568. "Представлены новые материнские платы на восьмиядерном процес..."  –1 +/
Сообщение от X5asd5 (?), 06-Май-20, 15:40 
> Т.е. само IR-представление внутри LLVM ориентировано на "узкие" команды, а многие виды оптимизаций бесполезны и даже вредны.

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

скорее даже наоборот -- в большенстве случаев НЕ требуется супер-быстрого выполнения.

какая вам там разница с какой скоростью выполняется команда ls .

во многих случаях быват уже достижение когда хорошо что программа просто ХОТЬ КАК-ТО смогла скомпилироваться и заработала.

стратегия Эльбрусовцев должна была бы быть такая:

1. взять за ОСНОВНОЙ компилятор как решение на llvm/gcc . возможность корректно реализовать компилирования програм -- пусть хоть и будут они работать не быстро.

2. паралелльно -- сделать этот свой проприетарный говно-компилятор (Edison Design Group LLC) -- предлагающий себя как альтернативный. пусть хоть он и не будет способен осуществить компилирование всё тех же програм программ как llvm/gcc -- но зато будет позволять для НЕКОТОРЫХ програм компилировать их в быстрый код (в ситуации когда геморой от запатчивания будет оправдан).

Ответить | Правка | К родителю #282 | Наверх | Cообщить модератору

572. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Michael Shigorinemail (ok), 06-Май-20, 15:54 
> какая вам там разница с какой скоростью выполняется команда ls .

      /* We use the byte length rather than display width here as
         an optimization to avoid accurately calculating the width,
         because we only output the clear to EOL sequence if the name
         _might_ wrap to the next line.  This may output a sequence
         unnecessarily in multi-byte locales for example,
         but in that case it's inconsequential to the output.  */

> во многих случаях быват уже достижение когда хорошо что программа
> просто ХОТЬ КАК-ТО смогла скомпилироваться и заработала.

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

> стратегия Эльбрусовцев должна была бы быть такая:

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

Желаю дальнейших творческих успехов и ни в коем разе не останавливаться на этом внушающем надежду пути :-)

PS: реальная картина, разумеется, ровно противоположная -- исключения хотелось бы иметь возможность хоть как-то, но скомпилить.

Ответить | Правка | Наверх | Cообщить модератору

288. "Представлены новые материнские платы на восьмиядерном процес..."  +2 +/
Сообщение от Michael Shigorinemail (ok), 05-Май-20, 17:48 
> Насколько я знаю, МЦСТ даже не смотрит в сторону поддержки Эльбруса
> в LLVM.

Насколько я знаю точно -- смотрит (ключевое слово в llvm-9.0.1.build -- "lccrt"), но состояние кодогенератора пока "мы вам не советуем" (по опыту -- Аникин плохого не посоветует).

Параллельно развивается и аналогичная попытка с gcc9.

Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

509. "Представлены новые материнские платы на восьмиядерном процес..."  +1 +/
Сообщение от Vkni (ok), 06-Май-20, 06:40 
В Compiler Development чате в телеге могут подсказать аналог llvm на графовых представлениях. Может быть он лучше для Эльбруса подойдёт. Там, естественно, не всё так круто, как в llvm, но может быть лучше.
Ответить | Правка | Наверх | Cообщить модератору

573. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Michael Shigorinemail (ok), 06-Май-20, 15:55 
> В Compiler Development чате в телеге могут подсказать аналог llvm
> на графовых представлениях. Может быть он лучше для Эльбруса подойдёт.
> Там, естественно, не всё так круто, как в llvm, но может быть лучше.

Спасибо, Андрей -- передал.

Ответить | Правка | Наверх | Cообщить модератору

82. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Аноним (119), 05-Май-20, 12:56 
Чтобы накатить патч, нужны исходники ядра. А кто те исходники хотя бы видел? Мишаня Шигорин, скажи честно, вот ты видел, или вы в альте тупо блоб пакуете?
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

161. "Представлены новые материнские платы на восьмиядерном процес..."  –2 +/
Сообщение от Аноним (161), 05-Май-20, 14:48 
Я видел. Но там ректальное NDA (на лицензии в Северной Нигерии всем ...) подписывать заставили, с угрозой кучей кар.
Ответить | Правка | Наверх | Cообщить модератору

290. "Представлены новые материнские платы на восьмиядерном процес..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 05-Май-20, 17:54 
> А кто те исходники хотя бы видел?

Эх, детский сад.  Вот: http://packages.altlinux.org/kernel-source-4.9

Интересен в таком случае, разумеется, сам патч.  Точнее, vendor tree (хотя я его в пакете оформляю именно патчем относительно вышеуказанного).

PS re #313: грепать надо было не по patch, а по modification, глупый.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

313. "Представлены новые материнские платы на восьмиядерном процес..."  –3 +/
Сообщение от Аноним (119), 05-Май-20, 18:32 
Почитай в GPL, что называется исходным кодом. Подсказка: про патчи там ни слова нет.
Ответить | Правка | Наверх | Cообщить модератору

315. "Представлены новые материнские платы на восьмиядерном процес..."  +2 +/
Сообщение от erthink (ok), 05-Май-20, 18:38 
...
- Ой, папа, что это было?!
- Море, сынок...
- Где?
Ответить | Правка | Наверх | Cообщить модератору

693. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от Тот_Самый_Анонимус (?), 13-Май-20, 09:22 
О хоспадя... Сектанты, вы достали! Теперь ГПЛ является источником понятия «исходный код»?
Ответить | Правка | К родителю #313 | Наверх | Cообщить модератору

488. "Представлены новые материнские платы на восьмиядерном процес..."  –1 +/
Сообщение от evkogan (?), 06-Май-20, 02:43 
Я правильно понимаю, что в выше указаном патча нет?
Т.к. договор запрещает распространение.
Именно для заключения этого договора и требуют ИП при продаже.
Ну а лицензия, кто у нас соблюдает законы...
Интересно когда найдется доброволец, который купит, получит код (правда я не уверен, что всем дадут), а потом разместит в инете.
Причем все понимают, что если код давать больше чем в пару родных контор, то все от кого это и правда стоит прятать, давно этот код увидели или он им не интересен.
Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

570. "Представлены новые материнские платы на восьмиядерном процес..."  +/
Сообщение от X5asd5 (?), 06-Май-20, 15:49 
> http://packages.altlinux.org/kernel-source-4.9

блин, ну вот опять это устаревшее ядро..

где поддержка io_uring ?

где поддержка pidfd ?

какого чёрта архитектуры нет в дереве https://kernel.org

Ответить | Правка | К родителю #290 | Наверх | Cообщить модератору

575. "Представлены новые материнские платы на восьмиядерном процес..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 06-Май-20, 15:58 
>> kernel-source-4.9
> блин, ну вот опять это устаревшее ядро..

4.19 ещё не шмог собрать (там какая-то локальная загадка), 5.4 пока пилят.

> где поддержка io_uring ?
> где поддержка pidfd ?

Вы, кстати, для чего именно их применяете?  Или "где блютуз"?..

> какого чёрта архитектуры нет в дереве kernel.org

Опеннетовские стратеги не экспроприировали и не отнесли, наверное.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру