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

61–70 of 157 posts

Re: Golang's big miss on memory arenas

#61

Post by UncleEntity »

tptacek wrote: post #29
ndr wrote: post #26

Earlier quoted context omitted.

I'm curious, do you have any arena experience out of c/cpp/rust/zig? It may be that you can "just" build one, but you can't "just" use it and expect any of the available libraries and built ins to work with it. How many things would you have to "just" rewrite?

There was never a proposal to automate arenas in Go code, and that wouldn't even make sense: the point of arenas is that you bump-allocate until some program-specific point where you free all at once (that's why they're so great for compiler code, where you do passes over translation units and can just do the memory accounting at each major step). (Yes: I used arenas a lot when I was shipping C code; they're a very e…

> Yes: I used arenas a lot when I was shipping C code; they're a very easy way to get big speed boosts out of code that does a lot of malloc

This is something I look forwards to exploring later in my current pet project, right now it has possibly the stupidest GC (just tracks C++ 'new' allocated objects) but is set up for drop in arena allocation with placement new so, we'll see how much that matters later on. There are two allocation patterns, statements and whatnot get compiled to static continuation graphs which push and pop secondary continuations and Value objects to do the deed so, I believe, the second part with the rapid temporary object creation will see the most benefit.

Anyhoo, slightly different pattern where the main benefits will most likely be from the cache locality or whatever, assuming I can even make a placement new arena allocator which is better than the performance of the regular C++ new. Never know, might even add more overhead than just tracking a bunch of raw C++ pointers as I can't imagine there's even a drop of performance which C++ new left on the table?

Re: Golang's big miss on memory arenas

#62

Post by riku_iki »

silisili wrote: post #30

I'm a bit split on this one. Simple arenas are easy enough to write yourself, even if it does make unidiomatic code as the author points out. Pretty much anything that allocates tons of slices sees a huge performance bump from doing this. I -would- like that ability in an easier fashion. On the other, hand, new users will abuse arenas and use them everywhere because "I read they are faster", leading to way worse code…

> Simple arenas are easy enough to write yourself

you can write arena yourself, but it is useless if lang doesn't allow you to integrate it, e.g. allocate objects and vars on that arena..

Re: Golang's big miss on memory arenas

#65

Post by twoodfin »

Pet_Ant wrote: post #56

> The real reason was the “Infectious API” problem. To get performance benefits, you can’t just create an arena locally; you have to pass it down the call stack so functions can allocate inside it. This forces a rewrite of function signatures. Sorry, but it doesn't seem that difficult (famous last words). Add a new implicit parameter to all objects just like "this" called "thisArena". When a call to any allocation is…

That design introduces two kinds of overhead at runtime:

- You need a pointer to the allocator (presumably you’d want to leave room for types beyond arenas). That’s 8 bytes of extra size on every object.

- You need to dynamically dispatch on this pointer for every allocation. Dynamic dispatch is a lot cheaper than it used to be on modern architectures, but it’s a barrier for basic inlining, which is a big deal when alloc() for an arena is otherwise just a pointer bump.

Re: Golang's big miss on memory arenas

#66

Post by 9rx »

Yokohiii wrote: post #55
andrewcamel wrote: post #44

Philosophical question, but after reaching critical mass, should languages even aspire to more? I.e. do you risk becoming "master of none"? What's wrong with specialist languages? I.e. best of breed vs best of suite? I agree with author Go is getting squeezed, but it has its use cases. "COBOL of could native" implies it's not selected for new things, but I reach for it frequently (Go > Java for "enterprise software"…

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.

Re: Golang's big miss on memory arenas

#67

Post by fpoling »

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.

Rust also suffers from libraries returning a newly allocated strings and vectors when the code should allow to pass a pre-existing string or vector to place the results.

Granted the latter leads to more verbose code and chaining of several calls is no longer possible.

But I am puzzled that even performance-oriented libraries both in Go and Rust still prefer to allocate the results themselves.

Re: Golang's big miss on memory arenas

#68

Post by acmj »

Going from something like "Go lacks a builtin arena allocation" to "Go risks becoming the COBOL" is a long stretch. First, Go is slower than C/C++/rust without complex memory allocation. Introducing an arena allocator won't fix that. Second, arena allocation often doesn't work for a lot of allocation patterns. Third, plain arena allocator is easy to implement when needed. Surely a builtin one would be better but Go won't fall without it.

Re: Golang's big miss on memory arenas

#69

Post by silisili »

riku_iki wrote: post #62
silisili wrote: post #30

I'm a bit split on this one. Simple arenas are easy enough to write yourself, even if it does make unidiomatic code as the author points out. Pretty much anything that allocates tons of slices sees a huge performance bump from doing this. I -would- like that ability in an easier fashion. On the other, hand, new users will abuse arenas and use them everywhere because "I read they are faster", leading to way worse code…

> Simple arenas are easy enough to write yourself you can write arena yourself, but it is useless if lang doesn't allow you to integrate it, e.g. allocate objects and vars on that arena..

You can, for some things, but it's a rather ugly process. I've mainly used it with slices and strings. So not useless, but certainly not full featured or simple.

Re: Golang's big miss on memory arenas

#70

Post by openasocket »

Frankly, it’s not a lack of arenas that is holding Go back. It’s the fact that, in 2025, we have a language with a runtime that is neither generational nor compacting. I can’t trust the runtime to perform well, especially in memory-conscious, long-running programs.
Post reply on HN