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.
That said, understanding how to design in tight memory constraints is useful. While typically only seriously practiced by embedded systems developers, having habits that minimize memory use can have a large impact at scale. The paper gives some good reasons on what the benefits of those habits are, but I also think that, as a percentage of the total, programmers living in constrained memory spaces are a specialization not the mainstream any more.
We're not living in constrained memory spaces on desktop but we sometimes are in the cloud.
In my experience 'small-batch distributed jobs' (~5 machines) are often candidates for memory optimization. Especially if written in high-level languages without easy access to struct packing.
I think we _are_ living in memory constrained spaces on the desktop. For some time now I have found the impetus for upgrading to a new computer has been to gain more RAM. More RAM usually requires changing RAM/DIMM type which necessitates new Motherboard and therefore new CPU. It has been that way since I had a 8 Meg machine.
It boggles me that a machine that could hold six hundred uncompressed 1080p video frames is my most memory constrained computer.
For what it's worth, I've had the opposite experience throughout my life. I've never actually upgraded to the physical/motherboard memory limits before I end up buying a new motherboard anyway when changing CPU sockets.
I agree. When I was at university, I bought a top-of-the-line Macbook. Not even a year later, I couldn't even run Eclipse and Firefox at the same time without swapping. Any time I needed to switch from Eclipse to Firefox or vice versa, I wound up waiting a noticeable length of time while the system was busy paging one out of RAM and the other in.
I remenber a video posted here showing experiments without traditional memory alignment (none instead of 4 ou 8). The code is faster and use less memory as long as the data can fit in the processor cache. It was on Intel CPU.
Actually also ARM has 64 byte cache lines. ARM also tends to be more more sensitive performance wise to proper alignment than x86, before ARMv6 you couldn't even do unaligned accesses except by emulating it in software.
So the results will probably be pretty similar on ARM as well.
> 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.
That said, understanding how to design in tight memory constraints is useful. While typically only seriously practiced by embedded systems developers, having habits that minimize memory use can have a large impact at scale. The paper gives some good reasons on what the benefits of those habits are, but I also think that, as a percentage of the total, programmers living in constrained memory spaces are a specialization not the mainstream any more.