KP
спасибо
Size: a a a
2018 April 19
AV
а где-нибудь в районе JetBrains есть хорошие места с розеткой, где можно посидеть и дописать слайды (ну или просто поработать)
AV
λO
какое-нибудь (анти)кафе на 7й линии
AZ
Можно в «На парах» (7-я линия) посидеть, заказать там кофе. У них норм инет и розетки есть.
PK
На парах - отлично
AV
спасибо
2018 April 20
MA
Tim Baldridge тут написал про все новинки Java и как это может быть применено для Clojure. Ответ: никак.
GraalVM does a lot of things, and I think it's important to separate these terms.
GraalVM - most often this is used to refer to a project that was originally designed to be a implementation of the JVM in Java. So when people ask "does X run on GrallVM" the question is really "does X run in the JVM". Clojure runs on the JVM therefore it runs on GraalVM. I've done this, and it's not that hard to setup.
Truffle - is an AST interpreter framework that allows for highly dynamic languages to run efficiently on GraalVM. Truffle is valid Java code, so you can run Truffle on a stock JVM, but it's much faster on GraalVM (or on JVM of version >= 9). Notice my use of "highly dynamic" earlier. Surprisingly, Clojure is mostly static, so there's no clear win here to translating Clojure to Truffle. The exception to this is primitive math, and situations that use lots of HOF where Truffle could perhaps offer more localized optimizations that fit into the Clojure programming model. However, you pay for all this with some rather massive startup time penalties. Most examples I've seen show Truffle adding seconds on to the startup time of a language.
SubstrateVM - (aka native-image), SubstrateVM attempts to improve the performance of a Truffle based language by doing image freezing. This method has been used in other languages, and has existed in the PyPy toolchain (RPython) for well over a decade. The idea is that you write an interpreter, then hand SVM a pointer to the start of your interpreter (the main() function). The framework then analyzes the data needed by that function and all the functions it calls. All data required by those functions are also recorded. Then the call graph required to run all these functions is written out (normally to C or C++) and compiled. The side-effect is that all the startup time is removed since the interpreter is "frozen" in a started state. In the terms of Clojure this means that metadata would be serialized as-is, instead of running the code to create that metadata on every startup.
Polyglot VM - so in truffle you can have multiple type systems, and multiple languages all running on Truffle. The framework then allows cheap interop between these languages. So when GraalVM docs talk about "zero overhead interop" what they mean is that it's possible to inline a Truffle based function inside any other truffle based function. Since Truffle implementations exist for Ruby, Python, LLVM bytecode (think C/C++), JavaScript, etc. It's easy to see how its possible to have all of these languages efficiently calling each other on the same VM.
It's not all awesome though. By using SubstrateVM you give up Java reflection/interop, or have to find a way to embed a full JVM as a Truffle language (this is being worked on), but every language you add into your SVM image comes at a cost of startup times, memory usage etc. So most of the time SVM images stick to a few languages. TruffleRuby for example only uses Ruby and LLVM (for c interop).
To finish, I think Clojure on Truffle is possible, but it would take a TON of work. Basically most of clojure.lang.RT would need to be rewritten from scratch, and I'm not sure how much more in clojure.lang.* would also need to be rewritten. So the tradeoff is:
A. Current state
- Good enough performance
- Fast enough startup (Clojure starts quickly, it's the deps/tooling that are slow)
- Requires type hinting to avoid reflection
B. Clojure on Truffle
- More-or-less the same performance
- Faster un-type-hinted math
- (Possibly) Faster transducers/HOF over primitive collections
- No need for type hints
- Massive rewrite
- Huge startup time penalty
- Requires a modern/uncommon JVM (JVM9+ or GraalVM)
Comparing these side-by-side, it looks to me to be a wash. And because of that I doubt we'll see a TruffleClojure any time soon.
Timothy
GraalVM does a lot of things, and I think it's important to separate these terms.
GraalVM - most often this is used to refer to a project that was originally designed to be a implementation of the JVM in Java. So when people ask "does X run on GrallVM" the question is really "does X run in the JVM". Clojure runs on the JVM therefore it runs on GraalVM. I've done this, and it's not that hard to setup.
Truffle - is an AST interpreter framework that allows for highly dynamic languages to run efficiently on GraalVM. Truffle is valid Java code, so you can run Truffle on a stock JVM, but it's much faster on GraalVM (or on JVM of version >= 9). Notice my use of "highly dynamic" earlier. Surprisingly, Clojure is mostly static, so there's no clear win here to translating Clojure to Truffle. The exception to this is primitive math, and situations that use lots of HOF where Truffle could perhaps offer more localized optimizations that fit into the Clojure programming model. However, you pay for all this with some rather massive startup time penalties. Most examples I've seen show Truffle adding seconds on to the startup time of a language.
SubstrateVM - (aka native-image), SubstrateVM attempts to improve the performance of a Truffle based language by doing image freezing. This method has been used in other languages, and has existed in the PyPy toolchain (RPython) for well over a decade. The idea is that you write an interpreter, then hand SVM a pointer to the start of your interpreter (the main() function). The framework then analyzes the data needed by that function and all the functions it calls. All data required by those functions are also recorded. Then the call graph required to run all these functions is written out (normally to C or C++) and compiled. The side-effect is that all the startup time is removed since the interpreter is "frozen" in a started state. In the terms of Clojure this means that metadata would be serialized as-is, instead of running the code to create that metadata on every startup.
Polyglot VM - so in truffle you can have multiple type systems, and multiple languages all running on Truffle. The framework then allows cheap interop between these languages. So when GraalVM docs talk about "zero overhead interop" what they mean is that it's possible to inline a Truffle based function inside any other truffle based function. Since Truffle implementations exist for Ruby, Python, LLVM bytecode (think C/C++), JavaScript, etc. It's easy to see how its possible to have all of these languages efficiently calling each other on the same VM.
It's not all awesome though. By using SubstrateVM you give up Java reflection/interop, or have to find a way to embed a full JVM as a Truffle language (this is being worked on), but every language you add into your SVM image comes at a cost of startup times, memory usage etc. So most of the time SVM images stick to a few languages. TruffleRuby for example only uses Ruby and LLVM (for c interop).
To finish, I think Clojure on Truffle is possible, but it would take a TON of work. Basically most of clojure.lang.RT would need to be rewritten from scratch, and I'm not sure how much more in clojure.lang.* would also need to be rewritten. So the tradeoff is:
A. Current state
- Good enough performance
- Fast enough startup (Clojure starts quickly, it's the deps/tooling that are slow)
- Requires type hinting to avoid reflection
B. Clojure on Truffle
- More-or-less the same performance
- Faster un-type-hinted math
- (Possibly) Faster transducers/HOF over primitive collections
- No need for type hints
- Massive rewrite
- Huge startup time penalty
- Requires a modern/uncommon JVM (JVM9+ or GraalVM)
Comparing these side-by-side, it looks to me to be a wash. And because of that I doubt we'll see a TruffleClojure any time soon.
Timothy
VB
Кстати, спасибо всем докладчикам - было очень интересно!!
АГ
AV
вот это вот ^
VB
Функциональщики - есть вопрос.
Нужна функция как apply(f, args), но с обратным списком аргументов - apply(args, f).
Вопрос в следующем - есть ли общепринятое название такой функции, кто знает?
Нужна функция как apply(f, args), но с обратным списком аргументов - apply(args, f).
Вопрос в следующем - есть ли общепринятое название такой функции, кто знает?
VB
На ум приходит только reverseApply, но не нравится совсем
PK
А что apply(f, args) делает? И какой это язык?
IZ
Vitaly B.
На ум приходит только reverseApply, но не нравится совсем
Тебе придумать название надо?
VB
Ага, название