> I originally missed your point about "multiples of"

That wasn't my point, but the claim of the poster I was replying to, and it was exactly this claim that I think is unsupportable.

Has some software gotten faster? Sure. But mostly software has a gotten slower and the rarer cases of software getting faster have been outpaced significantly by HW.

> You want examples where software has sped up at a rate faster than hardware

"several multiples":

that in some/many areas software has improved performance by several multiples of the improvement in hardware performance over the last 20 years

> [JavaScript] JIT compilers have improved

The original JITs were done in the late 80s early 90s. And their practical impact is far less then the claimed impact.

http://blog.metaobject.com/2015/10/jitterdammerung.html

As an example the Cog VM is a JIT for Squeak. They claim a 5x speedup in bytecodes/s. Nice. However the naive bytecode interpreter, in C, on commodity hardware in 1999 (Pentium/400) was 45 times faster than the one microcoded on a Xerox Dorado in 1984, which was a high-end, custom-built ECL machine costing many hundred thousands of dollars. (19m bytecodes/s vs. 400k bytecodes/s).

So 5x for software, at least 45x for hardware. And the hardware kept improving afterward, nowadays at least another 10x.

> [compilers] Parsing isn't as simple as it seems [..]

Parsing is not where the time goes.

> 2005-era swift running faster

Swift generally has not gotten faster at all. I refer you back to Proebsting's Law and the evidence gathered in the paper: optimizer (=software) improvements achieve in decades what hardware achieves/achieved in a year.

There are several researchers that say optimization has run out of steam.

https://cr.yp.to/talks/2015.04.16/slides-djb-20150416-a4.pdf

https://www.youtube.com/watch?v=r-TLSBdHe1A

(the difference between -O2 and -O3 is just noise)

> Big-O notation should speak for itself

It usually does not. Many if not most improvements in Big-O these days are purely theoretical findings that have no practical impact on the software people actually run. I remember when I was studying that "interior point methods" were making a big splash, because they were the first linear optimization algorithms that had polynomial complexity, whereas the Simplex algorithm is NP-hard. I don't know what the current state is, but at the time the reaction was a big shrug. Why? Although Simplex is NP-hard, it typically runs in linear or close to linear time and is thus much, much faster than the interior point methods.

Similar for recent findings of slightly improved multiplication algorithms. The n required for the asymptotic complexity to overcome the overheads is so large that the results are theoretical.

> FFT

The Wikipedia link you provided goes to algorithms from the 1960s and 1940s, so not sure how applicable that is to the question of "has software performance improvement in the last 20 years outpaced hardware improvement by multiples?".

Are you perchance answering a completely different question?

> [H264/H265] I'm talking specifically about SW implementations

Right, and the improvements in SW implementations don't begin to reach the improvement that comes from moving significant parts to dedicated hardware.

And yes, you have to modify the software to actually talk to the hardware, but you're not seriously trying to argue that this means this is a software improvement??