I think thread pools are one of those solved problems that the silent majority of C programmers has solved ages ago and doesn’t release open source projects for. I’ve also written my 300 line for pool and allocator together and always laughed at taskflow, rayon, etc.. Even NUMA is easy with arena allocation. When casey muratori of the handmade network said the same thing I remember agreeing and he got made fun of for it.
BTW the for-case can simply be supported by setting a pool/global boolean and using that to decide how to wait for a new task (during the paralle for the boolean will be true, otherwise do sleeps with mutexes in the worst case for energy saving)
I'd love to learn more about this. What resources/books/articles/code can I look at to understand this more? Or, if you have some time, would you mind expanding on it?
The parts I'm specifically interested in:
1. What the 300 line pool and allocator look like
2. What this means: "BTW the for-case can simply be supported by setting a pool/global boolean and using that to decide how to wait for a new task (during the paralle for the boolean will be true, otherwise do sleeps with mutexes in the worst case for energy saving)"
This stuff is sometimes difficult to search for because people don’t name it or there are many different names.
Arena allocation on windows for example is basically calling VirtualAlloc for a couple gigabytes on a 64 bit system (you have terabytes of virtual memory available) and then slicing it up into sub-ranges that you pass as parameters to threads grouped hierarchically for each cpu and then within that each group of cores that share cache and then single cores for their own cache memory. Lock the software threads to their hardware threads and done. Then for each arena use bump and maybe pool allocators for most stuff. Very basic and little code, much higher performance than most software out there. It’s also why a lot of diehard C programmers find rust lifetime management overengineered and boring btw because you don’t have so many lifetimes as modern C++ code for example.
For the boolean stuff look at the “better software conference” youtube talk about that video game physics engine for example (sorry, I’m on my phone on the jump). Again, old ideas being rediscovered
I totally agree — most C/C++ developers with 10+ years of experience have built similar thread pools or allocators in their own codebases. I’d include myself and a few of my former colleagues on that list.
That said, closed-source solutions for local use aren’t quite the same as an open-source project with wider validation. With more third-party usage, reviews, and edge cases, you often discover issues you’d never hit in-house. Some of the most valuable improvements I’ve seen have come from external bug reports or occasional PRs from people using the code in very different environments.
> When casey muratori of the handmade network said the same thing I remember agreeing and he got made fun of for it.
Casey Muratori, while a great programmer in his own right, often disregards the use cases, which leads to apple-to-orange comparisons. E.g., why is this ASCII editor from 40 years ago much faster than this Unicode (with full ZWC joining emoji suite) text editor?
in general I see two types of Python in the wild:
- simple self-contained scripts, everything is a free function, no type hints
- over-engineered hierarchies of classes spread over dozens of files and modules, type hints everywhere
I personally largely prefer the first kind, but it seems even the standard formatting rules are against it (two empty lines between free functions etc.)
I've always been very careful about dependencies, and freezing them to versions that are known to work well.
I was shocked when I found out that at some of the most profitable shops, most of their code is just a bunch of different third-party libraries badly cobbled together, with only a superficial understanding of how those libraries work.
The nuclear industry did say that this would happen but the reality was the exact opposite:
>According to research institute Fraunhofer’s Energy Charts, the plant had a utilisation ratio of only 24% in 2024, half as much as ten years before, BR said. Also, the decommissioning of the nearby Isar 2 nuclear plant did not change the shrinking need for the coal plant, even though Bavaria’s government had repeatedly warned that implementing the nuclear phase-out as planned could make the use of more fossil power production capacity necessary.
You can just use your native windowing system to achieve what you want, instead of implementing a poor version of one with clear accessibility issues within a browser window.
It would require a completely different design to video games.
Current video games are designed around streamlining content. As a player, your job is to extract all content from an area before going to the next. That's why most areas are designed as linear corridors so that there is a straightforward progression, and most NPCs interactions are meant to offer something meaningful so as to not waste the player's time.
But imagine if interaction with NPCs wasn't just a content delivery mechanism, but instead could sometimes be rewarding, sometimes useless, dynamically adjusted in how you interact with the world in non-predictable ways.
The player would just waste their time in their usual approach of canvasing each new area, which would become unsustainable. There would be no reliable way of ensuring you've extracted all the content. All he/she could do is roam around more naturally, hoping the glimpses they catch are engaging and interesting enough.
Maybe a new player skill would be to be able to identify the genuine threads of exciting content, be it designed or emergent, within the noise of an AI-generated world.
Realistically though, how do you build an exciting player experience with this framework? A starting point might be to approach it as something more akin to LARP or improvisation theater, you'd give each NPC and player a role they need to fulfill. Whether players actually enjoy this is another thing entirely.
> But imagine if interaction with NPCs (…) instead could sometimes be rewarding, sometimes useless, dynamically adjusted in how you interact with the world in non-predictable ways.
That’s a slot machine, and the same mechanism which also gets us hooked on social media. Sounds like something which would immediately be exploited by vapid addiction-as-a-feature games à la FarmVille.
> The player would just waste their time in their usual approach of canvasing each new area, which would become unsustainable. There would be no reliable way of ensuring you've extracted all the content.
Sounds frustrating. Ultimately games should be rewarding and fun. Constraints are a feature.
> All he/she could do is roam around more naturally, hoping the glimpses they catch are engaging and interesting enough.
Good reminder to go take a walk outside. Take a train to somewhere we haven’t been. Pick a road we’ve never crossed. We don’t even need a mini map, and sucks that we don’t have teleportation back to base, but we do have a special device which always points the way back.
> Realistically though, how do you build an exciting player experience with this framework? (…) Whether players actually enjoy this is another thing entirely.
Agreed. Though not enjoying it and abandoning it is fine, I’m more worried about people not enjoying it but feeling unable to quit (which already happens today, but I think the proposed system would make it worse).
>> There would be no reliable way of ensuring you've extracted all the content.
> Sounds frustrating. Ultimately games should be rewarding and fun.
this seems to assume that the only way to feel rewarded / have fun is by comprehensively extracting content from the game. in order to have fun in an "emergent" generative game of this nature, you'd need to let go of that goal.
i do agree with the risks surrounding engineered engagement.
> this seems to assume that the only way to feel rewarded / have fun is by comprehensively extracting content from the game.
Not my intention, that is not something I believe. I’m not a completionist (I get those who are, but to me it can get boring or stressful) and I see the appeal in sandbox games (even if I don’t usually play them).
> Some games are designed around content and "extraction". Many are not.
While I think the parent post leaves a lot of open ended questions, I think they are spot on about the tightness of design in games.
In many open world RPGs, or something like GTA, you cannot open every door in a city.
In street fighter you can't take a break to talk to your opponent.
In art games like Journey you cannot deviate from the path.
Games are a limited form of entertainment due to technical and resource restrictions, and they always will be. Even something as open ended and basic as minecraft has to have limits to the design, you wouldn't want the player to be able to collect every blade of grass off of a block just because you could add that. You have to find the balance between engaging elements and world building.
Having a LLM backed farmer in an RPG that could go into detail on how their crops didn't grow as well last season because it didn't rain as much seems good on paper for world building. But it is just going to devalue the human curated content around it as the player has to find what does and does not advance their goals in the limited time they have to play. And if you have some reward for talking to random NPCs players will just spam the next button until it's over to optimize their fun. All games have to hold back from adding more so that the important parts stand out.
One particular thing to be careful of are core dumps.
What I did at a previous shop was remove the passwords as part of a smart gdb script that runs when the core is dumped, before it gets written to a readable location.
Writing the script also helped to demonstrate how to extract the passwords in the first place.
<rant>The official Arrow C++ implementation is just ergonomic warts, full of `const std::shared_ptr<T>&` bs. Trying to use it to manipulate data always give me headache telling apart WTH is an Array, ArrayData, Buffer, and the typed Array interfaces are barely usable. The original official Rust port inherited all the mis-designs too. On the Rust side someone created arrow2 [0] to fix it.</rant>
None of them involve allocation or system calls after initialization. Queues are pre-allocated, as they should.
reply