The need to use optimal patterns didn't go away, but the techniques certainly did. Just as a quick example, it's usually a bad idea now to use lookup tables to accelerate small math workloads. The lookup table creates memory pressure on the cache, which ends up degrading performance on modern systems. Back in the 1980s, lookup tables were by far the dominant technique because math was *slow.*

The way to approach this is to benchmark and then pick the best solution.

> Back in the 1980s, lookup tables were by far the dominant technique because math was slow.

This actually generalizes in a rather clean way: compared to the 1980s, you now want to cheaply compress data in memory and use succinct representations as much as practicable, since the extra compute involved in translating a more succinct representation into real data is practically free compared to even one extra cacheline fetch from RAM (which is now hundreds of cycles latency, and in parallel code often has surprisingly low throughput).

It’s a mad word where ultimate performance in one problem can require compressing data in ram and in another storing it uncompressed on disc.

The same atmosphere that makes bread hard makes crackers soft.

When was the last time you used mergesort because you had to?

Coincidentially, last night, and I'm not pulling your leg! But to be fair that's the first time in much more than a decade. I don't normally work with such huge files and this was one very rare exception. I also nearly crashed my machine by triggering the OOM killer after naively typing 'vi file' without first checking how large it had become. I'm working on a project that I probably should run on a more serious machine but I don't feel like moving my whole work environment from the laptop that I normally use.

It obviously never became completely irrelevant. But I think programmers spend a lot less time thinking about memory than they used to. People used to do a lot of gymnastics and crazy optimizations to fit stuff into memory. I do quite a bit of embedded programming and most of the time it seems easier for me to simply upgrade the MCU and spend 10cents more (or whatever) than to make any crazy optimimzations. But of course there are still cases where it makes sense.

While thinking less about memory optimizations is possible since we have more memory, it was enabled by the languages and libraries we use. Fourty years ago, you were probably implementing your own data structures. Sure, there were plenty of languages that offered them back then (LISP was based on linked lists, and that language is from the 1960's). Chances are you weren't using such languages unless you were using big computers or writing software that didn't handle much data. These days, pretty much any language will provide at least some data structures and their related algorithms. Even systems programming languages like C++ and Rust. Of course, there are an absurd number of libraries if you need anything more specialized.