NRK <nrk_AT_disroot.org> wrote:
> Below are two of the most impactful changes. I was going to elaborate on
> these but it was getting *really* long very quickly so I've kept it to a
> brief overview followed by a real-world project that demonstrates these
> techniques.
I completely agree. Since trying sized strings/fat pointers and
learning about Arenas I have used them in every project I have
written. Both of these techniques lead to faster code with fewer
bugs and usually in less total lines.
> (Do note that this "style" of C programming quite different to the
> suckless one, so I wouldn't be surprised if it generates some
> "backlash".)
In my view the suckless "style" on the aforementioned page is
entirely dogma and should be ignored. To me the only thing that
matters is writing code which minimizes the amount of end user
time waste (both in terms of runtime and lost time to bugs/poor
usability). As far as I can tell not a single item in the suckless
"style" serves towards meeting this goal.
> Region based memory management
> ------------------------------
> [...]
> You can make many of them and then discard them all in one call.
>
Why even bother with making a call? Usually I partition my Arenas
at startup into permanent and temporary parts. The temporary part
gets passed around on the stack and is thus reset when the scope
exits. For example a "frame allocator":
Arena frame_storage = new_arena(size); /* or from the bulk arena at startup */
while (!ctx->window_should_close) {
do_work(ctx, frame_storage);
/* any allocations made in frame_storage are discarded
* when the loop restarts */
}
In this way it is completely free* (I'm sure you know this NRK).
Of course this involves passing structs around by value which I'm
sure is not suckless approved but it makes literally no difference
to the CPU unless the struct's size is very big (Arenas can be
done in 16 bytes which is small compared to the 64 byte vector
registers on newish CPUs).
* May involve a stack pointer move if for whatever reason
frame_storage was not passed in through a register.
- Randy
--
https://rnpnr.xyz/
GPG Fingerprint: B8F0 CF4C B6E9 415C 1B27 A8C4 C8D2 F782 86DF 2DC5
- application/pgp-signature attachment: stored
Received on Sat Jun 22 2024 - 06:45:41 CEST