6 ms·
> This lets it greatly outperform the JVM, at the expense of some rarely used functionality. Outperform in what metric? Startup time? Granted. Anything else? N
by marta_morena_25 6y ago
> This lets it greatly outperform the JVM, at the expense of some rarely used functionality.
Outperform in what metric? Startup time? Granted. Anything else? Not so much.
>Basically, it’s like switching from the JIT to a C compiler’s -O3.
Yeah and that would be pretty bad (it's not a good analogy to begin with). "-O3" doesn't have anything that a JIT couldn't have. The only advantage is again, startup time. JIT compilation has otherwise only advantages over static compilcation, especially in highly polymorphic code, such as java. Static compilation for polymorphic code is a joke in terms of performance... And every C++ programmer should know that.
I didn't look at the spec, but I would assume that AOT is only the bootup and then the JIT will take over anyway. This means, they'd do some basic precompilation for fat bootup and then use JIT again to optimize the code further based on runtime analysis. Everything else would be a ridicolous step backwards in time and make AOT completely useless, except for some niche scenarios.
- TimTheTinker 6y agoAs far as I know, Truffle is able to do some absolutely incredible compile-time optimizations —- reaching deeply into what we would normally regard as strictly semantic territory. (For an example, see some of the optimizations done by TruffleRuby for things like `myArray.sort.first` - which it apparently optimizes by terminating the sort as soon as the first element is sorted to the front of the array... and all that without any special hints in the standard library. Please correct me if I’m wrong... it’s been a few years since I’ve read in depth about TruffleRuby. And granted this example isn’t Java, but I imagine there are great parallels there.)
- deleted 6y ago[deleted]
- tosh 6y agoI'm not sure how it would terminate sort early, my initial assumption was that for small arrays there might be special-casing? this seems to be a related thread on twitter: https://twitter.com/ChrisGSeaton/status/1001582169578524672 https://twitter.com/ChrisGSeaton/status/1001582169578524672
- monadic2 6y agoAre you unsure about the runtime considerations or how the compiler would infer the necessary optimizations?
- innagadadavida 6y agoCan the storage of generic containers change as well? For example, store the objects in the container instead of reference?
- galaxyLogic 6y ago> Startup time? Granted. Anything else? Not so much. Startup time matters a lot especially for Java applications. The reason Java never got to the desktop (including browser) I believe was the startup time. Startup time matters a lot also for micro-services. A 2nd great benefit of GraalVM I think is it makes it easy to integrate programs written in different languages, say Node.js and Java for instance.
- Erlich_Bachman 6y ago> Java never got to the desktop (including browser) What do you mean by this? There are a lot of desktop Java applications...
- outadoc 6y agoI'd like to hear about them, because apart from enterprise applications, there aren't that many left. Electron is the new desktop Java.
- hoistbypetard 6y agoI wouldn't call them dominant by any stretch, but I wouldn't call them uncommon. Ones I use somewhere between daily and semi-regularly: * Pycharm * Datagrip * Charles * JDiskReport * TexturePacker * Android Studio and associated tools * Apache Directory Studio * Zed attack proxy That's just stuff that I've used recently and on an ongoing basis... I feel like I see quite a bit more of it.
- galaxyLogic 6y agoI used to use a thing called JMeter. But its GUI felt inferior in my view compared to typical Windows applications.
- mikkom 6y ago> The reason Java never got to the desktop (including browser) I believe was the startup time. I think it's mainly the fact that it has always been very difficult to create executable files. Running java requires you to install the given version of JRE instead of just downloading an application and starting it.
- sriku 6y agoThere's also an expectation that memory footprint will be lower and that can contribute to speed by reducing GC time. The "JIT can do it too" arguments generally don't consider bounded memory.
- Turbots 6y agoOutperform in terms of startup time and memory footprint. Starting up a complete Spring MVC + Netty web stack in 0.018 seconds with roughly 60-100Mb of memory is pretty cool for container runtimes like Kubernetes. Can reduce cost A LOT in cloud environments and makes way for proper function/event based architectures where scaling down to 0 or scaling up to hundreds of instances for burst use cases is required. It does this mostly by doing ahead of time compilation, eliminating dead code and putting all the static code on a stack which gets loaded into memory at startup. This has some implications: - reflection is nearly impossible to use in this scenario - you can't do anything funky in static code blocks like initialize a database or something weird like that - the JIT compiler of the JVM is not present so it cannot do hot code path optimizations at runtime, meaning the native image performance of SubstrateVM is slower than in the JIT compiler. So if you want performance and throughput, stick to the JIT compiler (GraalVM has a really good one written in Java itself, or use the standard Hotspot one by Oracle, OpenJDK or other vendors)
- deleted 6y ago[deleted]
- avasthe 6y agoHehehe the old AOT vs JIT debate. JITs can do great optimizations in theory. But in practice they have only so much time to do optimizations. And startup time, binary distribution size, memory footprint matter too.