He failed to account for the "why" with previous architectures. 8-bit systems offer numbers from 0 to 255. In order to solve most realistic problems, you need

He failed to account for the "why" with previous architectures. 8-bit systems offer numbers from 0 to 255. In order to solve most realistic problems, you need 16 or 32-bit numbers. Working with a 32-bit number requires a half-dozen instructions to add two numbers and closer to 30+ instructions to multiply them and that's assuming no register pressure. If you only have a couple registers and an accumulator, you will have many more instruction moving data between registers and memory. 16-bit processors were an almost uniform upgrade here. You halve the number of raw math operations and the amount of MOVs decrease way more than that. 32-bit processors were a mild upgrade in comparison. If you needed 32-bit numbers, they were faster, but any time you could get away with 16-bit numbers, the other half of the ALU was just wasting power and die space. There was still a pretty large advantage to this change though. 64-bit processors have comparatively mild advantages. Unfortunately, increasing cache size (especially L1 cache) explodes the implementation complexity when you try to keep latency cycles down. Actually using a bunch of 64-bit numbers where 32-bit numbers would be sufficient halves the hit rate in cache. The actual gains from a fully 64-bit processor are consequently rather mild in most real-world applications. Most of the things people believe to be inherent advantages of 64-bit processors are actually x86 specific because it could double it's general purpose registers and ditch tons of legacy garbage when in 64-bit mode. The Pentium 4 for example could access 36-bits of memory despite being a 32-bit architecture. Meanwhile 64-bit x86 systems use 40-52 bits for their memory offsets rather than the full 64 and we're nowhere close to saturating that in any commonly-used system. 128-bit processors hit this wall hard. You can't use 128-bit numbers everywhere because the cache hit is too big (you could mitigate this by increasing addressable size from 8 bits to 16 or 32 bits, but that adds another set of problems). To get that full cache usage, you are still going to be using 32-bit integers wherever possible, but that means 3/4 of your pipeline goes to waste for most calculations. For the occasional times where 128-bit or bigint numbers are needed, it's better to have a 64-bit processor and dedicate that extra die area to other things than wider ALUs. There is a special case for very specific supercomputers running highly-detailed simulations requiring high-precision floating-point numbers, but even in those cases, I suspect a 64-bit system with a 128-bit floating-point co-processor is probably a good approach.