[HN Gopher] Why x86 doesnt need to die
___________________________________________________________________
Why x86 doesnt need to die
Author : ylk1
Score : 41 points
Date : 2024-03-27 19:29 UTC (3 hours ago)
(HTM) web link (chipsandcheese.com)
(TXT) w3m dump (chipsandcheese.com)
| dmitrygr wrote:
| This misses on an important bit: parallel decoding of
| instructions. It is a lot harder with variable-length instrs
| where the length cannot even be calculated from the first byte -
| you need to read 10 bytes in the worst case to find an instr's
| len in x86. In aarch64 you need to read 0 bytes to know the
| length - it is 4
|
| This matters in the way it interacts with i-cache. In aarch64
| with 64-byte cache lines, one cache line is 16 instrs. always. In
| x86 that cache line could contain only 3 whole instrs. So unless
| your core is able to ingest over one icache line per cycle (intel
| cores currently are NOT), you are thus limited.
| account4mypc wrote:
| usually the really fat instructions take over 1 cycle anyway,
| right? so the decoder should be able to keep up
| dmitrygr wrote:
| pipelining...
|
| they are usually piplineable
| tester756 wrote:
| https://chipsandcheese.com/2021/07/13/arm-or-x86-isa-doesnt-...
|
| >Another oft-repeated truism is that x86 has a significant
| 'decode tax' handicap. ARM uses fixed length instructions,
| while x86's instructions vary in length. Because you have to
| determine the length of one instruction before knowing where
| the next begins, decoding x86 instructions in parallel is more
| difficult. This is a disadvantage for x86, yet it doesn't
| really matter for high performance CPUs because in Jim Keller's
| words:
|
| >For a while we thought variable-length instructions were
| really hard to decode. But we keep figuring out how to do that.
| ... So fixed-length instructions seem really nice when you're
| building little baby computers, but if you're building a really
| big computer, to predict or to figure out where all the
| instructions are, it isn't dominating the die. So it doesn't
| matter that much.
|
| >...
|
| >Researchers agree too. In 2016, a study supported by the
| Helsinki Institute of Physics[2] looked at Intel's Haswell
| microarchitecture. There, Hiriki et al. estimated that
| Haswell's decoder consumed 3-10% of package power. The study
| concluded that "the x86-64 instruction set is not a major
| hindrance in producing an energy-efficient processor
| architecture."
| dmitrygr wrote:
| I did not talk about power - i talked about perf. No modern
| x86 chip can decode 6 or 7 of these long instrs per cycle.
| there are aarch64 chips that can
| TazeTSchnitzel wrote:
| Perhaps it's compensated by the fact a single x86
| instruction does more? If a bunch of those aarch64
| instructions would be loads and stores, but for x86 they're
| part of the arithmetic instructions, then it maybe doesn't
| matter?
| The_Colonel wrote:
| What impact does it have on the overall performance though?
| Keller's argument is that the effect is small/negligible.
| AnimalMuppet wrote:
| Keller's argument (as stated) is that it doesn't take up
| much die space. Hiriki's argument is that it doesn't
| consume much power. Neither addresses dmitrygr's
| argument, which is about performance and bottlenecks. (It
| could use very little power and very little space and
| still be a very big bottleneck.)
|
| That doesn't mean that dmitrygr is correct. It means that
| everyone trying to answer him is arguing about the wrong
| thing.
| IshKebab wrote:
| The total architectural difference is pretty small in
| general. Like, say switching a chip from Intel to ARM
| lets you make it 30% faster. For the last several decades
| that _was_ insignificant. Not so much these days though.
|
| The decode difficulty may make a 5% difference, but add
| in the other things people have mentioned and maybe it
| adds up to 30%. (numbers pulled out of my arse)
| LegionMammal978 wrote:
| > So unless your core is able to ingest over one icache line
| per cycle (intel cores currently are NOT), you are thus
| limited.
|
| Do Intel cores no longer have a mop cache in front of the L1i
| cache?
| pif wrote:
| I think you are missing the only point of the article:
| performance and compatibility are important; everything else is
| just aesthetics.
|
| As long as Intel can produce fast CPUs, with new features and
| while maintaining support for the existing binaries, everything
| is OK. Fixed or variable length, that's a matter for Intel
| engineers: users could, and should, care less.
| JonChesterfield wrote:
| It's a nice theory but I don't think it holds up. X64 executes
| from a micro op cache and there's no particular reason to
| expect the ops in that to be variable length encoded. Thus it
| only goes to the i-cache when that misses, at which point
| you've spent long enough digging around in the cache that the
| extra decoding probably doesn't matter.
|
| It's of like saying x64 is limited by only having 16 registers
| - there's only names for 16ish in the ISA, but there's loads
| more registers in the machine as part of hiding latency.
| robotnikman wrote:
| > x86-64 CPUs keep real mode around so that operating systems can
| keep booting in the same way ... It's part of the PC
| compatibility ecosystem that gives x86 CPUs unmatched
| compatibility and longevity.
|
| This imo is one of the biggest advantages of x86 currently, at
| least as a hobbyist. In comparison to ARM based computers (like
| the raspberry pi for example) where the boot process is different
| for each device, and usually involves proprietary binaries which
| the user has no clue of how they work
|
| In comparison, you could re-use, update, and repurpose any old
| x86 machine to do whatever you need.
| the_panopticon wrote:
| https://www.intel.com/content/www/us/en/developer/articles/t...
| yjftsjthsd-h wrote:
| The really annoying thing is that we're _so_ close to doing
| better - openfirmware is decades old, and if we must throw that
| away UEFI is in fact portable; we _could_ have UEFI ARM
| machines with nice normal busses that the OS can enumerate and
| boot just like x86. But, y 'know, that would cost another 10
| cents a board so we get to live with the current trash. (I
| mean, this is even a thing that we _do_ use to boot VMs and
| Windows on ARM, and AIUI ex. https://libre.computer/ _does_ use
| UEFI firmware, the adoption is just super limited)
| JonChesterfield wrote:
| I don't think the instruction encoding is a significant problem.
| Cache coherency really might be.
|
| A current x64 chip is a dozen or so separate dies with eight or
| so x64 cores per die, with a couple of those in different
| sockets. When one thread on one code decides to write to a cache
| line, the memory model makes really strong guarantees about cores
| on some other socket noticing that change.
|
| Arm doesn't have to go with total store order. GPUs involve
| distinct blocks of memory with their own invariants on when
| caches are invalidated at potentially very coarse granularity
| (like no change will be seen until after a kernel has finished
| executing, where a kernel is essentially a process that sprung to
| life and then did arbitrary amounts of maths).
|
| Fast x64 code is prone to carefully partitioning the problem
| across different cores and trying not to hit a cache from another
| core but even then you still have something like MOESI sitting in
| the background waiting just in case some thread mutates the
| instructions executing on another one.
___________________________________________________________________
(page generated 2024-03-27 23:02 UTC)