4 ms·

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 consis

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.

deleted 7y ago
[deleted]
continuational 7y ago
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/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- gjs278 7y ago
  i’ve never used a fast java program in my life
- norswap 7y ago
  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).
EdwardDiego 7y ago
> 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-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...
- jerf 7y ago
  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".)
  - the8472 7y ago
    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.
    - jerf 7y ago
      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-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ 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.)
qqssccfftt 7y ago
> 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.
- titzer 7y ago
  > The Go GC is intentionally very simple. This is simply not true. The Go GC is an example of a sophisticated non-moving concurrent collector. > optimised for one specific metric This is only partly true. Low pause time is definitely the highest priority metric, but throughput still matters. The Go GC probably has the lowest pause times of any production GC these days, outside of perhaps nonpublic custom solutions, e.g. successors to IBM's Metronome sold to specific customers.
wtetzner 7y ago
> 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.

deleted 7y ago

[deleted]

continuational 7y ago

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/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

gjs278 7y ago
i’ve never used a fast java program in my life
norswap 7y ago
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).

EdwardDiego 7y ago

> 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-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...

jerf 7y ago
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".)
- the8472 7y ago
  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.
  - jerf 7y ago
    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-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ 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.)

qqssccfftt 7y ago

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

titzer 7y ago
> The Go GC is intentionally very simple. This is simply not true. The Go GC is an example of a sophisticated non-moving concurrent collector. > optimised for one specific metric This is only partly true. Low pause time is definitely the highest priority metric, but throughput still matters. The Go GC probably has the lowest pause times of any production GC these days, outside of perhaps nonpublic custom solutions, e.g. successors to IBM's Metronome sold to specific customers.

wtetzner 7y ago

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