Comment by jffhn
19 hours ago
Also, the four fallacies of local computing:
- The CPU is infinitely fast.
- RAM is infinite.
- CPU caches don't exist.
- Cache lines don't exist.
19 hours ago
Also, the four fallacies of local computing:
- The CPU is infinitely fast.
- RAM is infinite.
- CPU caches don't exist.
- Cache lines don't exist.
- The computer is plugged to an infinite source of unlimited power
This was big before the mobile era and is true to this day to an extent. Many mainstream languages created in the 1990s (I call them "the children of the 1990s") were designed with this fallacy plus the ones you listed as a basis: JavaScript, Python, Ruby, Java, etc.
Java is basically the "greenest" managed language out there, so not sure putting it into the same list for energy efficiency is warranted. Though of course energy efficiency is fundamentally linked to memory usage, not destructing/collecting dead objects will increase memory usage but increase efficiency.
https://www.sciencedirect.com/science/article/pii/S016764232...
Reading your link IMHO in today's world I would set a basic rule, if you're touching >20% of a Java codebase you should refactor to Rust. With AI-Native development practices it's worth the SDE time to refactor, replace the underlying subsytem and reduce your fleet by 50% or more.
7 replies →
Indeed, the Java mobile platform had power consciousness baked in 25 or so years ago.
Was big before the AMD athlon. First commodity GHz processor was also the first to make obscene power demands.
Today even tiny CPUs are really fast. Locally you have to mess up badly to run into trouble. But of course people will do exactly that...
Most real world problems still can be solved with 32-bit software, so the last ~20 years running out of RAM always counted as "using defective hardware". AI workloads now make things interesting again, but it's not that easy to hit the ceiling with real world workload.
Cache is indeed very important. Optimisations like that are gone when you go for distributed computing. Sometimes adding a single nop can do wonders. I wonder how many percent of developers have something in their toolbox to profile for that.
I think there's a very different perspective on this between people old enough to have written assembly for 8 bit cpus like 6502 or Z80 often with well under 64kb of total system memory - compared to people who grew up in the age where the "starting coding" choices were something like "Angular or React?" and each browser tab could consume a GB or two of memory.
I'm not trying to say "greybeards are better" or "younger developers don't understand fundamentals" - it's more that the learned/ingrained abstractions those two types of developers start from are very very different. People who were familiar with concepts like the 6502's zero page where you get faster performance because you can use 8 bit addressing to access the first 256 _bytes_ of memory, end up with different mental tools and thinking than, say, people who started out their development learning about asynchronous callbacks and promises. One isn't better or worse than the other - but they are very very different.
(Even today's "tiny" CPUs are commonly 32 bit multi core SOCs. ESP32 kinda took over what used to be done with 8bit atmel Arduino class CPUs)
Arguably cache concerns are distributed computing concepts moving closer to the core. Same with concurrency semantics. These were far more exotic concepts when the fallacies were first written.
Very easy to hit the 3GB limit imposed by 32-bit architecture for any non trivial data processing app but luckily 64-bit is firmly established for at least 10 years
It's more niche but also underestimating the impact of using SIMD in places where it makes sense. Especially in higher level, interpreted programming languages where the overhead for each iteration is much larger than the few assembly instructions it would take to perform that iteration without vectorization in a low level language.
Disk never gets filled up.