My Experience of building Bytebeat player in Zig(blog.karanjanthe.me)
blog.karanjanthe.me
My Experience of building Bytebeat player in Zig
https://blog.karanjanthe.me/posts/zig-beat/
16 comments
Arena Allocator is great, especially for periodic frame based allocations, e.g. rendering loop, game loop, request handling, etc. You just reset the arena at the end of every frame. It has the feature to reset and retain the memory allocated underneath. It's just a reset of the arena pointer.
I would love to see a blogpost about the advantages of different Zig allocators (page, arena, fixed buffer, more?) and practical use-cases. Right now, I’m just thinking “this is the thing I pass through all my functions,” and it’s usually just the std.heap.page_allocator. Imagine we get to a period where people are writing games, web UIs, servers directly in Zig. I think the way allocators are used is likely to be the most interesting part.
The answer to this is not Zig specific (and predates Zig). I'm guessing good blog posts exist but I don't have a link handy, sorry. If not, I agree one should be written.
Don't sleep on the StackFallbackAllocator either, which will try to use a certain amount of stack space first, and only if it overflows that space will it fallback to another allocator (usually the heap but you can specify). This can speed up code a lot when the common case is small values with periodic very large values.
Don't sleep on the StackFallbackAllocator either, which will try to use a certain amount of stack space first, and only if it overflows that space will it fallback to another allocator (usually the heap but you can specify). This can speed up code a lot when the common case is small values with periodic very large values.
> the common case is small values with periodic very large values
I find that a common scenario here is parsers where "Real world" input will tend to be small but you're also exposed to adversarial input. e.g. a parser for function prototypes would typically not expect to see more than 16 arguments in the wild, but you still need to handle it without erroring in case someone decides to send a 1000-argument function through your parser.
I find that a common scenario here is parsers where "Real world" input will tend to be small but you're also exposed to adversarial input. e.g. a parser for function prototypes would typically not expect to see more than 16 arguments in the wild, but you still need to handle it without erroring in case someone decides to send a 1000-argument function through your parser.
please remember that the page allocator makes an expensive kernel call on each alloc/free call, so if allocation is frequent you may want at least a bump allocator on top. if you don't mind linking libc, for default use cases, c_allocator might be a better choice, as malloc is a quite battle tested general purpose allocator.
My thought when reading this, as someone who has never used zig, wouldn't it be easier with a global (thread local) variable? If you don't care you don't touch it. If you you do care you change it and restore it when you are done with whatever you were doing.
Doing that seems like it's just manually replicating a call stack (with potential for error); I don't see what the benefit is. Making functions independent of global state - and allocation is a huge source of implicit dependency on global state - is generally considered good programming practice.
You can use regular buffers for many things, but a lot of core Zig std functions require an allocator (satisfying std.mem.Allocator interface) as an argument. This means the developer retains control of how memory is managed. It's also advantageous for testing, as you can pass in specialized allocator for detecting memory leaks during testing but use the more efficient allocator for release mode. You can wrap regular buffer into a FixedBufferAllocator which just uses stack values. ArenaAllocator is just a container that wraps an underlying allocator but it will free everything when you call defer arena.deinit(), which is useful for short-lived things like http requests.
That would get you almost none of the benefits of arenas and other types of allocators. Recommend https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...
I know what arenas are but I don't see how passing something explictly vs implicitly matters except for which style people prefer?
For one, you don't want exactly one arena or allocator for all tasks.
Well you couldn't you just use a different one in that case? The variable would just be like a suggestion.
Most programmers don't prefer thread local mutable state over a single pointer argument. Especially for general purpose code (i.e., not specific to a single purpose/project). With the mutable state version, you have to clearly define which state you're using and when (which named allocator/arena variable), and if you're mutating it in place and then restoring it, there can be some pretty obvious issues.
Given this thread is completely off the rails from anything specific to allocators or arenas, and even Zig, I will now exit.
Given this thread is completely off the rails from anything specific to allocators or arenas, and even Zig, I will now exit.
I took a similar approach when I wrote a bytebeat player in CPython for a nightclub performance (https://github.com/kragen/pytebeat), but I used a shunting-yard parser rather than a Pratt parser.
From the description I thought the expression was a function of only 't', and there was no (for instance) accumulation of the previously computed byte. Then in the image I saw the same value of 't' evaluating to different values:
t=1000: 168 t=1000: 80
Reading the source: https://github.com/KMJ-007/zigbeat/blob/main/src/evaluator.z...
It does look like the expression is a pure function of 't', so I can only assume that's a typo.
t=1000: 168 t=1000: 80
Reading the source: https://github.com/KMJ-007/zigbeat/blob/main/src/evaluator.z...
It does look like the expression is a pure function of 't', so I can only assume that's a typo.
[deleted]