moin moin

Hello!

morning

Morning

morning

👋:skin-tone-2:

Next few talks for the London Clojurians may include the following * Clojure and GraalVM (idea stage) * How to talk to your REPL - exploring prepl (working title, speaker acquired) * Introduction to deep learning with MXNet and Clojure (idea stage) * unleashing vim for Clojure development (idea stage - how to use vim effectively for closure dev) Any thoughts on the interest of these talks, things you would like to see them cover, other topics you would find interesting?

vim for the win! 🙂

I managed to get a simple clojure app to run with graalvm (19.0.0)

worked well enough 🙂

nice

clojure and graal I’m super interested in b/c of the lambda use case

GraalVM!

What's the big deal with Graal..? Is it just__ startup, or is performance across the board considered better?

@jr0cket - Are you preparing all of these yourself..? *boggle*

@maleghast yes, I'll be doing all the talks as everyone else is too shy 😁 This is of course a big fib... I am sure you knew that already Oliver is doing the repl prepl talk... I would be happy to have anyone speak on the other topics (otherwise you may get me)

I think the thing about Graal, isn't about graal per se, it's being able to run without a JVM, i.e., faster startup. As we know, historically, the JVM has had a bad rap for it's startup time, and thus other languages (rightly or wrongly) are gaining more traction (i.e., go) simply because things compile to a single executable and can be run without anything else. If Graal helps Java, Scala, Clojure, Kotlin etc.., to "catch-up" in that aspect, then that can only be a good thing 🙂

Whether or not that is appropriate for the use-case in hand, depends.

I think graal itself may be the long-term replacement for hotspot...

That, and also (for me) the hope of making it easier to sell non-Java teams on Clojure 😄

the future of most apps will be on-demand compute/execution so anything based on the JVM needs a way of running w/a fast start-up if it wants to be a serious contender to ‘just using go’ or ‘just using node’

*will probably be

*imho

Anyone have recommendations for food companies, other than pizza, that can provide food for events?

I just noticed that Humus Bros has folded, that's a real shame

Not familiar with the area, so can't really offer any recommendations.

Does Graal actually significantly reduce the startup time of Clojure? My understanding was that AWS had done a lot of work to minimise the JVM startup time in Lambdas, but that Clojure's additional time on top of that still made it mostly not an option there. I would assume Graal would suffer the same problem

Also it's still a VM, so what makes it faster than the standard JVM?

Graal native image builds can makes the startup like a native application to the OS. Its still early days yet, but this approach could take away much of the JVM start time and hence improve that of Clojure. Start up times are probably the least interesting feature though. I dont see Grall native images as a benefit to development workflow speeds at the moment, but then I don't restart my repl very often and when I do its quick enough for me. You could also use a minimum profile JVM and/or ahead of time compilation to also reduce startup time and in the short term this may provide similar or better results. As with everything else, performance is a constraint and its dynamics come from a range of factors. Of course you can still write very bloaty code and it wouldn't matter what you did 🙂

Here's a very simple adhoc micro benchmark, same program:

% time java -jar target/palindrome-0.1.0-SNAPSHOT-standalone.jar "foo"
false
java -jar target/palindrome-0.1.0-SNAPSHOT-standalone.jar "foo"  1.27s user 0.09s system 238% cpu 0.569 total

(a moment...)

% time ./target/palindromes "foo"
false
./target/palindromes "foo"  0.00s user 0.00s system 87% cpu 0.001 total

1.27s vs 0.0 seconds 🙂

seems like a win to me 🙂

yeah GraalVM native compilation is looking pretty great if you need to ship a native binary… though there are I believe big limitations for some apps like no reflective calls. However Graal’s also I think more interesting from the perspective of truffle… where a language implementer need only implement a naive interpreter for their language using the truffle framework, and they’ll instantly get a compiled language with state of the art GC and VM support for free. The difference this can make looks to be huge, for example Ruby on Truffle was I believe about 14x faster than MRI / JRuby… though don’t quote me on that.

just saw out the corner of my eye and was like…

The tech to do the above is pretty amazing, and meta beyond belief… partial evaluation of a self specialising interpreter to yield an optimizing compiler for the said language with great performance.

https://web.archive.org/web/20110629171734/http://www.brics.dk/~hosc/local/HOSC-12-4-pp381-391.pdf

Supposedly called Futamura projections… which I just read as Futurama projections

From wikipedia: > 1. Specializing an interpreter for given source code, yielding an executable > 2. Specializing the specializer for the interpreter (as applied in #1), yielding a compiler > 3. Specializing the specializer for itself (as applied in #2), yielding a tool that can convert any interpreter to an equivalent compiler > Furthermore, applying the tool in #3 to itself yields the tool itself, so it is a Quine. 🤯

https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_projections

ugh… does anyone know of an alternative to jvisualvm that works with adoptopenjdk-12?

or do I need to buy a copy of yourkit?

@rickmoynihan Is there much hanging off JRuby these days? I know Embulk is but talking the maintainers a few weeks ago I think they’ll move away from it eventually and away from RubyGems for the plugins.