3 ms·
It's a short article. I was looking for any distinction between heap allocated and stack allocated objects. The compiler does escape analysis and will stack all
by karmakaze 4y ago
It's a short article. I was looking for any distinction between heap allocated and stack allocated objects. The compiler does escape analysis and will stack allocate anything that it can to a large degree.
It then goes on to say
> While allocation is as efficient as possible, it doesn’t avoid the memory pressure on the L1/L2 caches of your CPUs and when many cores are busy, they are contending for memory in the shared L3 cache.
So I suspect that it's not all about gc, but also the overhead of object memory and especially object packing for caching and use of objects between threads. That's why we have things like LMAX Disruptor[0].
Until we get Project Valhalla value objects, you're likely better off using Go than Java for the object packing efficiency.
[0] https://lmax-exchange.github.io/disruptor/ https://lmax-exchange.github.io/disruptor/
- kaba0 4y ago> but also the overhead of object memory I don’t think objects have the usual overhead when escape analysis says they can be stack-allocated. Regarding Go: Except that Go will be slower in most, complex cases.
- karmakaze 4y agoWhat would make 'complex' cases slower in Go? I know channels can be slow but you don't have to use them (though it's *ideomatic*) The benchmarks game shows them about the same[0] by How many times more CPU seconds. [0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- kaba0 4y agoComplex programs will likely need objects (not ‘value types’)+, and Go’s GC is nowhere near as performant as Java’s. Benchmarkgame’s binary tree test is the one that is specifically made to stress test the GC and Java beats out every single managed language by a huge margin there. + Even in Rust/c++ one often has to go with dynamic life times like (A)RC, shared pointers, etc.