4 ms·

>Not sure what you mean by imprecise It's a rigid term: https://en.wikipedia.org/wiki/Tracing_garbage_collection#Precise_vs._conservative_and_internal_pointer

>Not sure what you mean by imprecise It's a rigid term: https://en.wikipedia.org/wiki/Tracing_garbage_collection#Precise_vs._conservative_and_internal_pointers 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.

weberc2 8y ago
> It's a rigid term 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.
- ernst_klim 8y ago
  Both arrays and interfaces are heap allocated. Slice is just a pointer to a heap allocated array. 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-performance-go-services/ https://segment.com/blog/allocation-efficiency-in-high-perfo... func main() { x := 42 fmt.Println(x) } ./main.go:7: x escapes to heap So a trivial interface cast leads to allocation.
  - weberc2 8y ago
    Looks like you're right about interfaces (full benchmark source code: https://gist.github.com/weberc2/87d2fdc379065a2765d1c9f490ad8f9e https://gist.github.com/weberc2/87d2fdc379065a2765d1c9f490ad...)! 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 But arrays are stack allocated: BenchmarkEscapeArray-4 50000000 21.3 ns/op 0 B/op 0 allocs/op And structs are stack allocated, as are their fields--even fields that are structs, slices, and strings!: BenchmarkEscapeStruct-4 100000000 12.8 ns/op 0 B/op 0 allocs/op The code: 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() } }
    - ernst_klim 8y ago
      I'm sure your strings are not stack allocated, they are statically allocated (and would be statically alocated in any language). Not sure about arrays, but dynamic arrays should be dynamically allocated do, your arrays are static probably. They would be heap allocated, if you would use make.
      - weberc2 8y ago
        It doesn't matter whether they're stack allocated or statically allocated; neither is garbage, contrary to the original claim ("Go generates a lot of garbage except when dealing with numeric code"). The subsequent supporting claims ("structs with non-numeric members are heap-allocated", "struct fields that are not numbers are heap allocated", etc) were false (sometimes non-numeric members are heap allocated, but they're often not allocated and never because they're non-numeric and their container is never heap allocated on the basis of the location of the member data). 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.
        ernst_klim 8y ago
        >It doesn't matter whether they're stack allocated or statically allocated 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.
        weberc2 8y ago
        We're talking past each other. My claim was that Go doesn't need compaction as badly as other languages because it generates less garbage. You're refuting that with "yeah, well it still generates some garbage!". Yes, strings and arrays will often be dynamic in practice, but an array of structs in Go is 1 allocation (at most); in other many other languages it would be N allocations. > 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.

weberc2 8y ago

> It's a rigid term 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.

ernst_klim 8y ago
Both arrays and interfaces are heap allocated. Slice is just a pointer to a heap allocated array. 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-performance-go-services/ https://segment.com/blog/allocation-efficiency-in-high-perfo... func main() { x := 42 fmt.Println(x) } ./main.go:7: x escapes to heap So a trivial interface cast leads to allocation.
- weberc2 8y ago
  Looks like you're right about interfaces (full benchmark source code: https://gist.github.com/weberc2/87d2fdc379065a2765d1c9f490ad8f9e https://gist.github.com/weberc2/87d2fdc379065a2765d1c9f490ad...)! 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 But arrays are stack allocated: BenchmarkEscapeArray-4 50000000 21.3 ns/op 0 B/op 0 allocs/op And structs are stack allocated, as are their fields--even fields that are structs, slices, and strings!: BenchmarkEscapeStruct-4 100000000 12.8 ns/op 0 B/op 0 allocs/op The code: 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() } }
  - ernst_klim 8y ago
    I'm sure your strings are not stack allocated, they are statically allocated (and would be statically alocated in any language). Not sure about arrays, but dynamic arrays should be dynamically allocated do, your arrays are static probably. They would be heap allocated, if you would use make.
    - weberc2 8y ago
      It doesn't matter whether they're stack allocated or statically allocated; neither is garbage, contrary to the original claim ("Go generates a lot of garbage except when dealing with numeric code"). The subsequent supporting claims ("structs with non-numeric members are heap-allocated", "struct fields that are not numbers are heap allocated", etc) were false (sometimes non-numeric members are heap allocated, but they're often not allocated and never because they're non-numeric and their container is never heap allocated on the basis of the location of the member data). 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.
      - ernst_klim 8y ago
        >It doesn't matter whether they're stack allocated or statically allocated 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.
        weberc2 8y ago
        We're talking past each other. My claim was that Go doesn't need compaction as badly as other languages because it generates less garbage. You're refuting that with "yeah, well it still generates some garbage!". Yes, strings and arrays will often be dynamic in practice, but an array of structs in Go is 1 allocation (at most); in other many other languages it would be N allocations. > 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.