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

71–80 of 93 posts

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

#71

Post by jerf »

EdwardDiego wrote: post #49
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…

> Go ... has top notch garbage collection Is ballast[1] still required for certain use cases? [1]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

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 me a big slab of memory and walk away, please" (arena management, etc.).

(Not a defense of Go's GC, necessarily. I'm not sure I'd call it "top-notch". A lot of its advantage over Java was that it got to look at Java and make different decisions, and by having a lot more values in the language with fewer references, part of the reason it tends to do a lot better than Java in terms of memory usage is just that it gave itself an easier memory management problem in the first place. Java GCs are frightfully good, yes, but to some extent they are that good because they have to be. Java at the very, very beginning was not designed for the sort of usage it has today (it was very originally a set-top box language, not a Big Iron language), so the language does some things that stress its GC. Go's doesn't have to be that intricate to be still quite good, so it isn't. And note difference between "quite good" and "top notch".)

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

#72

Post by rb808 »

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?

dotnet does this, caches compiled assemblies then also tunes them. https://www.geeksforgeeks.org/what-is-just-in-time-jit-compi...

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

#73

Post by InfiniteRand »

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.

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

#74

Post by quotemstr »

It's psychological. Most users don't really care how fast something runs once the JIT warms up: instead, they care about the latency of their starting the program to the time they can use it and use this latency as a psychological measure of the performance of the program as a whole. Stupid? Yes. But that's what actually happens.

The JVM has always had a slow startup path. Much slower-overall systems like Python don't. That's why people don't complain about Python performance and do complain about Java performance.

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

#75

Post by the8472 »

jerf wrote: post #71
EdwardDiego wrote: post #49

Earlier quoted context omitted.

> Go ... has top notch garbage collection Is ballast[1] still required for certain use cases? [1]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

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.

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

#76

Post by lioeters »

offmycloud wrote: post #51
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.

Thank you, I was able to find more information about JSC on WebKit's site: https://trac.webkit.org/wiki/JSC

Also a standalone build (kinda old) for various platforms: https://github.com/Lichtso/JSC-Standalone

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

#77

Post by tracker1 »

qqssccfftt wrote: post #68
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…

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.

In my own experience IntelliJ is slower than VS Code to use... It will depend on what you're doing as VS Code has an interesting plugin module to not hang up the UI/Editor itself...

Not all the plugins respond in time while typing, but I can at least keep typing and it continues to function with basic editing (general worst case).

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

#78

Post by tracker1 »

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.

Just curious what the big 3 you're considering are?

- gcc - clang - msvc - intel

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

#79

Post by pizlonator »

fulafel wrote: post #43
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.

Heap layout changes between runs due to OS obfuscation (ASLR).

I would bet that a VM isn’t going to be deterministic enough to produce the same heap twice even without aslr. Just building a deterministic JS engine seems like a super hard problem.

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

#80

Post by btrask »

The_rationalist wrote: post #55
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.

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

This is a completely legitimate comment (which was 'dead' when I saw it). PGO really is less powerful than JIT.

A compiled language with a "micro-JIT" (e.g. for v-tables) seems like an interesting idea to me.

Post reply on HN