I work with another team at work that uses lots of message passing, C++ virtual methods in deeply nested class hierarchies, large DOMs and off-the-shelf C++ STL containers... on a STM32MP1, which has an in-order Cortex-A7 and a pittance of cache.
On the other hand, in my team I wrote my custom C++ STL containers that allocate inline, SAX-style processing libraries and an object pool with links that use index+generations like 2000s video games... on a STM32H5 with less than a megabyte of RAM.
Mechanical sympathy feels like a lost art to people I demonstrate it to... and I had to demonstrate to the first team with benchmark numbers that I would not be the bottleneck between us by orders of magnitudes.
I’ve had code review pushback against reorganizing data structures to be more cache-friendly on the grounds that it was “premature optimization” even though I pre-emotively justified the decision with benchmark results indicating that the performance difference was large and business relevant, and addressed a real performance bottleneck that I observed during testing.
This was on a team and at a time where Clean Code was very popular. I somewhat wonder if the problem is that, in the 2010s, many people became convinced that certain aesthetic standards were both objectively, provably correct, and more important than anything else.
There's not enough context for me (or other commenters) to really evaluate this, but every change has risk, and some projects aren't in a position to be accepting that risk.
A "real performance bottleneck that I observed during testing" is a little bit unclear whether it occurred outside of test conditions, or whether speeding up that particular bit improves anything anyone cares about.
That’s just pattern matching. Most people don’t do this level of prep so they assume you didn’t either. There’s usually no ill intent, and people are maybe a little embarrassed when you point it out, but t if you are tactful it’s fine.
If it has a pittance of cache, then mechanical sympathy might not mean cache-friendliness. Linked lists were mechanically sympathetic on uncached systems - it cost the same to access any byte of memory, so you might as well go directly to the one you wanted.
I thought up a RAM that paired every data word, with an address word, pointing to its "next" word. ListRAM.
Reduces usable RAM in half, but speed is speed.
The idea being the RAM buses could be designed to provide fast pipelines of chained data to the cache, despite arbitrarily scattering in RAM.
There is no way this could compete with a single batch read of actually adjacent data. But it could speed up "Random" accessed data, which often is not - in fact - actually random from the program's or the data structure's point of view, just not adjacent.
And it would do one thing better: Reading a null terminated string wouldn't over read. The null next-address would stop every small string read from becoming a page read.
Even more flexible, send little read-chain algorithms to RAM. A little address math chaining and branching on in-RAM values, on little distributed address-math cores (RAM embedded APU cores!), could avoid a lot slow turnarounds.
These kinds of ideas seem even better to me now, by orders of magnitude, than they did originally. RAM really needs help.
I work in the games industry with exceptionally skilled system programmers that can do that too. They're getting on in age, and there's fewer programmers in the younger generations that are interested in any of it. Technology is sadly increasingly homogenising around Unreal Engine 5
> Technology is sadly increasingly homogenising around Unreal Engine 5
I kinda get the commodification of games engines and Unreal. I am sure a lot of us saw the gaming revolution unfold, watching gaming companies one-up each other in graphics and interactivity. But once you get to the point of UE5, Unity, or Godot there is little need or value to make a game engine from scratch anymore.
Don't get me wrong, if you want to write an engine, go for it. But if you just want to make a game then an existing engine is good enough.
I’ll admit I lost the plot a long time ago, but there’s a part of me that wonders if the main purpose behind the game engine and graphics card treadmill is to line the pockets of people who sell games engines and graphics cards. My subjective sense of the connection between technology and enjoyment as a player started to degrade about a decade back.
I think it was just studios competing with each other in the 2010s to see who could make the biggest most ambitious game worlds. Leading to ballooning dev costs and then a feedback loop of higher production costs leading to safer design decisions.
There was also a heavy emphasis on games being "cinematic" which necessitates photorealistic rendering.
AAA games have been pretty artless for a while now baring a couple exceptions.
I'd it's more a convenient outcome of maximizing profits than premeditated. Not optimizing is cheaper for studios while Nvidia doesn't mind extra popularity for their DLSS feature.
Crysis 3 is over a decade old, still looks great and ran on hardware that wouldn't suffice for web browsing today. I haven't seen anything in games since then that justified a significant increase in system requirements.
The people working for Unreal/Unity/Godot. Nobody writes search engines any more - except for Google et al. Nobody writes advertising systems - except for all the advertising businesses.
Games are a bit different in that the game engine is a core part of the product. There aren't many projects with $100M budgets building directly on top of a search engine. A lot of small and medium sized companies will use off the shelf game engines, but you'll never see Rockstar switching over to Unity/Unreal.
I work with another team at work that uses lots of message passing, C++ virtual methods in deeply nested class hierarchies, large DOMs and off-the-shelf C++ STL containers... on a STM32MP1, which has an in-order Cortex-A7 and a pittance of cache.
On the other hand, in my team I wrote my custom C++ STL containers that allocate inline, SAX-style processing libraries and an object pool with links that use index+generations like 2000s video games... on a STM32H5 with less than a megabyte of RAM.
Mechanical sympathy feels like a lost art to people I demonstrate it to... and I had to demonstrate to the first team with benchmark numbers that I would not be the bottleneck between us by orders of magnitudes.
I’ve had code review pushback against reorganizing data structures to be more cache-friendly on the grounds that it was “premature optimization” even though I pre-emotively justified the decision with benchmark results indicating that the performance difference was large and business relevant, and addressed a real performance bottleneck that I observed during testing.
This was on a team and at a time where Clean Code was very popular. I somewhat wonder if the problem is that, in the 2010s, many people became convinced that certain aesthetic standards were both objectively, provably correct, and more important than anything else.
There's not enough context for me (or other commenters) to really evaluate this, but every change has risk, and some projects aren't in a position to be accepting that risk.
A "real performance bottleneck that I observed during testing" is a little bit unclear whether it occurred outside of test conditions, or whether speeding up that particular bit improves anything anyone cares about.
That’s just pattern matching. Most people don’t do this level of prep so they assume you didn’t either. There’s usually no ill intent, and people are maybe a little embarrassed when you point it out, but t if you are tactful it’s fine.
Before AI, nobody has been responsible for more psychic damage against software developers than Bob Martin.
If it has a pittance of cache, then mechanical sympathy might not mean cache-friendliness. Linked lists were mechanically sympathetic on uncached systems - it cost the same to access any byte of memory, so you might as well go directly to the one you wanted.
What is a cache friendly version of linked lists?
I thought up a RAM that paired every data word, with an address word, pointing to its "next" word. ListRAM.
Reduces usable RAM in half, but speed is speed.
The idea being the RAM buses could be designed to provide fast pipelines of chained data to the cache, despite arbitrarily scattering in RAM.
There is no way this could compete with a single batch read of actually adjacent data. But it could speed up "Random" accessed data, which often is not - in fact - actually random from the program's or the data structure's point of view, just not adjacent.
And it would do one thing better: Reading a null terminated string wouldn't over read. The null next-address would stop every small string read from becoming a page read.
Even more flexible, send little read-chain algorithms to RAM. A little address math chaining and branching on in-RAM values, on little distributed address-math cores (RAM embedded APU cores!), could avoid a lot slow turnarounds.
These kinds of ideas seem even better to me now, by orders of magnitude, than they did originally. RAM really needs help.
I work in the games industry with exceptionally skilled system programmers that can do that too. They're getting on in age, and there's fewer programmers in the younger generations that are interested in any of it. Technology is sadly increasingly homogenising around Unreal Engine 5
> Technology is sadly increasingly homogenising around Unreal Engine 5
I kinda get the commodification of games engines and Unreal. I am sure a lot of us saw the gaming revolution unfold, watching gaming companies one-up each other in graphics and interactivity. But once you get to the point of UE5, Unity, or Godot there is little need or value to make a game engine from scratch anymore.
Don't get me wrong, if you want to write an engine, go for it. But if you just want to make a game then an existing engine is good enough.
If everyone stops writing game engines then who is going to program unreal engine/unity/godot?
I’ll admit I lost the plot a long time ago, but there’s a part of me that wonders if the main purpose behind the game engine and graphics card treadmill is to line the pockets of people who sell games engines and graphics cards. My subjective sense of the connection between technology and enjoyment as a player started to degrade about a decade back.
I think it was just studios competing with each other in the 2010s to see who could make the biggest most ambitious game worlds. Leading to ballooning dev costs and then a feedback loop of higher production costs leading to safer design decisions.
There was also a heavy emphasis on games being "cinematic" which necessitates photorealistic rendering.
AAA games have been pretty artless for a while now baring a couple exceptions.
I'd it's more a convenient outcome of maximizing profits than premeditated. Not optimizing is cheaper for studios while Nvidia doesn't mind extra popularity for their DLSS feature.
Crysis 3 is over a decade old, still looks great and ran on hardware that wouldn't suffice for web browsing today. I haven't seen anything in games since then that justified a significant increase in system requirements.
The people working for Unreal/Unity/Godot. Nobody writes search engines any more - except for Google et al. Nobody writes advertising systems - except for all the advertising businesses.
Games are a bit different in that the game engine is a core part of the product. There aren't many projects with $100M budgets building directly on top of a search engine. A lot of small and medium sized companies will use off the shelf game engines, but you'll never see Rockstar switching over to Unity/Unreal.
https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
Has anyone rewritten this for 2026?