Ah, neat! I learned something. :)
You’re mistaken about only numbers and simple structs being stack allocated. All structs are stack allocated unless they escape, regardless of their contents. Further, arrays and constant-sized slices may also be stack allocated. I’m also pretty sure interfaces are only heap allocated if they escape; in other words, if you put a value in an interface and it doesn’t escape, there shouldn’t be an allocation at all.
Structure could be stack allocated, but any of it's fields would not if there is anything but a number.
A trivial example:
https://segment.com/blog/allocation-efficiency-in-high-perfo...
func main() {
x := 42
fmt.Println(x)
}
./main.go:7: x escapes to heap
BenchmarkEscapeInterface-4 50000000 33.3 ns/op 8 B/op 1 allocs/op
BenchmarkEscapeConcreteValue-4 200000000 9.45 ns/op 0 B/op 0 allocs/op
BenchmarkEscapeConcretePointer-4 100000000 10.0 ns/op 0 B/op 0 allocs/op
BenchmarkEscapeArray-4 50000000 21.3 ns/op 0 B/op 0 allocs/op
BenchmarkEscapeStruct-4 100000000 12.8 ns/op 0 B/op 0 allocs/op
type Inner struct {
Slice []int
String string
Int int
}
type Struct struct {
Int int
String string
Nested Inner
}
func (s Struct) AddThings() int {
return s.Int + len(s.String) + len(s.Nested.Slice) + len(s.Nested.String) +
s.Nested.Int
}
func BenchmarkEscapeStruct(b *testing.B) {
for i := 0; i < b.N; i++ {
s := Struct{
Int: 42,
String: "Hello",
Nested: Inner{
Slice: []int{0, 1, 2},
String: "World!",
Int: 42,
},
}
_ = s.AddThings()
}
}I think this matter is sufficiently resolved. Go trades GC throughput for latency and it doesn't need compaction to get good cache properties because it generates much less garbage than traditional GC-based language implementations.
It does. Any language could do static allocation, go is not different from java here, the problem is that in any real code nearly all your strings and arrays would be dynamic, thus heap allocated, as well as interfaces. Consider also that allocations in Go are much more expensive than in java or haskell.
> Consider also that allocations in Go are much more expensive than in java or haskell.
This is true, but unrelated to cache performance, and it's also not a big deal for the same reason--allocations are rarer in Go.
EDIT:
Consider `[]struct{nested []struct{i int}}`. In Go, this is at most 1 allocation for the outer array and one allocation for each nested array. In Python, C#, Haskell, etc, that's something like one allocation for the outer array, one allocation for each object in the array, one allocation for each nested array in each object, and one allocation for each object in each nested array. This is what I mean when I say Go generates less garbage.
A typical example, yeah. I've said about structs of ints already, it's not a common type unfortunately anywhere beyond number crunching, in which go sucks anyway.
In haskell you could have unboxed array with unboxed records. Check Vector.Unboxed.
Yeah, but you were wrong (you said other kinds of structs would escape to the heap). The innermost struct could have a string member and a `*HeapData` member; it wouldn't matter. The difference in number of allocations between Go and others would remain the same. The difference isn't driven by the leaves, it's driven by number of nodes in the object graph; the deeper or wider the tree, the better Go performs relative to other GC languages.
> In haskell you could have unboxed array with unboxed records. Check Vector.Unboxed.
For sure, but in Go "unboxed" is the default (i.e., common, idiomatic); in Haskell it's an optimization.
It's a rigid term:
https://en.wikipedia.org/wiki/Tracing_garbage_collection#Pre...
perf shows how much time does GC eat, and that's quite a lot. Thus in the majority of benchmarks go lags behind java or on par with it at best.
>there is so much less garbage than in other GC languages
That is not true since strings and interfaces are heap allocated thus the only stack allocated objects are numbers and very simple structs (i.e. which contains only numbers), so you would have a lot of garbage unless you are doing a number crunching, which could be easily optimized by inlining and register allocation anyway.