AG
Size: a a a
2020 May 26
PS
в перспективе он говорил что хочет https://github.com/stedolan/malfunction
Что-то оно как-то несерьезно выглядит, по сравнению с Chez, MLRISC, или, тем более, Thorin. Получается, это просто прослойка для бэкенда Ocaml. Которая, по идее, не нужна была бы в более тщательно спроектированном компиляторе для Ocaml :)
AZ
У нас на вики достаточно солидное обновление.
- добавлены все видеолекции курса @Sergey_Sverdlov
- я, наконец, создал заглавную страницу для удобства навигации,
- появилось описание еще одного учебника, за что большое спасибо @alexanius
- добавлены все видеолекции курса @Sergey_Sverdlov
- я, наконец, создал заглавную страницу для удобства навигации,
- появилось описание еще одного учебника, за что большое спасибо @alexanius
@true_grue я не помню, задавали этот вопрос или нет уже, но поднимался ли вопрос о том, чтобы компиляторную Вики перевести на английский язык? я мог бы кинуть клич - можно кинуть клич, мб и отзовётся кто-нибудь
BD
О, есть что-нибудь почитать по инлайнингу? Когда, к примеру его лучше не делать (instruction cache или что-то еще?), когда от него него наоборот профит очень важен (e.g. c++ vtables), и т.д.
он на эвристиках же весь, посмотри в ллвм
“тут после подкручивания коэффициента на 0.095 все поросло, открутим на -0.075 и посмотрим чо получится"
“тут после подкручивания коэффициента на 0.095 все поросло, открутим на -0.075 и посмотрим чо получится"
PS
"Juvix synthesizes a high-level frontend syntax, dependent-linearly-typed core language, whole-program optimisation system, and backend-swappable execution model into a single unified stack for writing formally verifiable, efficiently executable smart contracts which can be deployed to a variety of distributed ledgers."
... in cloud. ... with kubernetes! :)
... in cloud. ... with kubernetes! :)
AZ
он на эвристиках же весь, посмотри в ллвм
“тут после подкручивания коэффициента на 0.095 все поросло, открутим на -0.075 и посмотрим чо получится"
“тут после подкручивания коэффициента на 0.095 все поросло, открутим на -0.075 и посмотрим чо получится"
погоди, туда для этого уже ML завозят :)
AG
"Juvix synthesizes a high-level frontend syntax, dependent-linearly-typed core language, whole-program optimisation system, and backend-swappable execution model into a single unified stack for writing formally verifiable, efficiently executable smart contracts which can be deployed to a variety of distributed ledgers."
... in cloud. ... with kubernetes! :)
... in cloud. ... with kubernetes! :)
ну они там борщат конечно, по сути это форк идриса с бэкендом на оптимальной редукции
AZ
@true_grue я не помню, задавали этот вопрос или нет уже, но поднимался ли вопрос о том, чтобы компиляторную Вики перевести на английский язык? я мог бы кинуть клич - можно кинуть клич, мб и отзовётся кто-нибудь
хотя получится этакая версия уже существующего
awesome-compilersAG
не уверен насколько оно там рабочее, но идея у них такая была
PS
хотя получится этакая версия уже существующего
awesome-compilersИзначально меня как раз не устраивало наполнение awesome-compilers, ну и хотелось сделать ближе к нашей специфике :)
Возможно, сейчас awesome-compilers уже перегнал нашу wiki по содержательности. Я давно их не проверял.
Возможно, сейчас awesome-compilers уже перегнал нашу wiki по содержательности. Я давно их не проверял.
PS
еще есть вот такие ребята https://github.com/grin-compiler/idris-grin
А имеет ли смысл связываться с GRIN, если нет задачи компилировать ленивый ЯП?
BD
погоди, туда для этого уже ML завозят :)
а, это годно, пусть компилятор и твикает свои эвристики
AG
А имеет ли смысл связываться с GRIN, если нет задачи компилировать ленивый ЯП?
ну, ленивость там все равно есть
AG
я спрашивал этих ребят, они утверждают что в этой инкарнации есть профит и для строгих языков
PS
я спрашивал этих ребят, они утверждают что в этой инкарнации есть профит и для строгих языков
Но в результате все равно идти на поклон к LLVM?
Жаль, что мало функциональных бэкендов с развитой перенацеливаемостью.
Жаль, что мало функциональных бэкендов с развитой перенацеливаемостью.
AG
вообще мое лично мнение, что коль у нас уже есть тотальность (т.е. мы сразу отделили завершимых мух от продуктивных котлет) и линейные типы, нужно копать глубже в сторону расщепления лени, т.е. серьезнее с коданными работать, выжимать максимум из линейности и тд
AG
тогда возможно и не так остро нужны будут все эти графовые дела
AZ
а, это годно, пусть компилятор и твикает свои эвристики
мне Chandler Caruth как-то рассказывал, что веса, которые внутри есть, они с помощью ML на какой-то выборке проектов и подбирали :) а сейчас каждый сможет нормально так делать под своё приложение, надеюсь
AT
https://www.type-driven.org.uk/edwinb/why-is-idris-2-so-much-faster-than-idris-1.html
Такое ощущение, что Chez становится чем-то в духе LLVM для реализаций функциональных языков.
И вот это любопытно:
Такое ощущение, что Chez становится чем-то в духе LLVM для реализаций функциональных языков.
И вот это любопытно:
One performance problem in Idris 1 was due to space leaks in the Haskell caused by using lazy data structures where they weren't needed. Despite our best efforts, we were never able to resolve these fully.> Idris 1 is implemented in Haskell, but that has little (if anything) to do with the difference.
Кому что нравится, тот то и цитирует? 😉
Забавно, что приведённая Вами цитата находится под заголовком "Non-reasons". 🤷♀😁
Кому что нравится, тот то и цитирует? 😉
Забавно, что приведённая Вами цитата находится под заголовком "Non-reasons". 🤷♀😁
BD
мне Chandler Caruth как-то рассказывал, что веса, которые внутри есть, они с помощью ML на какой-то выборке проектов и подбирали :) а сейчас каждый сможет нормально так делать под своё приложение, надеюсь
это будет отлично