> I realize that small memory discipline is not something that serves a modern programmer well. Spending time on optimizing memory usage is often completely useless as a new version or new feature will invalidate the effort and the overall effect on the system, compared to other work the programmer could be doing, would not be cost effective
Memory consumption can be a primary issue for small embedded targets. Upgrading the hardware is often not an option or is actually more costly than development time, because development is a one-time cost, while adding RAM or flash is an extra production cost (so a per-unit cost).
Moreover, embedded software tends to be more stable feature-wise than desktop or server software: once it's done, you can expect that it won't be modified for a few years. From my experience, the smaller the system the more "carved in stone" it is.
Finally, it should be noticed than on "normal" systems, memory size is still important because of the many caches they feature.
L3 cache: (Up to) 8 MiB… with a latency (42ns) equivalent of 2½ branch mispredictions. You know, the things that Everyone Knows™ they should avoid with compiler hints like __builtin_expect.
RAM: As much as you want… at 246 cycles (61.5ns) latency.
Memory consumption can be a primary issue for small embedded targets. Upgrading the hardware is often not an option or is actually more costly than development time, because development is a one-time cost, while adding RAM or flash is an extra production cost (so a per-unit cost).
Moreover, embedded software tends to be more stable feature-wise than desktop or server software: once it's done, you can expect that it won't be modified for a few years. From my experience, the smaller the system the more "carved in stone" it is.
Finally, it should be noticed than on "normal" systems, memory size is still important because of the many caches they feature.