Hacker News Reader

Comment by waynecochran | Hacker News Reader

If you would have told me in the 1980's we would still be using x86 based chips in 2024 I would have laughed at you. I bet DOS runs really really fast on them.

View on HN

Running or virtualizing DOS-era software can be non-trivial: see, for example, Windows 98 vs TLB cache invalidation behavior in modern CPUs https://blog.stuffedcow.net/2015/08/win9x-tlb-invalidation-b... requiring a patch. Any code that does loop counting to estimate cycles for sleep() will also overflow (hello, Pascal CRT Error 200!) requiring a different patch.

> If you would have told me in the 1980's we would still be using x86 based chips in 2024 I would have laughed at you.

In the late 1970s, Gordon Moore believed that their next ISA would last the lifetime of the company. Now, technically, he thought their next ISA would be in the 8800. But it was such a drawn out failure they came up with the 8086 in an emergency 3-week sprint.

https://dl.acm.org/doi/10.1145/3282307

Instruction set wars were a 1970s concept anyways. The way x86 was built in the 80s vs. the way it's built today shows that it was a complete misnomer to begin with. It turns out instruction decoding really is the least important part of the pipeline.

Is it? My compute-bound tight loops on x86-64 are often decode-bound.

How tight are those loops really and how complex are your instructions? I'd suspect you're blowing out the cache and leaning on a single decoder due to the nature of the instructions. Particularly if these are SIMD instructions even if you sped up or paralleled the decoders you'd be up against later pipeline latencies very quickly anyways, at that point, are you actually measuring a real bound?

We did go from 16 to 32 and now to 64 bit, so there have been some significant changes in that time, plus all the new instructions added. But ARM chips are taking over, I think there are now more than 10 ARM chips for every x86 one sold

There's also an ARM CPU inside modern x86 processors, little-known fact. Look up AMD's Secure Processor.

ARM chips were widespread already long before they reached performance parity with x86, and actually already before the smartphone market took off.

There always have been vastly more chips of another architecture for every x86 chip. Most of the output of fabs with older processes are microcontrollers, most of which use some bespoke instruction set.

A lot lot more than a factor 10 if you count microcontrollers.

And then the punchline: computers have gigabytes of RAM, multiple cores with multiple GHz, yet they run slow.

Computers run very fast, it's software that runs slow.

I'd be curious to see how many clock cycles something as simple as "x = y + z" (Where all three variables are integers) takes in various languages.

The compiled languages would likely output a single MOV and ADD and get done in 2 cycles (plus any time to fetch from memory). Something like Python probably takes a couple hundred with all its type checking. JIT languages I would think would take a couple hundred the first time the line gets executed, but then have a single MOV and ADD ready the next time, unless I'm completely misunderstanding JIT.

Software is fast. It’s the user that is slow

Users are very fast, it's the muscles that are slow

They're only x86 for marketing purposes.

So I can't run DOS on them in real mode anymore?

Technically, I think you can’t anymore?

https://www.intel.com/content/www/us/en/developer/articles/t...

Intel dropped support for 16 bit booting with their firmware from a few years ago. And with x86S are looking to drop support all together and push people to virtualization

Reply on news.ycombinator.com