6 ms·
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.
by waynecochran 2y ago
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.
- dboreham 2y agoThey're only x86 for marketing purposes.
- waynecochran 2y agoSo I can't run DOS on them in real mode anymore?
- dagmx 2y agoTechnically, I think you can’t anymore? https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html 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
- morepork 2y agoWe 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
- ta988 2y agoA lot lot more than a factor 10 if you count microcontrollers.
- Squeeze2664 2y agoThere's also an ARM CPU inside modern x86 processors, little-known fact. Look up AMD's Secure Processor.
- samus 2y agoARM 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.
- madars 2y agoRunning 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-bug/ 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.
- Kon-Peki 2y ago> 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 https://dl.acm.org/doi/10.1145/3282307
- 29athrowaway 2y agoAnd then the punchline: computers have gigabytes of RAM, multiple cores with multiple GHz, yet they run slow.
- extesy 2y agoComputers run very fast, it's software that runs slow.
- guestbest 2y agoSoftware is fast. It’s the user that is slow
- knowitnone 2y agoUsers are very fast, it's the muscles that are slow
- PoppGolfer 2y ago[flagged]
- Sohcahtoa82 2y agoI'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.
- akira2501 2y agoInstruction 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.
- orlp 2y agoIs it? My compute-bound tight loops on x86-64 are often decode-bound.
- akira2501 2y agoHow 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?