Yes thanks a lot, it clarifies lots of points not obvious to me by simply skimming the graalvm website.
Le ven. 20 avr. 2018 à 04:34, Jason Kapp <mtbk...@gmail.com> a écrit : > Thank you for this detailed explanation. > > On Thursday, April 19, 2018 at 11:55:25 AM UTC-6, tbc++ wrote: >> >> 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 >> >> On Thu, Apr 19, 2018 at 4:00 AM, Khalid Jebbari <khalid....@gmail.com> >> wrote: >> >>> Hello, >>> >>> Oracle has just announced GraalVM 1.0 release candidate: >>> https://blogs.oracle.com/developers/announcing-graalvm >>> >>> It mentions a few JVM-based language but not Clojure (maybe just because >>> of popularity). >>> - Does it mean Clojure is not "compatible" with GraalVM ? >>> - Does it mean Clojure needs to be reimplemented in terms of GraalVM's >>> Truffle framework ? >>> - Does it mean Clojure can be run as a native binary with fast startup >>> time and minimized memory footprint ? >>> >>> If someone with some knowledge could explain to me the relationships >>> between Clojure and GraalVM ? Bonus points if Alex Miller answers and share >>> the plans, if any, about their integration/interaction. >>> >>> Thanks a lot in advance. really curious to understand more. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/iBY6hwqqp5c/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
