[HN Gopher] My Experience of building Bytebeat player in Zig
___________________________________________________________________
My Experience of building Bytebeat player in Zig
Author : KMJ-007
Score : 75 points
Date : 2025-11-04 11:10 UTC (3 days ago)
(HTM) web link (blog.karanjanthe.me)
(TXT) w3m dump (blog.karanjanthe.me)
| kragen wrote:
| 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.
| diek wrote:
| 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.
| ww520 wrote:
| 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.
| bikeshaving wrote:
| 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.
| mitchellh wrote:
| 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.
| im3w1l wrote:
| 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.
| dundarious wrote:
| 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...
| im3w1l wrote:
| I know what arenas are but I don't see how passing
| something explictly vs implicitly matters except for
| which style people prefer?
| throwawaymaths wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-07 23:00 UTC)