5 ms·

So the choices are: (1) Hardware designers need to do much more to speed up general memory accesses, so that a CPU cache is no longer needed. (2) Programmers

So the choices are: (1) Hardware designers need to do much more to speed up general memory accesses, so that a CPU cache is no longer needed. (2) Programmers need to accept that if they use pointers (either explicitly like in C, or implicitly like in Lisp or Java), they will have to tolerate the performance hit. (3) Programming is made much more difficult by requiring programmers to take into account memory layout, which is almost like a return to the bad old days when you had (by today's standards) tiny memories. (4) Memory is distributed over multiple CPUs, each working on a different part of the problem. There aren't many problems where users (who today, are almost everybody) care about raw speed. What they do care about are response times.

vvanders 11y ago
I'll add 5: Split application into logic(branches, special-case, and all the gnarly stuff that CPUs don't like) and data processing(nice structured data that fits well into memory). This is essentially what Sony did on the PS3, and made for a very fast system. They just did a poor job of messaging it ahead to devs who were familiar with n-core systems. That way you can speed up the things that need to be fast and the slow stuff doesn't interfere with it. We aren't going to see any fundamental shifts in memory tech so I think this is the best mitigating solution. Relational Databases already kinda nail the structured part to a degree, I think where we fall over is mixing logic with the data we want to process. There's also a continuum of prototyping -> high performance that gets missed in some of these discussions. If I want to see if something works I can knock out a quick prototype in JS but if I want to ship a performant, solid product I'm going to use Rust/C++/etc.