"As Go is a relatively ordinary imperative language with value types, its memory access patterns are probably comparable to C# where the generational hypothesis certainly holds and thus .NET uses a generational collector."
Where the generational hypothesis holds, compilers will also find more opportunities to allocate objects on the call stack, especially in languages with stronger value semantics. That means more object management will be implicitly handled by function call instrumentation.
Stronger value semantics also means fewer small objects in the presence of optimization. Not to mention that AoT compilation also tends to reduce the number of objects overall, especially with whole-program optimization.
Also, people underestimate the cost of runtime magic. Lua 5.2 added a generational collector but then removed it from Lua 5.3. They gave a year or two of warning, but nobody chimed in with use cases where the difference mattered. Removing the generational collector dramatically simplified the GC, which in practice was the better optimization on modern CPUs for real-world workloads where Lua was typically used (which includes server workloads). And this was apparently despite the fact that Lua creates tons of small objects and doesn't implement any fancy runtime optimizations like stack allocation. (The biggest optimization in Lua is probably string interning, though that actually simplifies much of the implementation.)
Over twenty years of Java and people are still far too credulous of the technological feats that JVM implementors promise. Optimizations that make sense in the abstract, even ones based on empirical studies, rarely pan out as expected. The benefits are likely to be fewer and more varied, and those same studies rarely explore possible alternatives or discount alternatives too heavily.
Look, the pressure to publish "results" in computer science is no less intense than elsewhere. When a paper comes out declaring a possible cure for cancer, many people have learned to be highly skeptical and to intuitively understand the inherent limitations and qualifications to such claims. Those same people, though, read computer science publications which much less skepticism than they should.
1 comment
[ 2.2 ms ] story [ 13.9 ms ] threadStronger value semantics also means fewer small objects in the presence of optimization. Not to mention that AoT compilation also tends to reduce the number of objects overall, especially with whole-program optimization.
Also, people underestimate the cost of runtime magic. Lua 5.2 added a generational collector but then removed it from Lua 5.3. They gave a year or two of warning, but nobody chimed in with use cases where the difference mattered. Removing the generational collector dramatically simplified the GC, which in practice was the better optimization on modern CPUs for real-world workloads where Lua was typically used (which includes server workloads). And this was apparently despite the fact that Lua creates tons of small objects and doesn't implement any fancy runtime optimizations like stack allocation. (The biggest optimization in Lua is probably string interning, though that actually simplifies much of the implementation.)
Over twenty years of Java and people are still far too credulous of the technological feats that JVM implementors promise. Optimizations that make sense in the abstract, even ones based on empirical studies, rarely pan out as expected. The benefits are likely to be fewer and more varied, and those same studies rarely explore possible alternatives or discount alternatives too heavily.
Look, the pressure to publish "results" in computer science is no less intense than elsewhere. When a paper comes out declaring a possible cure for cancer, many people have learned to be highly skeptical and to intuitively understand the inherent limitations and qualifications to such claims. Those same people, though, read computer science publications which much less skepticism than they should.