Live data from Hacker News

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

tratt.net

61–70 of 93 posts

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

#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 even better than other languages (at least when it comes to the JVM) for the tasks that they want to perform, which is for most programmers not going to be numeric simulation.

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

#62
post #57
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…

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?

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

#63

It occurs to me that, in practical terms, the "steady state" of performance with the increasingly large blobs of JavaScript we find littered throughout the web tends to impact the user more than other JITs. As the user navigates from page to page, the VM is reset, a fresh set of minified blobs is downloaded and JITed, and a core or two is pinned to do so. That translates pretty directly to a hotter phone, less batter…

It has been really frustrating watching the frontend-web evolve. Take Jira for example, the platform is written in Java yet all my time is spent waiting for all the widgets to jiggle their way into existence. No matter how fast your server is, if you have to do 10-20 network requests to hydrate your frontend architecture the network time alone is going ruin your perceived performance. Your server could deliver sub 5ms response times, with 50ms Time to First Byte on the initial request, and it would still feel like wobbly molasses. The JVM is the least of their worries.

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

#64
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?

i think there are some common lisp implementations that do this

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

#65
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. It's a huge mess.

- Potential for losing future OS support: Apple, Microsoft, and others may at any time decide to block Java VM or no longer support it on their platform. That means you have to bundle your software with a Java VM, e.g. Crashplan has done this, making installation and deployment even more difficult.

- A thousand past problems on Linux: Various versions of OpenJDK and Oracle's java in combination with user software written in Java have caused massive problems on my Linux machines during the past 15 years, from causing extreme slowdowns to freezing the desktop until you hard reset.

Nothing else has given me as much troubles on Linux than Java, not even proprietary graphics card drivers and kernel extensions. Whatever the Java VM does, if it can freeze your whole system just because you run desktop software like Jabref, then there is something wrong with it.

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

#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 variations after warmup.

All of the warmup, and transitions from interpreter, to JIT, to optimised JIT , happen inside the first few micro or milliseconds of EVERY one of their thousands of process iteration. Their measurements are ALL of the system variation of the VM after warm up has taken place. The VM is optimizing within the first 1-1000 inner loops occuring at the start of EACH process iteration. For most working programmers, a variation of a few percent on a running system AFTER warm-up in "steady-state peak performance", and before any I/O takes place (because language benchmarks avoid I/O), would not be an issue. If it is an issue, then the article perhaps demonstrates that a compiled language would offer less variation.

The benchmarks listed range from a shortest of around 0.4s for fannkuch/hotspot/linux, up to 1.8s for n-body, pypy, linux. This 'long-running' benchmark code (of .4 to 1.8s ), by definition, has to include multiple inner loops/hot code, which is quickly optimized, otherwise benchmark code would have to be millions of lines long, in order to have a sufficient runtime length. Tests need to run for at least tenths of a second, for cross language comparisons, since JITted languages take some iterations to warm-up.

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

#67

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…

> top notch garbage collection

No it doesn't. The Go GC is intentionally very simple and optimised for one specific metric, where as the set of JVM garbage collectors allow you to optimise for the metric that matters to you and are tuneable for the requirements of your application. The JVM has state of the art garbage collection; Go has My First GC Algorithm.

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

#68

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…

In my experience, IntelliJ is as fast as VS Code. It'll never be as fast as a terminal editor because it has actual features as opposed to just being a text editor.

Outside of startup (which has gotten so much better in the last years I don't even see the splash screen anymore) and initial indexing upon project creation or library downloading, it's perfectly fast enough.

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

#69

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/...

Honest question: isn't the benchmarks game unrepresentative because it encourages submission of heavily optimized non-idiomatic programs?

Edit: looked at the source, which is easily accessible. The Java examples are reasonable (if slightly performance-minded, but nothing shocking).

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

#70

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…

> Heck, with the advent of Go you now have another great higher level language that consistently outperforms Java/Scala

Citation needed? Java may not beat C++ in most use cases, but if you need a garbage collected language, it's likely the fastest you're going to find. But you get high memory usage in return.

Post reply on HN