The OpenNET Project / Index page

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



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

Оглавление

Опубликована документация разработчика и система команд Эльбрус, opennews (ok), 02-Июн-20, (0) [смотреть все]

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


82. "Опубликована документация разработчика и система команд Эльб..."  +2 +/
Сообщение от Аноним (77), 02-Июн-20, 13:20 
Итаник тоже VLIW.
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

159. "Опубликована документация разработчика и система команд Эльб..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 02-Июн-20, 15:12 
> Итаник тоже VLIW.

Точнее, итаник тоже EPIC.  Но вот украсть ещё и русских хакеров, помимо Бабаяна с Пентковским -- у интела мозгов не хватило.  А проект компилятора для таких штук относится именно к "невозможным"...

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

245. "Опубликована документация разработчика и система команд Эльб..."  +1 +/
Сообщение от Аноним (245), 02-Июн-20, 19:06 
Решение задачи создания такого (идеального) компилятора для императивных языков и есть невозможная, это следует напрямую из проблемы остановки. Но решив достаточное количество частных случаев, можно получить что-то пригодное на практике (что в итоге и сделано).

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

Странно, что нет (а действительно ли нет?) компиляторов всяких LazyML под Эльбрус. Хотя понятно, что практическая задача - скомпилировать существующий код, а не писать весь софт с нуля, но хотя бы как резерч.

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

280. "Опубликована документация разработчика и система команд Эльб..."  –1 +/
Сообщение от Michael Shigorinemail (ok), 02-Июн-20, 19:55 
На эту тему оставлю-ка ссылочки на творчество коллеги:
http://www.altlinux.org/Common_LISP_Porting_Initiative
http://www.altlinux.org/Haskell_Porting_Initiative
Ответить | Правка | Наверх | Cообщить модератору

323. "Опубликована документация разработчика и система команд Эльб..."  +2 +/
Сообщение от Аноним (245), 02-Июн-20, 23:17 
Я о другом. Ваш коллега, при всем уважении к его труду, все же решает куда более прикладную задачу. Получить работающий компилятор так получится (если получится завести llvm - так вообще тривиальным образом), но использовать заложенную в языке микропараллельность для эффективной компиляции под целевую VLIW-архитектуру - нет, поскольку такая задача при разработке ghc просто не ставилась: ghc заточен под генерацию "последовательного" кода (llvm или c--), а параллелизация под SMP и параллелизация под VLIW - это очень разные вещи, макро- и микроуровень. Заложенная в самом языке параллелизация будет потеряна на самых ранних этапах.
Ответить | Правка | Наверх | Cообщить модератору

333. "Опубликована документация разработчика и система команд Эльб..."  +1 +/
Сообщение от erthink (ok), 02-Июн-20, 23:52 
> Я о другом. Ваш коллега, при всем уважении к его труду, все
> же решает куда более прикладную задачу. Получить работающий компилятор так получится
> (если получится завести llvm - так вообще тривиальным образом)...

Уже много раз писал/пояснял, но на всякий повторю.
LLVM выстроен под RISC/CISC, натягивать его на VLIW не рационально.

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

Поэтому от LLVM останется только frontend-ы, а рядом придется выстроить инфраструктуру для VLIW, у которой с текущей RISC/CISC крайне мало общего. И всё это притом, что сообщество в принципе не в восторге от идеи поддержать какой-то VLIW от "странных русских".

---

Если я правильно понимаю намерения МЦСТ, то они сделают некий облегченный (с одной извилиной) кодогенератор для LLVM. Ну или у меня (может и с их помощью) дойдут руки до https://github.com/vnmakarov/mir/issues/47.

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

337. "Опубликована документация разработчика и система команд Эльб..."  +2 +/
Сообщение от Аноним (245), 03-Июн-20, 00:01 
Да, я именно это и пытаюсь сказать.

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

И если для императивных языков затея с llvm еще и имеет какой-то смысл, то для функциональщины - вообще выглядит как вредительство.

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

338. "Опубликована документация разработчика и система команд Эльб..."  +1 +/
Сообщение от erthink (ok), 03-Июн-20, 00:02 
> Да, я именно это и пытаюсь сказать.
> Сделать компилятор, который работает, но генерирует неэффективный код, через llvm можно
> (но не рационально). Сделать компилятор, который учитывает параллельную сущность языка
> - невозможно, поскольку этот фарш обратно так не проворачивается, уже все
> залинеили.
> И если для императивных языков затея с llvm еще и имеет какой-то
> смысл, то для функциональщины - вообще выглядит как вредительство.

Хорошо сформулировано.

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

372. "Опубликована документация разработчика и система команд Эльб..."  +/
Сообщение от Michael Shigorinemail (ok), 03-Июн-20, 03:54 
> Уже много раз писал/пояснял, но на всякий повторю.
> LLVM выстроен под RISC/CISC, натягивать его на VLIW не рационально.

Передал, ответили:

---
В llvm есть IR как внутреннее абстрактное представление. На котором сам
llvm делает много оптимизаций.
А дальше всё это превращается в ассемблер через кодогенератор - для
каждой архитектуры ЦПУ свой.

Так вот, в этой схеме вся работа с IR никак не мешает VLIW-кодогенератору.
Прокручивать фарш обратно не надо.
Ключевой момент только в том, что кодогенератор должен понимать IR на входе.

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

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

373. "Опубликована документация разработчика и система команд Эльб..."  +/
Сообщение от erthink (ok), 03-Июн-20, 04:44 
Миша, а ты когда спишь?

>> Уже много раз писал/пояснял, но на всякий повторю.
>> LLVM выстроен под RISC/CISC, натягивать его на VLIW не рационально.
> Передал, ответили:

Тут (видимо) какое-то недопонимание и/или "сломанный телефон".

Во-первых они сами (но уже не помню кто именно) говорили про трудности и "фарш обратно".

Во-вторых: loop fusion, sinking, load/store motion, и чего-то там еще иногда достаточно сильно мешают.

В-третьих: в LLVM есть куча различных перетасовок и трансформаций нацеленных на "выпрямление" кода для традиционных регистровых архитектур. И вот все эти пертурбации нередко "замыливают" исходную семантику запрошенных пользователем операций в исходном коде.
Т.е. все эти преобразования привносят
некоторое кол-во побочных эффектов, которые не нарушают видимую пользователем картину, но при сложной кодогенерации это создает дополнительные трудности - нужно либо кодогенерировать один-в-один с сохранением чего-то лишнего, либо посредством анализа вычленять/восстанавливать заказанный пользователем минимум.

С другой стороны, конечно VLIW-кодогенератор может переварить LLVM-овский IR и сгенерировать корректны код. Вопрос лишь в том, насколько хуже будет результат и/или насколько больше для этого потребуется времени. При этом опять-таки, можно не задействовать какие-то LLVM-оптимизации/преобразования исходного IR от фронтенда или не заморачиваться потерей 1-3% скорости в среднем "по больнице".

Тем не менее, если они исследовали вопрос и решили сделать полноценный бек к LLVM, то хвала им и почет. В этом случае, передай "алаверды" что я с удовольствием присяду им на хвост по теме https://github.com/vnmakarov/mir/issues/47. Но только я хочу попробовать свой "укладыватель тетриса", и пока у меня совсем нет времени (

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

394. "Опубликована документация разработчика и система команд Эльб..."  +1 +/
Сообщение от Michael Shigorinemail (ok), 03-Июн-20, 12:35 
> Миша, а ты когда спишь?

Когда спится; а ты?

>> Передал, ответили:
> Тут (видимо) какое-то недопонимание и/или "сломанный телефон".

Тогда идём-ка в почту для надёжности.

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

443. "Опубликована документация разработчика и система команд Эльб..."  +/
Сообщение от Аноним (442), 04-Июн-20, 01:51 
> Поэтому от LLVM останется только frontend-ы, а рядом придется выстроить инфраструктуру
> для VLIW, у которой с текущей RISC/CISC крайне мало общего.

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

> И всё это притом, что сообщество в принципе не в восторге от
> идеи поддержать какой-то VLIW от "странных русских".

Странные русские приложили к тому немало усилий...

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

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

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




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

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