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

81–90 of 93 posts

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

#81

Post by hedora »

pso wrote: post #66

It seems that the authors are not measuring what they think they are, or have explained it poorly. Most transitions from interpreter to JIT show speedups of x10 to x100, eg luajit or V8. How is it possible that the variation of V8 (as an example), according to their numbers is showing improvements of only a few percent, when it should be orders of magnitude faster after transition? My conclusion, they are measuring v…

Their first iteration is an entire run of the underlying benchmark. Subsequent iterations are reusing the same VM. They run each plot multiple times, and reboot between plots.

They’re trying to show that “warmed up steady state” isn’t something that reliably exists.

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

#82

Post by hedora »

lokedhs wrote: post #62
ncmncm wrote: post #57

Earlier quoted context omitted.

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…

That's a True Scotsman fallacy. I guess all those millions upon uncountable millions of lines of Java, Erlang, C#, etc code in production is not serious? Because it's running in a VM?

What percentage of those lines run with an incremental realtime GC?

The only such Java GC I know of is part of the Azul Zing VM.

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

#83

Post by fulafel »

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.

PGO as done in C family compilers of today can't make speculative optimizations and fall back to recompilation, so it's much weaker.

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

#84

Post by jerf »

the8472 wrote: post #75
jerf wrote: post #71

Earlier quoted context omitted.

I think if you implicitly define "top-notch garbage collection" as "never requires any tweaking ever in any performance profile" you've limited your "top-notch garbage collection" down to the empty set. There aren't even any "manual" memory management techniques that can stand up to that definition, honestly. Even in "manual memory management" languages there are situations where you end up having to say "just give m…

Ballast isn't gc tuning in the sense of changing some configuration, it's doing something nonsensical in the application code itself to alter gc behavior. In java you would simply set -Xms to increase the min heap size and then that additional memory would also be available to the application and not wasted as in the Go case.

It's not "wasted" in the Go case. On modern systems, the ballast is only a few numbers in the virtual memory table as long as you don't touch it, which isn't that hard. The original blog post confirm it: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... search for "Now onto 2. Won’t this use up 10Gib of my precious RAM?"

It may be "nonsensical" but on the grand scale of "things done for memory management's sake" I find it unimpressive. (If 10GB were actually allocated and unavailable, I would find it impressive.)

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

#85

Post by qqssccfftt »

jonathanstrange wrote: post #65
lokedhs wrote: post #61

People are complaining about VM performance, while at the same time I'm guessing a fair number of the same people happily writes production code in Python. It's hard to find a slower language than Python. People are not using VM-based languages because they want to beat the numeric performance of hand-optimised Fortran. They use it because of the memory safety, compatibility and performance which is on par with or ev…

I have nothing against lean VMs/JIT compilation like LuaJit or the way Racket compiles on the fly, but I do avoid Java VMs for various reasons: - Dependency hell and deployment problems: It's hard to make correct assumptions about which VM version is available on which platform. Pre-installed versions interfere with side-installed versions, and there is a ton of software that requires older Java VMs to work properly.…

t. person who has not used java since Java 1.5

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

#86

Post by pso »

hedora wrote: post #81
pso wrote: post #66

It seems that the authors are not measuring what they think they are, or have explained it poorly. Most transitions from interpreter to JIT show speedups of x10 to x100, eg luajit or V8. How is it possible that the variation of V8 (as an example), according to their numbers is showing improvements of only a few percent, when it should be orders of magnitude faster after transition? My conclusion, they are measuring v…

Their first iteration is an entire run of the underlying benchmark. Subsequent iterations are reusing the same VM. They run each plot multiple times, and reboot between plots. They’re trying to show that “warmed up steady state” isn’t something that reliably exists.

Yes, I know. But the tone of the whole article, is as if, they've found deep flaws across many VMs. They call something 'warmup" which I think has little or nothing to do with the JIT, but is unaccounted variations in the whole running system.

The final graph shows a binary trees program in C, with a 6% variation between "in process executions", and no steady state, it seems logical that most VMs will show the same or worse variation.

The "warmed-up steady state" does exist, but not if they define it so narrowly. All of their iterations and timings are running at x30 to x100 interpreted speed, the only 'cold' interpreted code is in a few microseconds of the first loops of an execution.

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

#87

Post by jdsully »

tracker1 wrote: post #78
jdsully wrote: post #47

Earlier quoted context omitted.

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

Just curious what the big 3 you're considering are? - gcc - clang - msvc - intel

Yes in that order. Maybe you could say big 4, but I find Intel is only popular in smaller niches.

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

#88

Post by WorldMaker »

hedora wrote: post #82
lokedhs wrote: post #62

Earlier quoted context omitted.

That's a True Scotsman fallacy. I guess all those millions upon uncountable millions of lines of Java, Erlang, C#, etc code in production is not serious? Because it's running in a VM?

What percentage of those lines run with an incremental realtime GC? The only such Java GC I know of is part of the Azul Zing VM.

I believe that's why the poster referenced the "No True Scotsman" fallacy. It entirely depends on your definitions and you can keep endlessly narrowing your definitions. All of them GC, right? All of them are doing some form or another of incremental, right? (Some in all generations, others only in some generations, based on balancing and tuning needs.) Do all of them have realtime characteristics? Yes and no. None of them are allowed to stop the world, certainly, but does that mean that all of them or any of them can be called "realtime"? It's a semantic hedge forest.

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

#89

Post by smabie »

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 difference is that GC provides so much more value than a VM. For example, without GC, functional programming is practically impossible, unless you consider linear types the solution (I'm not aware of a FP language that uses them instead of GC, so I can't really comment on their viability).

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

#90

Post by smabie »

InfiniteRand wrote: post #73
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…

Performance is I think for most people a matter of good-enough performance, most of the time, with good-enough and most varying wildly depending on context. Regarding the move towards the web, I think portability still matters, because a lot of web developers write code and potentially test code on Windows and but deploy on Linux for production.

Except it's not good enough. Every JVM project I've worked on had to work around the unpredictability of the VM: doing things like on a new deploy hitting all your endpoints a 100 times in order to warm things up. Or the curious cases when a trivial change in one part of your program somehow affects the performance characteristics of another. VMs don't provide enough benefits to justify the large burden of actually using them effectively.
Post reply on HN