I just got done building a very similar page, and then accidentally found yours.

http://lightsecond.com/passphrase.html

My word list is 2845 long, it’s a selectively slimmed down copy of the Dale-Chall 3000 Simple Word List. I think my words are a bit more recognizable and easier to remember and spell. You’re welcome to use my copy if you’d like:

http://lightsecond.com/password_building_block_dict.txt

I also use push-buttons to select how many words you want, and I chose not to display words before you push a button so that your mind won’t be tainted by compelling words prior to seeing a phrase that you like.

Lemme know what you think?

But I think there are several reasons to focus on purely single-threaded processes only:

1. Complex software will become more and more constrained by Amdahl’s Law, and it’s useful to quantify to what extent we are, and will be, limited by this law.
2. It gives us a better idea how the CPU microarchitecture itself has evolved.
3. In a true single-threaded process, we know that the other cores are available to do work. You can launch N copies of the process and expect up to N times the throughput (assuming no shared bottlenecks). But when an application has been auto-parallelized, the same can no longer be said, so the comparison is not completely fair, in my opinion.

Seems like an argument can be made for leaving the autoparallelization influenced results uncorrected. These benchmarks have always tested CPU+compiler. If the compiler can eek more performance out of single threaded code by spreading it over multiple cores, why shouldn’t that count?

I’m curious what the trend line looked like bck into the early 90s. At just about the point your grap starts, Intel lost a significant part of the market for high-performance programmable digital logic to the 3D chip vendors. It is also about the time we started seeing SIMD instructions in mainstream CPUs. I wonder what impact those things had on investment in single threaded performance.