5 ms·
And OCaml has a generational GC, unlike Go. So Go's throughput is going to be hit even harder. Not going with a generational GC is a choice that runs against w
by pcwalton 10y ago
And OCaml has a generational GC, unlike Go. So Go's throughput is going to be hit even harder.
Not going with a generational GC is a choice that runs against what has been accepted practice for decades. It may of course work out, but it's what I'd consider an experiment.
- fpoling 10y agoTypical Go code does not generate a lot of short-lived objects, compared with, say, Java or with typical usage of persistent data structures in functional languages. That removes the practical need for generational GC.
- weberc2 10y agoI'm also of the impression that Go's "transactional GC" is similar to a generational GC?
- pcwalton 10y agoIf this were true, then escape analysis wouldn't be so important in Go code. But it is: the lack of it is the reason why gccgo is slow in practice.
- fpoling 10y agoI see the importance of escspe analysis as another indication that tyical Go code does not generate a lot of short-lived objects on the heap. It is just the language does not allow to express particular stack-allocation idioms requiring the compiler to infer them. Compare that with Java where rather sofisticated escape analysis does not help much besides allowing to return several things cheaply from a function. Typical code there just does not follow stack-like allocation patterns.
- deleted 10y ago[deleted]