Since I wrote this article Kotlin Native has been released, and you can read about it here:<p><a href="https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/" rel="nofollow">https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-...</a><p>It features some interesting language support for C interop, an LLVM backend, and a reference counting+cycle detecting garbage collector. I wish the team the best of luck with it!<p>Meanwhile, I've been working on the tool I suggested in the blog, that uses Avian to create small self-contained binaries easily. For people who like using Go to make command line utilities and the like, Avian+Kotlin could be a very nice alternative. For high throughput servers you are still best sticking with the JVM, in my view.
> Unreal Engine is written in C++ and has used a core garbage collected game heap since version 3. It powers many of the worlds AAA titles. They can hit 60 frames per second and they are using a very basic GC.<p>This is actually very false. Yes they use GC but they also drop 2-3 frames at each 30s interval because that's when the GC runs.<p>Go boot up Gears of War and let a character sit idle with no action, you can set your watch on 30s spans by the obvious frame hiccup. UnrealScript was great for prototyping and empowering designers but I wouldn't hold it up as an example of a high performance runtime.
Graal is pretty brand new in the relative scheme of things, it's not going to be amazing out of the box. (I'll ignore the "LLVM has a JIT" part)<p>Really.
There is no magic here.
The way you get compilers with 100% or greater perf of gcc/llvm is not through silver bullets.
It's through a large amount of hard work and tuning. IE hundreds of person years.<p>It's usually easy to get the first 60-70%, and then people say "see, we didn't need <heavyweight thing>, we'll beat them with <lightweight thing>". But if you have customers where no performance is ever "good enough", getting that 30%, and eventually beating other compilers, is the thing that takes 10+ years. You'll never do it with <lightweight thing>.
That's why all these folks who try eventually end up with 3 layers of compilers, etc.<p>If it could have been done with <lightweight thing>, it would have been done that way.<p>Also, you can just about always transfer the metadata necessary to do high level optimization x at a lower level. it just may not be efficient to do so.<p>Conversely, compilers that focus on fairly high level optimizations often do a bad job at lower level ones :)<p>Again, tradeoffs, tradeoffs.
(This is why, for example, swift/rust/etc have some higher level IR, do what they can, and hand the rest off to llvm).
I don't understand why these "people who want to do things without the JVM are wrong and deluded" articles never seem to even acknowledge that not everyone might want to go through the trouble of installing and configuring a JVM to begin with (and so the comparison they make is between "compile and run native code" and "compile and run java -jar soandso"). Being on an apparently second-class platform (Linux), every forced encounter with GUI-enabled Java applications in recent memory for me (Mathematica, MATLAB...) resulted in having to spend days picking apart esoteric JVM issues to do with everything ranging from hardware acceleration to font rendering to native library interfaces which apparently keep popping up every year in such a way that the previous year's Stack Overflow fixes no longer do anything.<p>Adding to that the hairiness of having to deal with concurrent versions (often the system's versus what was included with the software package) and how even distro-official JRE packages usually follow the "postinst script executes installer, installer downloads a blob and covers the whole system in untracked goo" format, I'm usually very relieved to scrub my system of all traces of Java after I am done with whatever forced me to install it.
I don't think the author did a particularly good job of addressing the points about startup time or memory size.<p>In particular, I think the argument about memory consumption is that it's independent of compilation strategy, but rather it depends on the quality and tuning of the garbage collector. An AOT compiled program that uses the default JVM GC with default tunings will not see much better memory performance (unless the memory consumption is dominated by the JIT).<p>On the other hand, I think the "AOT improves startup times" argument is a good one, and the author's explanation was unsatisfactory: AOT Java programs don't start any faster than JVM programs. What is the methodology for testing? Is he using the later-mentioned Avian? Because that tool deliberately trades startup time for small binaries (via compression). Even if he isn't, it's likely a matter of tool maturity--there's no fundamental reason an AOT Java Hello World should be slower than a golang hello world (which clocks in at 50ms on my machine compared to 130ms for JVM). Also the author implies that startup times only matter for tiny unix tools--I'd like to counter with a practical example: Gradle is so slow to start up that it's been daemonized. I don't know if this satisfies the author's characterization of "tiny unix tools" or not, but clearly start up times matter.
It's such an utter shame that Microsoft got to buy out and then abandon RoboVM (presumably because they felt it a threat to their recently acquired Xamarin). The one issue the author considers the most valid, was pretty decently solved almost a year ago-- I had made a couple little games that worked incredibly well out of the box in both iOS and Android on the same Kotlin codebase, it was a pleasure.<p>Luckily, RoboVM was forked after a while and it is being actively maintained by MobiDevelop [1], so give it a try if you're into Kotlin, that scene deserves a lot more love.<p><a href="http://robovm.mobidevelop.com/" rel="nofollow">http://robovm.mobidevelop.com/</a>
Straw-man article. The main problems with the JVM in my experiences are the slow startup, large memory use and added cognitive load. The first one he says doesn't matter, the second he never addresses directly and the third he completely misses.
>This impression is heightened by the fact that some well known garbage collected apps are written by people who just don’t seem to care about performance at all, like Minecraft or Eclipse, leading people to blame GC for what is in reality just badly written code.<p>This assertion is too harsh. Eclipse does seem to be over-engineered(speaking from the point of view of someone who had to write a proprietary plugin for it) and Minecraft does seem to run slow on even the latest machines (compared to AAA games).<p>But Minecraft is not a trivial program to write, despite fooling people with low-resolution textures. it is, "algorithmically speaking", out of reach of many people, including those with a reasonable computer science background. I dare someone to do better (on the JVM!)<p>On a personal note, I cringe every time I have to go to a kid's computer and modify "-Xmx" settings. I'm running a game, I want it to have all available resources not otherwise allocated to the OS, just like almost every other game there is.
> Worse, native CPU code is a lot larger than JVM bytecode.<p>><p>> [Goes on to show how Hello World is <i>just</i> 1 MB, which is smaller than Go's Hello World]
Off topic comment here about Medium's "open in app", on mobile which can't be dismissed [1]. It's so infuriating that it sticks out over the text and has no way of being closed.<p>No I'm not going to install your app!<p>[1] <a href="https://imgur.com/a/81hky" rel="nofollow">https://imgur.com/a/81hky</a>
I remember the old gcj (GCC/Java native backend) being terrible years ago (as far as performance). I haven't looked at it since.<p>I agree with a lot of points in this article. The JVM does a lot of nice stuff for you. One of the big, non discussed, advantages of compiling to native would be removing the JVM dependency (and hence the dependency on openjdk or the terrible Oracle JVM license).<p>As far as LLVM, I'll agree it's a technologically impressive. Still, I feel a clear tech implementation was only partially the motivation, and the other was getting away from GPLv3/FSF licensing. That bothers me a bit. I like the GPLv3, but I feel much of the industry wants to distance itself from the licensing that essentially helped pull Linux into what it is today.
Questions:
"Many optimisations that can really help high level managed languages like Kotlin simply don’t apply to C++": Which optimisations?<p>"Larger code bloats downloads and uses more RAM, lowering cache utilisation". This depends on your definition of cache <i>utilisation</i>: The code gets compiled, regardless of whether it's AOT or JITed, therefore the cache gets used anyway?
Would something derived from Rust's HIR/MIR make a good target for other compiled languages, maybe with lessoned memory safety for some basic blocks.
i used avian in the past for some small project, it was a bit complicated at first but i like it in the end.
I would love some integration in ide like intellj and build system