FR>Тут не понял разве HLVM это реализация OCaml под llvm? FR>Мне показалось что это просто еще один биндинг к llvm.
HLVM (High Level Virtual Machine), это альтернативный рунтайм для ML языков к-й юзает LLVM для кодогенерации. Автор периодически пишет о нем на reddit (ник jdh30), но пока проект похоже слегка заморожен (если я все правильно понял) Я точно где-то читал, что автор считает конкуррентный GC одной из главных задач проекта.
И опять же проблема библиотек -- у кемла очень хреновый FFI: из Си идет работа с кемловскими значениями напрямую, оно конечно попроще в реализации и, возможно, шустрее, но серьезные изменения в рантайме уже затруднены. Так что я подозреваю, что multicore OCaml-а вообще никогда не появится. Кстати, Damien Doligez (который написал окемловский GC) еще году в 95-м защитил диссер по multicore CG, однако в кемл его так и не вставили.
Здравствуйте, FR, Вы писали:
FR>А перелопачивать компилер рано или поздно придется, может вообще лучший вариант будет перевести его на llvm например, многое упростится.
Над HLVM'ом пока работает один человек — Jon Harrop — к-й похоже вынужден был временно приостановить работу:
That would beat the performance of F# with minimal effort. That was the goal
of my HLVM hobby project but I was forced to shelve it when the recession
hit. Hopefully I'll get back to it in 2010... Отсюда
Здравствуйте, vshabanov, Вы писали:
V>Я что-то не стал ждать и перешел на хаскелл Над кемлом работает 0.5 человека, так что кемл скорее мертв, чем жив. К тому же у кемла уже набралась критическая масса, когда для дальнейшего расширения надо серьезно перелопачивать компилер (менять алгоритм проверки типов), а ресурсов на это у INRIA нет, им важнее теоремы доказывать и сертифицированные компилеры делать.
У хаскеля полно своих проблем
К тому же мне например сейчас интересен именно не ленивый гибридный язык с хорошей подержкой и функциональщины и императивщины.
Я бы не сказал что OCaml мертв, застой конечно есть, но последний год есть подвижки.
А перелопачивать компилер рано или поздно придется, может вообще лучший вариант будет перевести его на llvm например, многое упростится.
FR>>Насчет FFI вроде ничего там такого мешающего нет, вся работа со значениями идет через стандартные макросы.
V>Уж не помню, но что-то тот же Ксавье говорил по этому поводу, что не так легко оно все получится. Есть еще всякие блокирующие/небликирующие вызовы (leave/enter_blocking_section), многие библиотеки делались с расчетом на то, что кемл всегда работает в одной нити. В общем legacy там порядочно.
Понятно что legacy есть, но все же решаемо, конечно нужны ресурсы.
V>В хаскеле как-то все сильно проще получилось, из-за того, что в Си там особо рантайм не подергаешь, ничего привязанного к рантайму и нет.
В хаскеле FFI я только мельком глянул, мне он тоже показался более внятным.
FR>>Как пример в том же питоне такой же корявый FFI и ничего пережил уже пару серьезных перетрясок рантайма.
V>Ну, думаю, что параллельный сборщик мусора к питону запросто не добавить Да и вроде питон тоже всегда в одной нити работает?
Угу там практически та же проблема, но не та
Там GC это счетчик ссылок + разруливатель циклов, это по моему гораздо сложнее эффективно распараллеить чем полноценный GC кэмла.
Здравствуйте, FR, Вы писали:
FR>Правда пока это больше похоже на демку, работает только под Linux/AMD64 но есть надежда что станет базовым для OCaml'а.
Интересно, когда его портируют на AIX платформу...
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Угу, но была надежда что расшевелятся французы
V>И опять же проблема библиотек -- у кемла очень хреновый FFI: из Си идет работа с кемловскими значениями напрямую, оно конечно попроще в реализации и, возможно, шустрее, но серьезные изменения в рантайме уже затруднены. Так что я подозреваю, что multicore OCaml-а вообще никогда не появится. Кстати, Damien Doligez (который написал окемловский GC) еще году в 95-м защитил диссер по multicore CG, однако в кемл его так и не вставили.
Насчет FFI вроде ничего там такого мешающего нет, вся работа со значениями идет через стандартные макросы.
Как пример в том же питоне такой же корявый FFI и ничего пережил уже пару серьезных перетрясок рантайма.
Я что-то не стал ждать и перешел на хаскелл Над кемлом работает 0.5 человека, так что кемл скорее мертв, чем жив. К тому же у кемла уже набралась критическая масса, когда для дальнейшего расширения надо серьезно перелопачивать компилер (менять алгоритм проверки типов), а ресурсов на это у INRIA нет, им важнее теоремы доказывать и сертифицированные компилеры делать.
V>>И опять же проблема библиотек -- у кемла очень хреновый FFI: из Си идет работа с кемловскими значениями напрямую, оно конечно попроще в реализации и, возможно, шустрее, но серьезные изменения в рантайме уже затруднены. Так что я подозреваю, что multicore OCaml-а вообще никогда не появится. Кстати, Damien Doligez (который написал окемловский GC) еще году в 95-м защитил диссер по multicore CG, однако в кемл его так и не вставили.
FR>Насчет FFI вроде ничего там такого мешающего нет, вся работа со значениями идет через стандартные макросы.
Уж не помню, но что-то тот же Ксавье говорил по этому поводу, что не так легко оно все получится. Есть еще всякие блокирующие/небликирующие вызовы (leave/enter_blocking_section), многие библиотеки делались с расчетом на то, что кемл всегда работает в одной нити. В общем legacy там порядочно. В хаскеле как-то все сильно проще получилось, из-за того, что в Си там особо рантайм не подергаешь, ничего привязанного к рантайму и нет.
FR>Как пример в том же питоне такой же корявый FFI и ничего пережил уже пару серьезных перетрясок рантайма.
Ну, думаю, что параллельный сборщик мусора к питону запросто не добавить Да и вроде питон тоже всегда в одной нити работает?
Я точно где-то читал, что автор считает конкуррентный GC одной из главных задач проекта.
Над кемлом работает 0.5 человека, так что кемл скорее мертв, чем жив. К тому же у кемла уже набралась критическая масса, когда для дальнейшего расширения надо серьезно перелопачивать компилер (менять алгоритм проверки типов), а ресурсов на это у INRIA нет, им важнее теоремы доказывать и сертифицированные компилеры делать.
