Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

tratt.net

Post reply on HN
Print view View original

31–40 of 93 posts

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#31

Post by charleslmunger »

jjnoakes wrote: post #18
hansvm wrote: post #9

Earlier quoted context omitted.

I mostly agree, but compilers intentionally don't explore every optimization path to save compilation time, and a JIT is able to trace the program for real data and find places that could benefit from additional attention. I don't think JITs are the only way to address that trade-off in compilation time vs runtime performance metrics, and whether their benefits are worth their other costs is an interesting, program-d…

Any languages explore both? Compile to native and run with a jit which profiles and optimizes further based on runtime behavior?

You can get a bunch of the benefit by applying FDO:

https://llvm.org/devmtg/2013-04/novillo-slides.pdf

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#32

Post by electrum »

Spivak wrote: post #11

Stupid question for people who know more about these things. Why can’t we fight the warmup time by running an already warmed up snapshot of the program? Or say dumping some data structure when it hits steady state to give hints to the JIT the next time it runs?

Azul's ReadyNow! for their commercial Zing JVM does this: https://www.azul.com/products/zing/readynow-technology-for-z...

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#33

Post by darksaints »

I love intellij idea, but it's pretty damn slow for a lot of things (though never quite as bad as eclipse). I have always wondered if the JVM is optimizing for tasks that happen at startup, at the expense of performance during use. It would be a shame if the slow performance simply came down to the JVM profiling at startup and determining that the core function of the entire program was to index the code in your workspace.

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#34

Post by alfalfasprout »

The reality is... it's been decades and while JVM languages can be pretty fast, I have yet to see many non-contrived examples where the VM based language consistently outperforms competently written but not heavily optimized C++. Even then, extensive tuning is done to the VM. Heck, with the advent of Go you now have another great higher level language that consistently outperforms Java/Scala, has top notch garbage collection, and doesn't make you deal with a bloated VM.

JIT is very nice in theory. It's great in certain applications (eg; in very tightly scoped domains like accelerating linear algebra). Its proponents always talk about how it allows for optimizations that would be too costly or difficult when doing AOT compilation. But the operational complexity to get it to actually perform at that level on a production language VM (eg; oracle's JVM) is often its undoing.

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#35

Post by saagarjha »

pizlonator wrote: post #23
hamburglar wrote: post #17

Earlier quoted context omitted.

It does seem like you could do JIT with a persistent cache which stores the JIT output along with a key that's a hash of all the relevant system parameters like CPU model and VM parameters like heap size. This would mean that the typical case of re-running a program in the same environment would be pre-warmed.

It’s much harder than that because the JIT is speculating on what lots of objects in the heap are doing, including watchpointing them to constant fold properties. It’s not clear what the key should be in that case. Still not impossible but I want to be clear on what exactly makes this hard. CPU model for example is not what makes it hard.

> including watchpointing them

I assume this isn't literally using hardware watchpoints?

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#36

Post by lstamour »

Spivak wrote: post #11

Stupid question for people who know more about these things. Why can’t we fight the warmup time by running an already warmed up snapshot of the program? Or say dumping some data structure when it hits steady state to give hints to the JIT the next time it runs?

If you look for "AOT" or "Ahead-of-time" you'll find examples in both .NET and Java, but as far as I know they're either largely experimental or limited to newer code (not backwards-compatible with all code). But I haven't looked too deeply into it. Dumping data structures to give hints for next time reminds me of something I read recently on the topic, but drat, I can't remember it right now.

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#37

Post by thayne »

dodobirdlord wrote: post #28
cortesoft wrote: post #26

Earlier quoted context omitted.

Isn't that just compiling, then?

Sure, but something like Java already has to be compiled. Throw a few more minutes in there, maybe run the test suite a couple thousand times.

But many languages with VMs are intended to be portable across processor architectures, and a snapshot would be architecture-dependent.

Also, the charecteristics of your test suite may be very different than how it is run in production.

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#38

Post by jayd16 »

Spivak wrote: post #11

Stupid question for people who know more about these things. Why can’t we fight the warmup time by running an already warmed up snapshot of the program? Or say dumping some data structure when it hits steady state to give hints to the JIT the next time it runs?

Android does this with ART. They use JIT and profiling to generate AOT binaries dynamically. I believe this also lets Android update the runtime in a way that invalidates the AOT binaries. They are simply be regenerated as needed.

https://source.android.com/devices/tech/dalvik/jit-compiler

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#39

Post by [deleted] »

alfalfasprout wrote: post #34

The reality is... it's been decades and while JVM languages can be pretty fast, I have yet to see many non-contrived examples where the VM based language consistently outperforms competently written but not heavily optimized C++. Even then, extensive tuning is done to the VM. Heck, with the advent of Go you now have another great higher level language that consistently outperforms Java/Scala, has top notch garbage co…

[deleted]

Re: Why Aren’t More Users More Happy With Our VMs? Part 1 (2018)

#40

Post by fulafel »

Spivak wrote: post #11

Stupid question for people who know more about these things. Why can’t we fight the warmup time by running an already warmed up snapshot of the program? Or say dumping some data structure when it hits steady state to give hints to the JIT the next time it runs?

We can and there are many implementations of it, but the relatively rare application of this approach suggests it's not a big enough win to justify the cost.
Post reply on HN