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

51–60 of 93 posts

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

#51

Post by offmycloud »

pizlonator wrote: post #2

It would be better if VM comparisons included JSC rather than, or in addition to, V8. JSC tends to outperform V8 so if you find a pathology in V8 it’s just not so surprising. It would be more interesting if you found a pathology in JSC. I think that the use of small benchmarks obscures what’s going on. The VM is trying to win in the average. It’s like a professional gambler. Observing that the VM did something dumb f…

For those who aren't familiar, JSC is JavaScriptCore, the built-in JavaScript VM in WebKit, Apple's browser engine.

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

#52

Post by afiori »

thayne wrote: post #37
dodobirdlord wrote: post #28

Earlier quoted context omitted.

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.

I would say those are reasonably easy to solve, you just need to offer platform specific trained binaries and add a realistic set of stress tests with which you can train the VM.

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

#53

Post by afiori »

im3w1l wrote: post #19

The title doesn't do the surprising conclusion justice. "When we set out to look at how long VMs take to warm up, we didn’t expect to discover that they often don’t warm up. But, alas, the evidence that they frequently don’t warm up is hard to argue with." By not warming up they refer to instances when early performance is higher than later performance or when the performance doesn't settle.

> By not warming up they refer to instances when early performance is higher than later performance or when the performance doesn't settle.

which are both cases where you would be disappointed were you to use the VM as a server.

I think their point is that VMs are more unpredictable than many realize and also intrinsically unpredictable in some cases.

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

#54

Post by The_rationalist »

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?

https://github.com/facebook/nailgun

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

#55

Post by The_rationalist »

jdsully wrote: post #47
jjnoakes wrote: post #18

Earlier quoted context omitted.

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

Its called profile guided optimization, although they don’t run with an actual JIT. The big 3 C compilers all have it.

It is clearly less powerful, it analyse one sample and extrapolate from it.

Every user should have it's own PGO and regularly refresh it to be competitive with the advantage of JIT profiling

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

#56

Post by gjs278 »

continuational wrote: post #48
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…

According to The Computer Language Benchmarks Game, Go performance is in the same ballpark as Java, and sometimes several times slower: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

i’ve never used a fast java program in my life

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

#57

Post by ncmncm »

smabie wrote: post #16

Haven't we learned that VMs aren't worth it? The amount of engineering resources it takes to design a half-way decent one is just absolutely staggering. We all know that theoretically they can be faster than native code, but how many people have actually experienced that? The costs are too high: the warm-up costs, the engineering costs, the complexity costs. If every single language just generated LLVM IR and compile…

The same can also be said about GC. Every year somebody is promoting a new Incremental Realtime Generational garbage collector that is almost acceptable for serious work, if you ignore enough real-world overheads. People writing code that has to manage resources besides memory have found that, given the right core language facilities, managing memory too is no bother, but managing other resources while fighting GC is intolerable. Of vourse you need destructors.

Meanwhile, C performance has not been a worthy goal in decades. Getting "as fast as C", if you could get there, would still leave you firmly in second or third place. Thr computers are not getting much faster anymore, but the problems are getting much bigger and the networks much faster, so performance matters more each year than the last.

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

#58

Post by noir_lord »

ncmncm wrote: post #57
smabie wrote: post #16

Haven't we learned that VMs aren't worth it? The amount of engineering resources it takes to design a half-way decent one is just absolutely staggering. We all know that theoretically they can be faster than native code, but how many people have actually experienced that? The costs are too high: the warm-up costs, the engineering costs, the complexity costs. If every single language just generated LLVM IR and compile…

The same can also be said about GC. Every year somebody is promoting a new Incremental Realtime Generational garbage collector that is almost acceptable for serious work, if you ignore enough real-world overheads. People writing code that has to manage resources besides memory have found that, given the right core language facilities, managing memory too is no bother, but managing other resources while fighting GC is…

> The computers are not getting much faster anymore

True for each core on a CPU (broadly) but not true for the computer as a whole unit, we've seen an explosion of core counts on x86 desktops/laptops over the last 5 years (helped by the resurgent AMD forcing Intel to stop putting out incremental upgrades to 2C/4T on laptop and 4C/8T on desktop every year).

> People writing code that has to manage resources besides memory have found that, given the right core language facilities, managing memory too is no bother,

If we assume that it is 'no bother' as stated that doesn't address the 8C/16T elephant in the room in that for maximum throughput on a modern machine we need to orchestrate running across multiple cores properly and that's a tougher problem to crack in a general purpose popular language without an explosion in complexity to the programmer.

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

#59

Post by ccmcarey »

jsiepkes wrote: post #45
darksaints wrote: post #33

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 work…

Slow compared to? VSCode? Visual Studio? Vim?

From experience, slower than VSCode by quite a bit, and both VSCode and Jetbrains are of course slower than Vim by an order of magnitude.

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

#60

Post by blinkingled »

hamburglar wrote: post #17
pizlonator wrote: post #14

Earlier quoted context omitted.

That would be great but it’s hard because the trick, at least in JS VMs, is to have the JIT specialize based on the heap. So you’d need a heap snapshot or some way to link the generated code to a different heap. Maybe not impossible, just hard enough that it’s not widespread.

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.

IBM OpenJ9 JVM does that with the AOT feature. It's good for startup time and the AOT code can be still further optimized by the JIT. https://www.eclipse.org/openj9/docs/aot/
Post reply on HN