Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Golang's big miss on memory arenas

avittig.medium.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: Golang's big miss on memory arenas

#71

Post by gethly »

I was considering few use cases where arena would make sense and I encountered the "abandoned" arena library in the standard library and then read on why it was never enabled. And yes, in those extremely rare situations, it would be nice to have them. But generally, they make little sense for Go and projects Go is used in. So I definitely do not share any of the opinions from the blog post.

There is Odin, Zig or Jai(likely next year) as new kids on the block and alternatives to the cancer that is Rust or the more mainstream C, C++, Java or even C#.

Go definitely does not have to try and replace any of them. Go has its own place and has absolutely no reason to be fearful of becoming obsolete.

After all, in rare/extreme cases, one can always allocate big array and use flatbuffers for data structures to put into it.

Re: Golang's big miss on memory arenas

#72

Post by jimbokun »

9rx wrote: post #66
Yokohiii wrote: post #55

Earlier quoted context omitted.

Look at PHP. Every year people say PHP got much better then in the dark ages. Yes it got rid of it's rough edges. People solely look positive at it because it has become more familiar with mainstream OOP languages. But it has no identity anymore. It is still simpler for the web then most competitors, but it doesn't matter because you install 30 packages for an hello world anyway. The community doesn't want simplicity…

Newbies want a compelling catchphrase: C: So powerful you can shoot your foot off! Rust: Now that you've shot your foot off, let's not do that a second time. Javascript: It runs on the server and in the browser . Typescript: It runs on the server and in the browser, now with types! In contrast, PHP: Not sure if I want to be a templating language or general-purpose programming language.

PHP is: see your changes by refreshing your browser. At least that was it’s initial appeal.

Re: Golang's big miss on memory arenas

#74

Post by bilbo-b-baggins »

Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks.

If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type.

But like… the write up completely missed that manual memory management exists, and Golang considers it “unsafe” and that’s a design principle of the language.

You could argue that C++ RAII overhead is “bounded performance” compared to C. Or that C’s stack frames are “bounded performance” compared to a full in-register assembly implementation of a hot loop.

But that’s bloody stupid. Just use the right tool for the job and know where the tradeoffs are, because there’s always something. The tradeoff boundary for an individual project or person is just arbitrary.

Re: Golang's big miss on memory arenas

#75

Post by jimbokun »

cyberax wrote: post #33

Go now has memory regions, an automatic form of arenas: https://go.googlesource.com/proposal/+/refs/heads/master/des... I think the deeper issue is that Go's garbage collector is just not performant enough. And at the same time, Go is massively parallel with a shared-everything memory model, so as heaps get bigger, the impact of the imperfect GC becomes more and more noticeable. Java also had this issue, and they spe…

Regions seem like a much cleaner and simpler solution to this problem.

Re: Golang's big miss on memory arenas

#76

Post by jimbokun »

jeffrallen wrote: post #42

The author is confused about how performance tuning works. Step one, get it right. Step two, see if it's fast enough for the problem at hand. There is almost never a step three. But if there is, it's this: Step three: measure. Now enter a loop of "try something, measure, go to step 2". Of the things you can try, optimizing GC overhead is but one of many options. Arenas are but one of many options for how to do that.…

Step 3 is always useful (if not necessary) once you reach a certain scale.

Re: Golang's big miss on memory arenas

#77

Post by bilbo-b-baggins »

foobiekr wrote: post #48
tptacek wrote: post #17

The vibe I get from this post is of someone who hasn't routinely used arenas in the past and thinks they're kind of a big deal. But a huge part of the point of an arena is how simple it is. You can just build one. Meanwhile, the idea that arena handles were going to be threaded through every high-allocation path in the standard library is fanciful.

Two big issues in Golang are that you can't actually build an arena allocator that can be used for multiple types in a natural way. The other is that almost no library is written in such a way that buffer re-use is possible (looking at you, typical kafka clients that throw off a buffer of garbage per message and protobuf). The latter could be fixed if people paid more attention to returning buffers to the caller.

You totally can build it using unsafe and generics. I’ve done it with mmap-backed byte slices for arbitrary object storage.

Re: Golang's big miss on memory arenas

#78

Post by swid »

bilbo-b-baggins wrote: post #74

Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…

This isn't true in practice because you won't be able to control where allocations are made in the dependencies you use, including inside the Go standard library itself. You could rewrite/fork that code, but then you lose access to the Go ecosystem.

The big miss of the OP is that it ignores the Go region proposal, which is using lessons learned from this project to solve the issue in a more tractable way. So while Arenas won't be shipped as they were originally envisioned, it isn't to say no progress is being made.

Re: Golang's big miss on memory arenas

#79

Post by ixwt »

christophilus wrote: post #23
guywithahat wrote: post #6

Earlier quoted context omitted.

I didn't realize odin had a similar threading model to go with built-in channels, that's pretty neat. Odin might be my next toy language

It’s a great little language. I just wish it had a bigger standard library.

Bigger?! What more do you need?! There are also other things that are on the way as well.

Re: Golang's big miss on memory arenas

#80

Post by sheepscreek »

bilbo-b-baggins wrote: post #74

Man this person is mediocre at best. You can do fully manual memory management in Go if you want. The runtime is full of tons of examples where they have 0-alloc, Pools, ring buffers, Assembly, and tons of other tricks. If you really want an arena like behavior you could allocate a byte slice and use unsafe to cast it to literally any type. But like… the write up completely missed that manual memory management exists…

I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution.

If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tried to make.

Your last paragraph captures the tension perfectly. Go just isn’t the tool we thought for some jobs, and maybe that’s okay. If you’re going to count nanoseconds or measure total allocations, it’s better to stick to a non-GC language. Or a third option can be to write your hot loops in one such language; and continue using Go for everything else. Problem solved.

Post reply on HN