Hacker News
points by the-tomster 2 days ago | 0 comments
If you don't like arenas then that will push you towards avoiding allocations :)

I don't love malloc / free, managing frees one-to-one with allocations is a nightmare. An HTTP server is actually a great example of a good fit for arenas... you can have an arena created per connection, and then free the arena when the connection closes. Now all of your allocations during that connection are guaranteed to be freed instead of having to keep track of them individually. Need something to live across connections? Use the general purpose allocator for those particular things.

For one shot programs, why bother freeing anything at all? The gpa or malloc or whatever else is fine there.

Personally I mostly lean on fixed-size buffers, but if I'm writing Zig it's just little toy programs where blowing up when the buffer runs out of room is fine. But for big non-toy programs it might be good to use fixed-size buffers anyway and define your limits in terms of things actually relevant to your domain.

RAII and smart pointers are fine too, but C++ has you covered if you want those. Zig is specifically avoiding that kind of invisible code that destructors bring you.

[–] grg0 2 days ago
> Now all of your allocations during that connection are guaranteed to be freed instead of having to keep track of them individually

And how do you size the arena?

> keep track of them individually

I think this is an exaggeration of the problem. This is what RAII semantics in C++ are for.

> avoiding that kind of invisible code

The invisible code is traded for defer statements right after initialization that are obvious and therefore mostly just noise, and also a problem if you forget to call them. This isn't an issue with RAII. I get the point of not wanting invisible code, but defers don't seem much of an improvement either. A trade-off at best.

[–] the-tomster 2 days ago
> And how do you size the arena?

Two options: you either say "eh 20MB per request ought to be big enough" and resize it later if you need to. Or you take time to figure out reasonable limits in terms of whatever domain you're dealing with, and return descriptive errors when those limits are exceeded. Maybe you're saying your service supports up to N HTTP headers and M query parameters in the URL and so on. For almost anything there's a limit you can place that's reasonable. Having no limits at all just means the limit is when you run out of memory / disk / whatever.

If you like RAII and C++ just use that though, Zig is an alternative not an upgrade, imo.

[–] grg0 1 day ago
The problem is not finding limits, although that does take decent engineering for anything non-trivial. The problem is that a hard limit assumes your requests have a relatively uniform distribution of memory requirements. Otherwise, you are wasting memory. Or you have N limits instead, which just complicates the problem.

Resize: realloc invalidates pointers. If you're saying allocate more chunks and link them, that is technically no longer an arena?

Requesting virtual memory and committing lazily seems a good trade-off except on Windows, which does not allow to over-commit. Somehow I don't find that very satisfying because it relies on the OS and on the hardware to provide virtual memory support. But maybe it's just what it is.

[–] palata 1 day ago
> Two options: you either say "eh 20MB per request ought to be big enough"

"Memory is cheap" and all that? :-)

[–] MrBuddyCasino 1 day ago
Can arenas be made to use no actual memory unless it is being used, so the virtual memory subsystem only allocates pages when written to?
[–] the-tomster 1 day ago
Yup! In C you can mmap out a big anonymous region and then it will only take up actual resident space for pages you use. I'm not sure if Zig exposes this in the stdlib somewhere or if you'd just do it through libc.

If you're doing something like per-request or per-frame arenas you can clear the arena without having to reallocate the whole mapping. And depending how fancy you want to get you can mark the pages unused when you clear the arena so that the OS can reclaim them if needed.

[–] rallyroger 1 day ago
>And how do you size the arena?

Should you allow an http-server to allocate unbounded request sizes? Seems like it would lead to an easy denial of service.

[–] grg0 1 day ago
As opposed to allocating a bunch of memory you won't need?

Allocating virtual memory up front and committing lazily might be a good trade-off, until it isn't. So I'm not actually sure and hence why I asked the question.

[–] lenkite 2 days ago
> And how do you size the arena?

All HTTP servers have a configurable maximum request size. Ex: client_max_body_size in Nginx.

[–] grg0 1 day ago
Not to take away from your point, but client_max_body_size "Sets the maximum allowed size of the client request body." That is different from how much the server/service is allowed to allocate internally to service the request.
[–] lenkite 1 day ago
Yes, my bad, replied in a hurry. Technically, the arena size will be function involving both the request body size, the response body size, along with the sizes of any intermediate results of processing.
[–] flohofwoe 1 day ago
> This is what RAII semantics in C++ are for.

...which typically has more overhead than a good GC though and much more overhead than using arenas for lifetime management.

[–] i2talics 2 days ago
> If you don't like arenas then that will push you towards avoiding allocations

I mean push in the sense of a pit-of-success, not making me do things because the alternative is unpalatable.

> managing frees one-to-one with allocations is a nightmare

It really isn't a nightmare if your language has tools to help you. I'm never particularly concerned about frees in Rust outside of thinking about room to optimize.

> Need something to live across connections? Use the general purpose allocator for those particular things.

Well, this is a determination you have to make very carefully and if you screw it up (like in the situation I was trying to outline) you have a subtle bug.

> Personally I mostly lean on fixed-size buffers, but if I'm writing Zig it's just little toy programs where blowing up when the buffer runs out of room is fine.

What's also fine is using malloc, which will have perfectly reasonable performance for your toy programs.

This is reinforcing my belief that Zig programmers actually just have a sort of aesthetic attachment to the idea of managing their allocations themselves and this has very little to do with the actual practical concerns of writing software that works. I'm a lot more sympathetic to the other reply that talked about library code improving flexibility for those relying on the library, than this comment that only thinks about the case where everything goes perfectly and using a fixed size buffer for no reason.

[–] nvme0n1p1 2 days ago
> I'm never particularly concerned about frees in Rust outside of thinking about room to optimize.

Zig's position, love it or hate it, is that you should be thinking about it. Dropping a Vec<String> in Rust is O(n). Have you ever clicked the X on an app and it takes 10 seconds to disappear? Stuff like this is part of the problem. You shouldn't have to traverse your process's whole memory space just to call exit(0).

If you have to write that for loop, the O(n) will jump out at you and push you towards an arena or FixedBufferAllocator or std.process.cleanExit, or any other solution to avoid the loop.

[–] kibwen 2 days ago
Dropping vecs that contain strings does not make any Rust code in the real world slow. You would need to have a vec containing billions of strings, occupying several gigs of memory, before dropping such a structure took any perceptible amount of time. And for extreme cases like that, you can simply use arenas. The bumpalo crate is approximately as old as Zig is. The reason that people so rarely turn to arenas in Rust isn't because you can't do them, because you've always been able to, but rather because arenas are a very specific solution to a specific sort of memory access pattern, and going out of your way to strictly adhere to that pattern doesn't produce measurable differences for most software.
[–] lunar_mycroft 1 day ago
Disclaimer at the start: Rust is my favorite language, this very much isn't an attack on Rust.

> Dropping vecs that contain strings does not make any Rust code in the real world slow. You would need to have a vec containing billions of strings, occupying several gigs of memory

I actually had a hobby project where that became very noticeable/too slow for my requirements at around 800k Strings, so several orders of magnitude less than your estimate. Switching to a solution that freed all the memory at once predictably made it run effectively instantly.

> And for extreme cases like that, you can simply use arenas

I think this is a fundamentally flawed way of thinking about things. Yes, each individual string allocation and drop isn't going to cost much, but in combinations with all the other similar decisions you're likely making if you think this way, plus the decisions of library authors, etc, it can add up even if strings specifically aren't a major problem. Avoiding pessimization by default instead of only when you can't ignore them any more is a good habit to be in.

[–] kibwen 1 day ago
Arenas aren't a free lunch either. You need a specific sort of memory access pattern, where large, conceptually related chunks of memory are being rapidly and predictably reclaimed, and if you don't have such a pattern then arenas are ceremony for no benefit. And the performance tradeoff is that you end up using more total memory than RAII because you're no longer eagerly reclaiming memory the moment it stops being used, but purposefully delaying your frees so that you can batch-reclaim it all at once. There are many cases where this makes sense, which, to reiterate, is why crates like bumpalo exist, which work gloriously well with Rust's lifetime system.
[–] lunar_mycroft 1 day ago
I agree that arenas aren't always the best choice, but I think you're underestimating how often they are. Not only does a lot of software have elements that are well suited to arenas (request handling for web servers, frames for games and UI, etc), but a lot of allocations are for short lived intermediary values anyway (the stack is basically an arena with a bit less flexibility).

(Also, you do not need to sell me on bumpalo, I use it heavily already)

[–] tialaramex 1 day ago
> Stuff like this is part of the problem.

Measure, measure, measure.

So often when people insist that a thing they don't like is "part of the problem" they haven't even thought about how much that "part" would be, although I suppose it's worse when they have thought and decided to go ahead anyway because the weasel wording might convince the hard of thinking.

A guy who rounded up from $14.86 to $15 on some grant paperwork and got 14 cents he wasn't entitled to out of a government programme, and Ken Paxton inexplicably becoming very wealthy from a government job are both "part of the problem" but hopefully it's apparent which of these is worth fixing.

[–] simonask 2 days ago
Just to let you know, `std::process::exit(...)` in Rust does not call any destructors. C++ also has `std::quick_exit(...)`. Applications exiting slowly is a problem caused by app developers.

(There are cases where it also takes time because the OS does have to flush all open files during process teardown, etc., but this shouldn't generally be user-visible.)

[–] the-tomster 2 days ago
> This is reinforcing my belief that Zig programmers actually just have a sort of aesthetic attachment to the idea of managing their allocations themselves and this has very little to do with the actual practical concerns of writing software that works.

Indeed if you don't want to manage everything yourself I don't think there's a need to use Zig. The whole pitch is making everything explicit and not hiding control flow. And I do think that limits its usefulness to smaller-scale codebases.

Writing quality software doesn't require much from the programming language until your codebase gets very large and you're collaborating with a ton of people. If I'm expecting a codebase to grow to a large scale I'm not reaching for Zig for that. I don't trust _myself_ to keep that much Zig code tidy and correct let alone a big mob of developers and agents :)

[–] alextingle 1 day ago
My opinion is quite the opposite.

With a small program, it's rarely difficult to work out what's going on. If your small program develops a performance problem, it's usually fairly tractable to work out what's going on, and modify it. In extremis, you can just rewrite the whole thing.

Large programs are another matter. Hidden control flows in C++ (for example) can make pinning down performance problems extremely difficult. And then widespread refactoring can be extremely challenging.

Zig forces everything to be an explicit interface, which should make maintenance work on large programs much more tractable.