←back to thread

183 points chhum | 7 comments | | HN request time: 0.877s | source | bottom
Show context
exabrial ◴[] No.44006194[source]
Java performance isn't the fastest, that's ok, a close 3rd place behind C/CPP ain't bad. And you're still ahead of Go, and 10x or more ahead of Python and Ruby.

Java syntax isn't perfect, but it is consistent, and predictable. And hey, if you're using an Idea or Eclipse (and not notepad, atom, etc), it's just pressing control-space all day and you're fine.

Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.

What do you get for all of these tradeoffs? Speed, memory safety. But with that you still still have dynamic invocation capabilities (making things like interception possible) and hotswap/live redefinition (things that C/CPP cannot do).

Perfect? No, but very practical for the real world use case.

replies(14): >>44006269 #>>44006358 #>>44006411 #>>44006567 #>>44006570 #>>44006865 #>>44007100 #>>44007464 #>>44007662 #>>44007666 #>>44009121 #>>44009861 #>>44011219 #>>44011642 #
1. znpy ◴[] No.44006358[source]
> Java memory management seems weird from a Unix Philosophy POV, till you understand whats happening. Again, not perfect, but a good tradeoff.

The GC story is just great, however. Pretty much the best you can get in the entire ecosystem of managed-memory languages.

You have different GC algorithms implemented, and you can pick and tune the one that best fits your use-case.

The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec.

Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.

replies(3): >>44006654 #>>44007698 #>>44011114 #
2. nxobject ◴[] No.44006654[source]
> The elephant in the room is of course ZGC, which has been delivering great improvements in lowering the Stop-the-world GC pauses. I've seen it consistently deliver sub-millisecond pauses whereas other algorithms would usually do 40-60 msec.

As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.)

I have the ability to understand these modern systems abstractly, and I have the ability to write some high-intensity nearly stutter-free gamedev code that balances memory collection and allocation for predicable latency, but not both, at least without mistakes.

replies(1): >>44008175 #
3. neonsunset ◴[] No.44007698[source]
> Needless to say, you can also write GC-free code, if you need that. It's not really advertised, but it's feasible.

It is not feasible under the JVM type system. Even once Valhalla gets released it will carry restrictions that will keep that highly impractical.

It's much less needed with ZGC but even the poster child C# from the GC-based language family when it comes to writing allocation-free and zero-cost abstraction code presents challenges the second you need to use code written by someone who does not care as much about performance.

replies(1): >>44011208 #
4. fidotron ◴[] No.44008175[source]
> As someone who's always been interested in gamedev, I genuinely wonder whether that would be good enough to implement cutting-edge combo modern acceleration structures/streaming systems (e.g. UE5's Nanite level-of-detail system.)

The GC would be the least of your problems.

Java is neat, but the memory model (on which the GC relies) and lack of operator overloading does mean that for games going for that level of performance would be incredibly tedious. You also have the warm up time, and the various hacks to get around that which exist.

Back when J2ME was a thing there was a mini industry of people cranking out games with no object allocation, everything in primitive arrays and so on. I knew of several studios with C and even C++ to Java translators because it was easier to write such code in a subset of those and automatically translate and optimize than it was to write the Java of the same thing by hand.

5. astrange ◴[] No.44011114[source]
I'm honestly amazed people say this about Java, because the language almost couldn't be worse at giving you tools to use memory efficiently.

There's no value types (outside primitives) and everything is about pointer chasing. And surely if there was less pointer chasing it'd be easier to do the GC work at the same time.

replies(1): >>44011413 #
6. zdragnar ◴[] No.44011208[source]
Zero-allocation (obviously different from zero GC) frameworks made a bit of a splash a little while back, but I'm not seeing much about them anymore from a brief search. I would have sworn that quarkus was one of them, but it looks like that's definitely not the case anymore.

The downside is that you sacrifice a lot of the benefits of guard rails of the language and tooling for what may not end up being much savings, depending on your workload.

7. vips7L ◴[] No.44011413[source]
When people talk about GC performance they’re not talking about using memory efficiently. They’re talking about how fast the GC can allocate and how long it will stop the world when it needs to collect. In both of these areas you won’t find GCs better than the ones provided by HotSpot. Even with what you mention, pointer chasing and lack of structs, they still outperform other implementations.