LINUX.ORG.RU

Haskell скрестили с LLVM


0

0

В статье кратко рассказывается как собрать сие чудо и, самое главное, приводятся результаты некоторых тестов. По отдельным тестам двукратное ускорение :) Правда под это дело надо хакать и GHC, и LLVM.

Надеюсь, когда-нибудь это переберётся в сам GHC

★★★★★

Сиё определённо радует. Но также мучает вопрос: почему бы не сделать хаскелевый бэкенд для gcc? Оптимизация там тоже зело мощная.

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

а он есть (в статье сравнивают и с ним)

Вот только «бэкэнд» LLVM всё равно показывает чуть более быстрые результаты (правда не уверен что по всем операциям, а не только по приведенным тестам)

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

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

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

корректней будет сказать, что GHC скрестили с LLVM - бекенд для UHC, скажем, был ещё с год назад

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

Он же есть :)

Который -via-c или прямо полноценный бэкенд?

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

Ну вернее, это не бекенд, а просто трансляция в С и скармливание гцц.

Ну вот! А полноценный gcc'шный бэкенд, имхо, llvm порвёт.

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

Там, в статье, ещё говорится, что с опциями оптимизации LLVM ещё и не начинали «играться» ;)

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

Там, в статье, ещё говорится, что с опциями оптимизации LLVM ещё и не начинали «играться» ;)

Я, честно говоря, не понимаю всего этого ажиотажа вокруг LLVM. Легче к языку написать бэкенд для LLVM, чем для gcc? Заявляют, что да. Будет работать быстрее? Нет.

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

Я думаю, это тяжеловато для одного человека... Не?

Смотря какого. Коммьюнити у ghc - это ведь не форум по убунту.

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

>Я, честно говоря, не понимаю всего этого ажиотажа вокруг LLVM.

Ну у неё есть таки «перспективка» :) На отдельных «синтетических» тестах показывает (показывала?) бо'льшую скорострельность кода за счёт различных оптимизаций кода (т.е. не на обычных циклах, а на чуть более сложных кусках программы) - обсуждалось здесь же надцать месяцев назад.

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

>Смотря какого. Коммьюнити у ghc - это ведь не форум по убунту.

Ну вот, ты собрался привлечь часть комьюнити, а там один «перец» за пол года «сварганил» :)

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

Ну у неё есть таки «перспективка» :) На отдельных «синтетических» тестах показывает (показывала?) бо'льшую скорострельность кода за счёт различных оптимизаций кода (т.е. не на обычных циклах, а на чуть более сложных кусках программы) - обсуждалось здесь же надцать месяцев назад.

Так gcc тоже на месте не стоит. Например, 4.3 и 4.4 - две большие разницы.

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

>Так gcc тоже на месте не стоит. Например, 4.3 и 4.4 - две большие разницы.

Ни кто и не спорит. Но генерить LLVM-asm, я думаю, несколько проще, чем возиться с потрохами gcc - не? (я просто не в курсе)

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

> Я, честно говоря, не понимаю всего этого ажиотажа вокруг LLVM. Легче к языку написать бэкенд для LLVM, чем для gcc? Заявляют, что да. Будет работать быстрее? Нет.

На счёт скорости сомневаюсь. В частности, LLVM умеет IPO на этапе компоновки, а не компиляции отдельного модуля.

Да и бекенды... Насколько я понял, разглядывая gcc, он - монолит. А кишки LLVM живут в либах, на базе которых можно делать свои компиляторы.

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

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

anonymous
()

Не понимаю, блин. В GCC4 архитектура очень похожая на LLVM. Только вот АФАЙР никому кроме gcc-хакеров непонятная ввиду отсутствия хоть какой-нибудь высокоуровневой документации и жуткой монолитности самого GCC.

Конечно понятно, что GHC давно пора обзаводиться своим кодогенерирующим бэк-ендом и в краткосрочной перспективе более привлекательна именно LLVM... Но в долгосрочной перспективе (ака «продакшен») ничего кроме как взаимодействие GHC с миддл-ендом GCC просто нет.

Кстати, может быть ребята из гугла в своем GCCgo чего-нибудь сообществу подгонят, но все-равно пока они держат отдельную ветку GCC, да и насущный проблемы (типа полного отсутствия в GCCgo сборщика мусора) имеются.

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

>Конечно понятно, что GHC давно пора обзаводиться своим кодогенерирующим бэк-ендом и в краткосрочной перспективе более привлекательна именно LLVM... Но в долгосрочной перспективе (ака «продакшен») ничего кроме как взаимодействие GHC с миддл-ендом GCC просто нет.

Имхо сейчас он по дефаулту (без -via-C) генерит асм самостоятельно, минуя gcc.

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

> Имхо сейчас он по дефаулту (без -via-C) генерит асм самостоятельно, минуя gcc.

Так и есть.

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

>по скорости - полностью одинаково получилось.

Видимо, потому что

на своем проекте


На моих тестах и по отзывам народа llvm пока ещё достаточно тормозной :)

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

не знаю. код простой, прямолинейный интерпретатор RISC-команд.
синтетику не гонял.

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

> На моих тестах

Ты оптимизацию включить забыл (это нетривиально делается).

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

>Имхо сейчас он по дефаулту

Отстал я чего-то от жизни :(

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

> На счёт скорости сомневаюсь. В частности, LLVM умеет IPO на этапе компоновки, а не компиляции отдельного модуля.

Грядёт GCC 4.5 же

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

> Грядёт GCC 4.5 же

Ну так ждём же с нетерпением! А пока вот в LLVM оно уже есть...

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