31–40 of 78 posts
Is there one for Kotlin yet? It's pretty pathetic that Google's own protocol lacks native support for its most popular operating system.
Earlier quoted context omitted.
Do I misunderstand what arenas are? I thought it was just "allocate this big array as a single allocation rather than N little allocations"? If so, how is that not supported in Go? (e.g., `arena := make([]Foo, 1000000000)`)
An arena allocator allows you to store many allocations _of different types_ in the same single chunk of memory, and then free all of them at one point in time.
Using CPU utilization as a performance metric can be extremely misleading. My favorite article on the subject is from Brendan Gregg: http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-... A much better way to test the influence of the new compiler would be to test the actual throughput at which saturation is achieved (which is what the benchmark in the C++ grpc library measure to assess their performance).
Earlier quoted context omitted.
An arena allocator allows you to store many allocations _of different types_ in the same single chunk of memory, and then free all of them at one point in time.
Why can't you do this in Go? I'm 99% sure we can allocate a massive array of bytes using safe Go and use unsafe to cast a chunk of bytes to an instance of a type. This isn't type safe, but neither would the equivalent C code.
Earlier quoted context omitted.
GP meant 5 orders of magnitude below "20 ms". 20 ms is a lot of time. There is nothing one can do to a, say, a 1 kilo byte buffer that will cross 1 ms in any language. My own Go code doesn't cross more than few micros per message.
GP's root claim is that protobuf serialization/deserialization performance shouldn't matter, on an article where a user is specifically demonstrating that it does matter .
Earlier quoted context omitted.
Why can't you do this in Go? I'm 99% sure we can allocate a massive array of bytes using safe Go and use unsafe to cast a chunk of bytes to an instance of a type. This isn't type safe, but neither would the equivalent C code.
That's what this whole thread is about: you can literally do just that.
I don't know how you get that from the thread:
> Arenas are, however, unfeasible to implement in Go because it is a garbage collected language.
> If you are willing to use cgo, google already implemented one for gapid.
> there are other garbage collected languages like D, Nim and C# that offer the language features to do arenas without having to touch any C code.
It seems like the above statements implicitly or explicitly claim that this isn't feasible in Go without C.
Earlier quoted context omitted.
That's what this whole thread is about: you can literally do just that.
> That's what this whole thread is about: you can literally do just that I don't know how you get that from the thread: > Arenas are, however, unfeasible to implement in Go because it is a garbage collected language. > If you are willing to use cgo, google already implemented one for gapid. > there are other garbage collected languages like D, Nim and C# that offer the language features to do arenas without having to…
Both of us are dismissing the assertion that "Arenas are, however, unfeasible to implement in Go because it is a garbage collected language."
You can do manually memory allocation via a syscall into the host OS, use unsafe to cast memory blocks to the types that you want and then clean it all up with defer, assuming the arena is only usable inside a lexical region, otherwise extra care is needed to avoid leaks.
Earlier quoted context omitted.
That's what this whole thread is about: you can literally do just that.
> That's what this whole thread is about: you can literally do just that I don't know how you get that from the thread: > Arenas are, however, unfeasible to implement in Go because it is a garbage collected language. > If you are willing to use cgo, google already implemented one for gapid. > there are other garbage collected languages like D, Nim and C# that offer the language features to do arenas without having to…
I _think_ allocating a slice of contiguous bytes and using unsafe pointers should work fine as long as you are very cautious about structs/vars with pointers into the buffer getting freed by the GC.