3 ms·
Yeah, but those two were two isolated issues in a decade. Now we're having a continuous stream of microarchitectural bugs that require more and more complicated
by giomasce 7y ago
Yeah, but those two were two isolated issues in a decade. Now we're having a continuous stream of microarchitectural bugs that require more and more complicated fixes in toolchain, kernel and microcode. I am an outsider, but the impression is that the thing is exploding.
- mschuster91 7y ago> I am an outsider, but the impression is that the thing is exploding. To be honest it's the entire architecture that's exploding. There's a reason why ARM has all but taken over the smartphone market (and it's not just power efficiency), the only thing keeping x86 alive is the massive demand for backwards compatibility. Good riddance to x86/x64 once someone makes an ARM core capable of current Ryzen performance and attaches a runtime binary translator to it.
- Crinus 7y ago> Good riddance to x86/x64 once someone makes an ARM core capable of current Ryzen performance and attaches a runtime binary translator to it. What you expect to happen: developers will target fastARM for new code and users will use the x86/x64 translator for existing/old code. What will really happen: outside of open source circles (where they do not need the translator anyway) developers will keep targeting x86/x64 for new code since their existing users will keep using their existing x86/x64 machines and anyone using the new fastARM machines will still be compatible thanks to the translator. This of course assumes that fastARM will be fast enough and the x86/x64 translator to provide better performance than a real x86/x64 machine. Otherwise users wont have much of an incentive to upgrade as all of their existing software will become slower. At least unless they are forced to (see Apple).