5 ms·

Not exactly. You can check the clock speeds: https://browser.geekbench.com/v5/cpu/4620493.gb5 https://browser.geekbench.com/v5/cpu/4620493.gb5 Up to 5050MHz i

Not exactly. You can check the clock speeds: https://browser.geekbench.com/v5/cpu/4620493.gb5 https://browser.geekbench.com/v5/cpu/4620493.gb5 Up to 5050MHz is stock behavior for the 5950X and it's using standard DDR4 3200 memory.

baybal2 6y ago
Yet it still makes it very clear: a properly implemented ARM core can easily bury an X86 of equivalent size because of inherent advantage of not having to pay interest on 40 years of technical debt in the ISA.
- throwaway2048 6y ago
  ISA has very little to do with it, ARM is almost as old as x86.
  - MrBuddyCasino 6y ago
    ARM went through multiple iterations of its ISA. They don’t need to run 40 year old code.
    - The_Colonel 6y ago
      X86 CPUs are not really "running" X86 ISA since Pentium Pro (1995), they are translating on-the-fly X86 instructions to microcode which is actually getting executed. ARM CPUs are also not executing ARM ISA directly and doing translation as well. Simpler ARM ISA has advantages in very small / energy efficient CPUs since the silicon translation logic can be smaller but this advantage grows increasingly irrelevant when you are scaling to bigger, faster cores. IMHO these days ISA implications on performance and efficiency are being overstated.
      - MrBuddyCasino 6y ago
        Yes, those are widely known fact. There are aspects of the ISA that do constrain performance and cannot be easily worked around, eg the memory model which is more relaxed on ARM.
      - baybal2 6y ago
        > IMHO these days ISA implications on performance and efficiency are being overstated. Noooo, besides simply copying instructions 1-to-1, the process is way to involved, and imposes 40 years old assumptions on memory model, and many other things, which greatly limits the amount of way you can interact with the CPU, adds to transistor count, and makes making efficient compilers really hard.
        tomxor 6y ago
        Interesting point. So on the one hand we have all these layers in the CPU to abstract away things in the ISA that are not ideal for block level implementation... but on the other hand compilers are still targeting that high level ISA... and ironically they also have their own more general abstraction, the intermediate representation. I'm probably not the first or last to suggest this but... it seems awfully tempting to say: why can't we throw away the concept of maintaining binary comparability yet and target some level of "internal" ISA directly (if intel/AMD could provide such an interface in parallel to the high level ISA)... with the accepted cost of knowing that ISA will change in not necessarily forward compatible ways between CPU revisions. From the user's perspective we'd either end up with more complex binary distribution, or needing to compile for your own CPU FOSS style when you want to escape the performance limitations of x86.
        MrBuddyCasino 6y ago
        I think IBM mainframes do something like this. Software is distributed as bytecode, and then compiled to machine code to CPU-specific assembly.
  - GreenHeuristics 6y ago
    AArch64/ARM64 was developed from the ground up, not bolted on to the old 32-bit ISA
- vbezhenar 6y ago
  Because 5 nm better than 7 nm. That's about it. AMD Zen will be on par with Apple Silicone when they'll use 5 nm process.
  - whizzter 6y ago
    Actually i'd bet that you're both wrong. What M1 does well isn't that "ARM-is-better" or that they're using a smaller process (even if both factors probably plays into helping the M1 chips edge a few %). Rather i suspect that the main benefit that M1 has in many real world benchmarks is that it has on-chip memory, cache-miss latency is a huge cost in the real world (why games has drifted towards DoD internals), so sidestepping that issue to a large extent by integrating memory on-die gives it a great boost. I'm betting once they've reverse engineered the M1 perf, we will see multi-GB caches on AMD/Intel chips within 4 years.
    - qayxc 6y ago
      There's nothing to "reverse engineer" there: M1 has 4x the L1 cache and a wider bus. That's it. This cannot be implemented in AMD's current 7nm process due to size restrictions. The SoC-side of the story is also contrary to the very core design of a general purpose CPU. RAM, GPU, and extension cards for specialised tasks are already covered by 3rd party products on the PCIe and USB4 buses and AMD has no interest in cannibalising their GPU and console business... With their upcoming discrete GPUs and accelerator cards, Intel might be in the same boat w.r.t. SoC design.
    - FrojoS 6y ago
      The M1 has an L1 cache with less than 0.5 KB per core and an L2 with about 4 MB shared by all cores. https://en.wikipedia.org/wiki/Apple_M1 https://en.wikipedia.org/wiki/Apple_M1
    - baybal2 6y ago
      > What M1 does well isn't that "ARM-is-better" Of course, not all to it, but denying that having to emulate a 40 years old ISA does not place a huge cost on transistor count, and efficiency is impossible.
- Fnoord 6y ago
  AMD64 (x86-64) runs x86-32 at near-native speed, but it isn't x86-32. As someone who was an early adopter of Linux/AMD64 I know first-hand backwards compatibility is very important. Apple knows, hence Rosetta. Every time they switch architecture, they invest into backwards compatibility. As a counter-example, Itanium wasn't good with backwards compatibility.
  - thrwyoilarticle 6y ago
    What was the Linux landscape like for AMD64 early adopters?
    - Fnoord 6y ago
      Debian was quick with adopting it (they've always been very cross-platform focused), in contrast to say Windows (which took a lot longer). On Linux, a lot worked, but not everything. Slowly but surely more got ported to AMD64. What didn't work? Especially pre-compiled proprietary software was not available (IIRC Nvidia drivers? At the very least games). You had to have x86-32 userland installed. Which adds up to higher diskspace requirement. Nowadays, diskspace requirement is negligible, and x86-32 userland is less relevant (on AMD64/x86-64). I would assume the 4 GB limit eventually made games swap to AMD64 as well. Back then, Intel was still betting on Itanium. It was a time when AMD was ahead of Intel. Wintel lasted longer, and its only since the smartphone revolution they got caught up. In hindsight, even a Windows computer on Intel gave a user more freedom than the locked down stuff on say iOS. OTOH, sometimes user freedom is a bad thing, arguably if the user isn't technically inclined or if you can sell a locked down platform like PlayStation or Xbox for relatively cheap (kind of like the printer business). I'm sure other people can add to this as well. :-)
      - thrwyoilarticle 6y ago
        Thanks
oysmal 6y ago
Even if the Ryzen wins out, that would still be comparing a desktop CPU to a mobile one, using 105W vs 10W. It is incredible that we are making these comparisons. Apple outdid themselves.
- The_Colonel 6y ago
  There's going to be a AMD mobile version of the 5000 generation soon and when looking back at 4000 generation their single core (boost) performance is going to be virtually the same as the desktop variant. Desktop CPUs differ from the mobile CPUs mainly in how much can they boost more/all cores.
  - lliamander 6y ago
    In my experience mobile cpus run at about 75%-90% the single-core performance of desktop counterparts. Zen 3 APUs will be close. Isn't the M1 fabbed on TSMC 5nm? Zen 3 is on 7nm. If a Zen 3 APU will run close to Apple Silicon I will be mightily impressed.
    - ernesth 6y ago
      So you mean Apple has this huge advantage of 5nm compared to 7nm but failed to outperform AMD? What a failure. (that was sarcasm. My take is this performance is impressive but you should not be surprised if it does not completely outperform CPUs that should be less efficient)
      - lliamander 6y ago
        > So you mean Apple has this huge advantage of 5nm compared to 7nm but failed to outperform AMD? I understand you are being sarcastic, but no, that's not what's not what I'm saying. It is Apple Silicon that is faster (at least on paper). I'm saying I think even though AMD will have worse perf/watt, I think it will get impressively close despite it's less efficient fabrication process.
    - The_Colonel 6y ago

baybal2 6y ago

Yet it still makes it very clear: a properly implemented ARM core can easily bury an X86 of equivalent size because of inherent advantage of not having to pay interest on 40 years of technical debt in the ISA.

throwaway2048 6y ago
ISA has very little to do with it, ARM is almost as old as x86.
- MrBuddyCasino 6y ago
  ARM went through multiple iterations of its ISA. They don’t need to run 40 year old code.
  - The_Colonel 6y ago
    X86 CPUs are not really "running" X86 ISA since Pentium Pro (1995), they are translating on-the-fly X86 instructions to microcode which is actually getting executed. ARM CPUs are also not executing ARM ISA directly and doing translation as well. Simpler ARM ISA has advantages in very small / energy efficient CPUs since the silicon translation logic can be smaller but this advantage grows increasingly irrelevant when you are scaling to bigger, faster cores. IMHO these days ISA implications on performance and efficiency are being overstated.
    - MrBuddyCasino 6y ago
      Yes, those are widely known fact. There are aspects of the ISA that do constrain performance and cannot be easily worked around, eg the memory model which is more relaxed on ARM.
    - baybal2 6y ago
      > IMHO these days ISA implications on performance and efficiency are being overstated. Noooo, besides simply copying instructions 1-to-1, the process is way to involved, and imposes 40 years old assumptions on memory model, and many other things, which greatly limits the amount of way you can interact with the CPU, adds to transistor count, and makes making efficient compilers really hard.
      - tomxor 6y ago
        Interesting point. So on the one hand we have all these layers in the CPU to abstract away things in the ISA that are not ideal for block level implementation... but on the other hand compilers are still targeting that high level ISA... and ironically they also have their own more general abstraction, the intermediate representation. I'm probably not the first or last to suggest this but... it seems awfully tempting to say: why can't we throw away the concept of maintaining binary comparability yet and target some level of "internal" ISA directly (if intel/AMD could provide such an interface in parallel to the high level ISA)... with the accepted cost of knowing that ISA will change in not necessarily forward compatible ways between CPU revisions. From the user's perspective we'd either end up with more complex binary distribution, or needing to compile for your own CPU FOSS style when you want to escape the performance limitations of x86.
        MrBuddyCasino 6y ago
        I think IBM mainframes do something like this. Software is distributed as bytecode, and then compiled to machine code to CPU-specific assembly.
- GreenHeuristics 6y ago
  AArch64/ARM64 was developed from the ground up, not bolted on to the old 32-bit ISA
vbezhenar 6y ago
Because 5 nm better than 7 nm. That's about it. AMD Zen will be on par with Apple Silicone when they'll use 5 nm process.
- whizzter 6y ago
  Actually i'd bet that you're both wrong. What M1 does well isn't that "ARM-is-better" or that they're using a smaller process (even if both factors probably plays into helping the M1 chips edge a few %). Rather i suspect that the main benefit that M1 has in many real world benchmarks is that it has on-chip memory, cache-miss latency is a huge cost in the real world (why games has drifted towards DoD internals), so sidestepping that issue to a large extent by integrating memory on-die gives it a great boost. I'm betting once they've reverse engineered the M1 perf, we will see multi-GB caches on AMD/Intel chips within 4 years.
  - qayxc 6y ago
    There's nothing to "reverse engineer" there: M1 has 4x the L1 cache and a wider bus. That's it. This cannot be implemented in AMD's current 7nm process due to size restrictions. The SoC-side of the story is also contrary to the very core design of a general purpose CPU. RAM, GPU, and extension cards for specialised tasks are already covered by 3rd party products on the PCIe and USB4 buses and AMD has no interest in cannibalising their GPU and console business... With their upcoming discrete GPUs and accelerator cards, Intel might be in the same boat w.r.t. SoC design.
  - FrojoS 6y ago
    The M1 has an L1 cache with less than 0.5 KB per core and an L2 with about 4 MB shared by all cores. https://en.wikipedia.org/wiki/Apple_M1 https://en.wikipedia.org/wiki/Apple_M1
  - baybal2 6y ago
    > What M1 does well isn't that "ARM-is-better" Of course, not all to it, but denying that having to emulate a 40 years old ISA does not place a huge cost on transistor count, and efficiency is impossible.
Fnoord 6y ago
AMD64 (x86-64) runs x86-32 at near-native speed, but it isn't x86-32. As someone who was an early adopter of Linux/AMD64 I know first-hand backwards compatibility is very important. Apple knows, hence Rosetta. Every time they switch architecture, they invest into backwards compatibility. As a counter-example, Itanium wasn't good with backwards compatibility.
- thrwyoilarticle 6y ago
  What was the Linux landscape like for AMD64 early adopters?
  - Fnoord 6y ago
    Debian was quick with adopting it (they've always been very cross-platform focused), in contrast to say Windows (which took a lot longer). On Linux, a lot worked, but not everything. Slowly but surely more got ported to AMD64. What didn't work? Especially pre-compiled proprietary software was not available (IIRC Nvidia drivers? At the very least games). You had to have x86-32 userland installed. Which adds up to higher diskspace requirement. Nowadays, diskspace requirement is negligible, and x86-32 userland is less relevant (on AMD64/x86-64). I would assume the 4 GB limit eventually made games swap to AMD64 as well. Back then, Intel was still betting on Itanium. It was a time when AMD was ahead of Intel. Wintel lasted longer, and its only since the smartphone revolution they got caught up. In hindsight, even a Windows computer on Intel gave a user more freedom than the locked down stuff on say iOS. OTOH, sometimes user freedom is a bad thing, arguably if the user isn't technically inclined or if you can sell a locked down platform like PlayStation or Xbox for relatively cheap (kind of like the printer business). I'm sure other people can add to this as well. :-)
    - thrwyoilarticle 6y ago
      Thanks

oysmal 6y ago

Even if the Ryzen wins out, that would still be comparing a desktop CPU to a mobile one, using 105W vs 10W. It is incredible that we are making these comparisons. Apple outdid themselves.

The_Colonel 6y ago
There's going to be a AMD mobile version of the 5000 generation soon and when looking back at 4000 generation their single core (boost) performance is going to be virtually the same as the desktop variant. Desktop CPUs differ from the mobile CPUs mainly in how much can they boost more/all cores.
- lliamander 6y ago
  In my experience mobile cpus run at about 75%-90% the single-core performance of desktop counterparts. Zen 3 APUs will be close. Isn't the M1 fabbed on TSMC 5nm? Zen 3 is on 7nm. If a Zen 3 APU will run close to Apple Silicon I will be mightily impressed.
  - ernesth 6y ago
    So you mean Apple has this huge advantage of 5nm compared to 7nm but failed to outperform AMD? What a failure. (that was sarcasm. My take is this performance is impressive but you should not be surprised if it does not completely outperform CPUs that should be less efficient)
    - lliamander 6y ago
      > So you mean Apple has this huge advantage of 5nm compared to 7nm but failed to outperform AMD? I understand you are being sarcastic, but no, that's not what's not what I'm saying. It is Apple Silicon that is faster (at least on paper). I'm saying I think even though AMD will have worse perf/watt, I think it will get impressively close despite it's less efficient fabrication process.
  - The_Colonel 6y ago