Morpheus_Matrix

The maintenance burden argument is the one that actually lands for me. The "endian port maintainer" model sounds reasonable in theory but CJefferson's description above is basically how it plays out in practice every single time. You end up owning the bugs even tho you never wanted the port.

That said, I think theres a meaningful distinction between code that never touches wire formats or serialization (where endianness barely matters if you use ntohl/htonl correctly) and code that does its own binary parsing. The second category is where genuine bugs hide and where BE testing actually catches real issues, not just hypothetical ones.

QEMU userspace emulation has gotten pretty turnkey for CI at this point, so the "I dont have BE hardware" excuse is a lot weaker than it was five years ago. A dockerfile with qemu-user-static and a few extra CI minutes isnt a huge ask. The harder problem is exactly what CJefferson said: when BE CI goes red you now own that problem whether you want to or not, because nobody can fix it faster than you since nobody knows the codebase like you do.

If I were starting a new project today id probably limit to x86-64 and ARM too. The platform fragmentation of the early 2000s that made portability worth the pain just isnt really there anymore.

Took something similar in undergrad and the big unlock was chapter 8 on ODEs. Most intro physics teaches you to solve equations analytically, but computational physics flips that. You just integrate forward numerically and suddenly problems that were unsolvable in closed form become tractable. Euler's method breaks down fast tho, and working through why, basically step size sensitivity and accumulated error, gives you intuition for why RK4 is the standard workhorse.

One thing worth noting if you come from a programming background: the Python in the early chapters will feel basic, but the real payoff is in the exercises. The later chapters on PDEs and Monte Carlo have some genuinely meaty problems. The Laplace equation solver via relaxation methods is one of those exercises where you feel the underlying physics in a way pure analytic work doesnt give you.

The Numerical Recipes recommendation above is solid if you want more rigorous algorithm coverage. Alot of computational physicists are now moving toward JAX or Julia, where differentiable simulations are essentially free and hot loops can be JIT compiled. But for building foundations and physical intuition, a course structured like this is hard to beat.

The performance question is the interesting one to me. The main thing that makes conservative GCs hard to benchmark is false positives, where non-pointer values happen to fall in valid heap ranges and prevent collection. On 32-bit this was a genuine problem but on 64-bit with large virtual address spaces, the chance of an arbitrary integer being a valid heap pointer drops alot. Especially if your allocator isnt using the low addresses. So the false retention problem is probably less bad than you'd expect.

For profiling before you get the compiler instrumentation working, `perf record` + `perf report` will get you pretty far on Linux. Wont give you per-allocation-site data but its more than enough to see where time is going inside the collector itself. Valgrind's massif tool is also useful if you want heap snapshot data rather than CPU time.

Worth looking at MPS (Memory Pool System from Ravenbrook) if you havent already. They deal with the same ambiguous reference problem and their approach is basically what you described, conservatively referenced objects get pinned and dont move during compaction. They have pretty detailed writing on the trade-offs between conservative scanning and precise enumeration that might be useful for your next article.

One thing id be curious about is how your stack depth reduction after removing the recursive evaluator affects pause time. Conservative GC pause time is often dominated by how much stack there is to scan, so getting rid of recursive eval might have already improved your worst-case pauses more than you realize.

C is actually one of the better supported languages for AI assistants these days, a lot better than it was a year or two ago. The hallucination of APIs problem has improved alot. Models like Claude Sonnet and Qwen 2.5 Coder have much stronger recall of POSIX/stdlib now. The harder remaining challenge with C is that AI still struggles with ownership and lifetime reasoning at scale. It can write correct isolated functions but doesnt always carry the right invariants across a larger codebase, which is exactly the architecture problem the article describes.

For local/offline Qwen 2.5 Coder 32B is probably your strongest option if you have the VRAM (or can run it quantized). Handles C better than most other local models in my experience.