3 ms·
That's a straw man. Just because GC is fast doesn't mean it can't be made faster. > Go team at Google would have enough real usage feedback from running Go sys
by openasocket 8y ago
That's a straw man. Just because GC is fast doesn't mean it can't be made faster.
> Go team at Google would have enough real usage feedback from running Go systems in their massive data centers. They most likely find it reasonable with all things considered.
That's not just an appeal to authority, that's a big assumption. As far as I know, no Go maintainer has claimed that they have gathered large amounts of performance data and concluded that a generational GC wouldn't improve performance.
Also, calling generational GC "Java GC design" is disingenuous. Generational GC long precedes the creation of Java, and is used almost universally. Common Lisp (various implementations), .Net, the Lua VM (and the LuaJIT VM), BEAM, SELF, and Haskell (GHC at least) all use generational garbage collection. In fact, the current Go implementation is the only GC implementation I'm aware of that isn't generational.
- geodel 8y agoI think it is other way round. No one has yet shown in production applications that Go's GC throughput is big problem for them.
- pcwalton 8y agoThe question to ask is: Have people switched away from Go for certain applications in order to get better CPU-bound performance? Yes, they have. GC throughput is one part of the reason why Go code is often suboptimal for CPU-bound workloads. Adding a generational GC won't solve this, but it's bound to help.
- weberc2 8y agoI don’t think “has anyone ever switched from Go...” is particularly meaningful. Is the switch common? I’ve only heard of a handful (like 3) of cases where people tried optimizing Go and found it to be lacking, and those cases were at the extreme end of the performance spectrum. Also, Go will never be optimally performant because it chooses to balance performance with competing concerns (safety, simplicity, etc), so its unclear in those cases whether the suboptimalism was due to Go’s GC scheme or to other trade offs.
- yoklov 8y agoNeither Lua nor LuaJIT use a generational design, they're both tri-color incremental mark and sweep collectors without a separate nursery. There was a plan for a generational GC for LuaJIT [0] (not to mention a lot of other cool features and a very clever design) but it was never implemented (and at this point it probably never will be). [0] http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector
- weberc2 8y agoAlso, most of the listed languages don’t have value types or added them expressly because their GC scheme was insufficient.