Comment by jffhn
15 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.
15 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.
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.