5 ms·

It's a trade-off between problems. Variable length instructions are not as trivial to decode wide, so you need more cleverness here. However, fixed length instr

• pclmulqdq 3y ago
  ARM used to find itself on the wrong side of this tradeoff in the era of 4-wide x86 decode units and 4-6 wide ARM decoders. They lost too much perf to cache size for the decoder width to make up for it. It's unclear to me if they will pull ahead on the perf/area game with the era of 8-wide x86 decoders coming.
• cesarb 3y ago
  > Note Zen4 has a 32 KB L1 instruction cache while the M1 has a 192 KB L1 instruction cache, requiring extra cleverness here instead to handle the higher latency and area. There's another factor here: to have a low latency, the L1 cache has to be indexed by the bits which don't change when translating from virtual addresses to physical addresses. That makes it harder to have a larger low-latency L1 cache when the native page size is 4KiB (AMD/Intel) instead of 16KiB (Apple M1/M2). That is, most of the "cleverness" allowing for a larger L1 instruction cache is simply a larger page size.
  • mjevans 3y ago
    If the instructions are on average 3-4x less dense (take about that much more space) than the trade-off in associativity granularity and corresponding increase in cache size are logical. The logical management circuits would be around the same size, though the number of memory cells and corresponding cost in silicon, power / thermal, and signal propagation / layout issues remain.
  • rep_lodsb 3y ago
    Since its instructions have to be aligned, ARM would also have only 12 usable address bits per page.
  • brigade 3y ago
    Pretty sure everyone uses a VIPT L1, what evidence is there that it's PIPT? (also what do you believe happens with 4k pages on M1, since it does support those, or why did the A7 have larger caches than Zen4 a decade ago, which was well before 16k pages)
• codedokode 3y ago
  x86 also uses 2-address instructions which means that you often need to use moves between registers (additional instructions), example: [1]. ARM uses 3-address instructions. Also, x86 code is compact, but not as compact as in era of 8080 [2] - here addition and multiplication require 3 bytes each, 6 bytes total. To my surprise, ARM has an add-multiply instruction and it uses just 4 bytes (instead of 8) [3]. And RISC-V uses 6 bytes because of shortened instruction for addition [4] Of course, this simple function cannot be a replacement for proper analysis, but it seems that x86 code is not significantly denser. Also to my great disappoitment none of those CPUs has checked overflow for arithmetic operation. [1] https://godbolt.org/z/jsoccE5jv https://godbolt.org/z/jsoccE5jv [2] https://godbolt.org/z/jTMs1MEzh https://godbolt.org/z/jTMs1MEzh [3] https://godbolt.org/z/nGb8qKcxe https://godbolt.org/z/nGb8qKcxe [4] https://godbolt.org/z/x9c115crY https://godbolt.org/z/x9c115crY
  • BeeOnRope 3y ago
    x86-64 is not even a particularly compact encoding even compared to contemporary fixed length encodings. The inherent advantage of variable length encoding is largely cancelled out by wasted encoding space for legacy cruft. Aarch64 is roughly on par for encoding density.
  • kazinator 3y ago
    It's incredible how large the code is when you compile some trivial piece of C with GCC for x86 or amd64, compared to one's memory of working with C on 386 boxes. What? I just wrote a simple main and a couple of small helper functions. How can we be past 20 kB of .text section?
    • throwaway2037 3y ago
      Can you share a sample with Godbolt? It might foster some good discussion here.
  • userbinator 3y ago
    Of course, this simple function cannot be a replacement for proper analysis, but it seems that x86 code is not significantly denser. Look at the demoscene for an example of dense x86 code, especially in the sub-1K categories. They routinely achieve code densities for x86 that no compilers I know of can get close to, and AFAIK I have not seen the same happen with ARM, nor MIPS or any other well-known RISC. 3-address instructions improve code density only in situations where both source operands are needed later.
• crest 3y ago
  The M1 uses 16kiB pages to reduce TLB pressure and get more non-aliasing cache tag bits.
  • sliken 3y ago
    Can use 16k pages. M1 also can use 4k pages.
• audunw 3y ago
  > However, fixed length instructions decrease code density, which asks more of the instruction cache. The problem is that x86 has a lot of legacy that wastes the potential gain of variable length encoding. If I remember correctly, the code density of 64-bit x86 isn't really significantly better than 64-bit ARM, despite ARM dropping support for Thumb. RISC-V is going to be interesting in that regard because with the latest revisions of the compressed instruction format, it can potentially beat both ARM and x86 on real-world code density, while still being easier to decode.
• nayuki 3y ago
  > Variable length instructions are not as trivial to decode wide, so you need more cleverness here. However, fixed length instructions decrease code density This is true in theory but I question how much it applies to current CPUs. A problem I see is that the x86 instruction set was designed in the 1970s with corresponding assumptions about instruction frequency, speed of memory, number of CPU cycles, pipelining (or lack thereof), addressing modes, etc. Even if the variable-length encoding was close to optimal back then, there's no way it's remotely optimal given all the extensions to the instruction set, the change from hand-coded assembly to compiler-generated code, and many more seismic shifts in the ISA. So I think x86's variable-length instructions now have all the downsides of complicated decoding as well as the downsides of suboptimal code density. But you also can't reshuffle all the instructions and addressing modes without breaking backward compatibility.