11 ms·

Where could I read more about this analysis? Genuinely interested to understand how x86_64 is such an albatross and more details about what could be accomplishe

by tux1968 7y ago

Where could I read more about this analysis? Genuinely interested to understand how x86_64 is such an albatross and more details about what could be accomplished in its absence.

kick 7y ago
Previous HN thread on (some of) the failures of x86 itself (it notes that most of this is not solved with x86_64): https://news.ycombinator.com/item?id=276418 https://news.ycombinator.com/item?id=276418 There's plenty of criticism of CISC in general, but that gets into flamewar status. A lot of modern abstraction, vulnerabilities and inefficiency can be summed up with "x86_64 sucks to write for, so let's build a new (or recreate an old) abstract machine!" In its quest to maintain fifty years of (near) compatibility with an architecture originally used in a calculator, the industry created a monster. There's a reason Apple (and Sun and MIPS before it) was able to get competitive with Intel's chips despite only getting a silicon team like half a decade ago and using an architecture generally seen as low-performance: they ruthlessly removed cruft, cutting ties with backwards compatibility in the process. Backwards compatibility is a scourge unto innovation and ease of use, as even Intel saw (IA64, for all of its faults, was better than x86_64 in virtually every way). I have a lot more criticism of x86_64, and can get a lot more technical in that criticism, but this comment is already getting a bit on the heavy side.
- sharpneli 7y ago
  IA64 had a glaring fault that trumps all of it’s advantages. It was explicitly a vliw design, so the user had to, or compiler, manually set multiple different kind of ops per single instructions. Modern superscalar OoO is pretty much like that, except there is a piece of hardware internally that does it, almost like a hardware jitter. This freedom both means the magical compiler doesn’t have to exist but also it allows processors to have varying amount of execution units. See that you could actually use one more int alu? Just add it and even older software is able to automatically get the benefit.
- nl 7y ago
  Ironically the link you posted supports the opposite view: that x86_64 is ugly but that isn't really an issue. Quote: in summary: x86 is ugly (and below is why I think so) but we don't care because compilers enable us to just forget about what ISA we're using. This is a good thing. This is the way it should be. But it's also an example of what the OP was talking about -- bad hardware design (in this case the x86 ISA; the actual hardware is quite good) not mattering because software is sufficiently good

Where could I read more about this analysis? Genuinely interested to understand how x86_64 is such an albatross and more details about what could be accomplished in its absence.

kick 7y ago

Previous HN thread on (some of) the failures of x86 itself (it notes that most of this is not solved with x86_64): https://news.ycombinator.com/item?id=276418 https://news.ycombinator.com/item?id=276418 There's plenty of criticism of CISC in general, but that gets into flamewar status. A lot of modern abstraction, vulnerabilities and inefficiency can be summed up with "x86_64 sucks to write for, so let's build a new (or recreate an old) abstract machine!" In its quest to maintain fifty years of (near) compatibility with an architecture originally used in a calculator, the industry created a monster. There's a reason Apple (and Sun and MIPS before it) was able to get competitive with Intel's chips despite only getting a silicon team like half a decade ago and using an architecture generally seen as low-performance: they ruthlessly removed cruft, cutting ties with backwards compatibility in the process. Backwards compatibility is a scourge unto innovation and ease of use, as even Intel saw (IA64, for all of its faults, was better than x86_64 in virtually every way). I have a lot more criticism of x86_64, and can get a lot more technical in that criticism, but this comment is already getting a bit on the heavy side.

sharpneli 7y ago
IA64 had a glaring fault that trumps all of it’s advantages. It was explicitly a vliw design, so the user had to, or compiler, manually set multiple different kind of ops per single instructions. Modern superscalar OoO is pretty much like that, except there is a piece of hardware internally that does it, almost like a hardware jitter. This freedom both means the magical compiler doesn’t have to exist but also it allows processors to have varying amount of execution units. See that you could actually use one more int alu? Just add it and even older software is able to automatically get the benefit.
nl 7y ago
Ironically the link you posted supports the opposite view: that x86_64 is ugly but that isn't really an issue. Quote: in summary: x86 is ugly (and below is why I think so) but we don't care because compilers enable us to just forget about what ISA we're using. This is a good thing. This is the way it should be. But it's also an example of what the OP was talking about -- bad hardware design (in this case the x86 ISA; the actual hardware is quite good) not mattering because software is sufficiently good