5 ms·

Do you people honestly believe we can have a real discussion about CPUs on HN? These posts are always hijacked into an Apple discussion (currently 21 comments o

Do you people honestly believe we can have a real discussion about CPUs on HN? These posts are always hijacked into an Apple discussion (currently 21 comments out of 23 are in the Apple thread) back to the topic: ARM and AMD CPUs have about the same L1 instruction cache size. But don't they have a very different instruction density, giving one a noticeable advantage over the other?

221qqwe 3y ago
> These posts are always hijacked into an Apple discussion Or occasionally by RISC-V "enthusiasts" who claim that none of it matters since ARM is dead and everybody is going to switch to RISC-V in the very near (but undetermined) future..
- imtringued 3y ago
  ARM is dead not because I am a RISCV enthusiast, but because ARM is a terrible company that is taking forever to enter the server market. Neoverse N2 chips should have been available years ago. Once Jim Keller releases his Ascalon server RISC-V CPUs that are competitive with Zen x86 server CPUs, there is basically no room for ARM servers left since ARM couldn't manage to get their feet into the server market soon enough. So many ARM server vendors canceled their CPU projects, to the point that the safest prediction you can make about any new ARM server CPU is that it will be canceled. The thing about ARM is that it is already dead in the server market.
  - lewisinc 3y ago
    Regardless of the merit of your points, why would you willingly walk into the caricature that was so obviously painted?
  - pjmlp 3y ago
    Amazon thinks otherwise.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
  - devnullbrain 3y ago
    ARM servers have a better history of mass production than server CPU startups have of making it to 5 years without being acquired. But then that's probably the goal.
- snvzz 3y ago
  >ARM is dead Not dead (yet). Just a legacy ISA. >everybody is going to switch to RISC-V RISC-V is inevitable.
  - 221qqwe 3y ago
    > RISC-V is inevitable. Exactly, I find this sort of fanaticism about an instruction set (of all things) so puzzling. Many of the comments which mention RISC-V have anything constructive to say or any meaningful arguments. All the fanboyism makes me feel a bit like I'm on reddit (or worse)...
    - snvzz 3y ago
      There's a bunch of such select phrases the use of which is suggested by the top of the organization[0]. I recognize the value of some level of coordination in marketing efforts, and as I'm no expert I just follow their recommendations, like "RISC-V is inevitable". 0. https://www.youtube.com/watch?v=r9DEM216748 https://www.youtube.com/watch?v=r9DEM216748
      - wwtrv 3y ago
        I never realized that it's actually RISC-five and not RISC-/v/.
mappu 3y ago
The uops are similar so if x86 has a density advantage, it will be paid back during micro-op expansion. Whether this is really a win or not depends on where your bottlenecks are,
- kramerger 3y ago
  Isn't L1 I$ at ISA level? There have been some attempts to cache microops instead but I don't think current CPUs do that.
  - Findecanor 3y ago
    You mean a µop cache of size approaching that of a L1 instruction cache? The A710 has a 1536-entry µop cache. That is 3/16 of the L1 cache (counting each instr as four bytes)
  - Tuna-Fish 3y ago
    A710 and Zen4 both have post-decode uop caches, up to 6750 ops/core in Zen4 and 1536 ops/core in A710. (Because the uop caches must fill lines aligned to real L1 cache, utilization cannot be perfect, and x86 has a somewhat harder time to achieve full utilization, while the uop cache on arm is easier to utilize because instructions are more regular, only "losing" slots when instructions are fused.)
bakugo 3y ago
> Do you people honestly believe we can have a real discussion about CPUs on HN? It's not just CPUs, feels like many discussions related to personal computing in general get hijacked into Apple discussions, likely because there's many people here desperate to rationalize their purchase of mediocre hardware at a 10x markup.
- FirmwareBurner 3y ago
  Agree that Apple fanboys hijacking all CPU threads are indeed annoying (along with the TSMC and ASML chip hipsters) and I wish moderators would handle this so we could enjoy on-topic discussion without the usual "my M1 is so good, every other non-M1 CPU is now pointless" spam, but I think it's also that people would like to have Apple's M1 level of performance and efficiency from other vendors of more open systems and not be conditioned of always buying into the Apple ecosystem for it, which we know isn't gonna happen, as nobody else is as vertically integrated and has the market share and profit margins of Apple to pull off a X86 to ARM transition for consumers like Apple did, nor is there any standardized ARM platform yet, like the trinational IBM PC clones were, where you can just plug in an extern GPU. The transition to ARM will happen first in the server/cloud space, but consumer will have to wait much longer for it to reach PCs, if it ever does, as X86 is also making progress.
  - qwytw 3y ago
    > X86 to ARM transition for consumers Apple did. > ARM will happen first in the server/cloud space, but consumer will have to wait much longer. It's not obvious to me that this is somehow inevitable. Yeah power efficiency wise Apple is ahead currently. But are there any reasons AMD/Intel why wouldn't be able to catch up and surpass Apple in a generation or two?
    - FirmwareBurner 3y ago
      Not while Apple is the main investor in TSMCs leading edge nodes, plus, X86 still has a lot of backwards compatibility cruft keeping it back. Eventually the gap will narrow as Apple already picked the lowest hanging fruits with the M1 design, and as we saw the jump to M2 was no longer as impressive, so we just have to wait.
Tuna-Fish 3y ago
> ARM and AMD CPUs have about the same L1 instruction cache size. But don't they have a very different instruction density, giving one a noticeable advantage over the other? Instruction cache sizes are not set by what you want, but by what you can get away with. The fetch path has both a lot of distance to travel and transistors to switch, and is typically a very critical path for clock speed, and while adding more pipeline stages for it helps with clocks, it also directly hurts performance near branches. So in the end you have to limit the size depending on what clocks you target and how many stages you are willing to give the fetch path.

221qqwe 3y ago

> These posts are always hijacked into an Apple discussion Or occasionally by RISC-V "enthusiasts" who claim that none of it matters since ARM is dead and everybody is going to switch to RISC-V in the very near (but undetermined) future..

imtringued 3y ago
ARM is dead not because I am a RISCV enthusiast, but because ARM is a terrible company that is taking forever to enter the server market. Neoverse N2 chips should have been available years ago. Once Jim Keller releases his Ascalon server RISC-V CPUs that are competitive with Zen x86 server CPUs, there is basically no room for ARM servers left since ARM couldn't manage to get their feet into the server market soon enough. So many ARM server vendors canceled their CPU projects, to the point that the safest prediction you can make about any new ARM server CPU is that it will be canceled. The thing about ARM is that it is already dead in the server market.
- lewisinc 3y ago
  Regardless of the merit of your points, why would you willingly walk into the caricature that was so obviously painted?
- pjmlp 3y ago
  Amazon thinks otherwise.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- devnullbrain 3y ago
  ARM servers have a better history of mass production than server CPU startups have of making it to 5 years without being acquired. But then that's probably the goal.
snvzz 3y ago
>ARM is dead Not dead (yet). Just a legacy ISA. >everybody is going to switch to RISC-V RISC-V is inevitable.
- 221qqwe 3y ago
  > RISC-V is inevitable. Exactly, I find this sort of fanaticism about an instruction set (of all things) so puzzling. Many of the comments which mention RISC-V have anything constructive to say or any meaningful arguments. All the fanboyism makes me feel a bit like I'm on reddit (or worse)...
  - snvzz 3y ago
    There's a bunch of such select phrases the use of which is suggested by the top of the organization[0]. I recognize the value of some level of coordination in marketing efforts, and as I'm no expert I just follow their recommendations, like "RISC-V is inevitable". 0. https://www.youtube.com/watch?v=r9DEM216748 https://www.youtube.com/watch?v=r9DEM216748
    - wwtrv 3y ago
      I never realized that it's actually RISC-five and not RISC-/v/.

mappu 3y ago

The uops are similar so if x86 has a density advantage, it will be paid back during micro-op expansion. Whether this is really a win or not depends on where your bottlenecks are,

kramerger 3y ago
Isn't L1 I$ at ISA level? There have been some attempts to cache microops instead but I don't think current CPUs do that.
- Findecanor 3y ago
  You mean a µop cache of size approaching that of a L1 instruction cache? The A710 has a 1536-entry µop cache. That is 3/16 of the L1 cache (counting each instr as four bytes)
- Tuna-Fish 3y ago
  A710 and Zen4 both have post-decode uop caches, up to 6750 ops/core in Zen4 and 1536 ops/core in A710. (Because the uop caches must fill lines aligned to real L1 cache, utilization cannot be perfect, and x86 has a somewhat harder time to achieve full utilization, while the uop cache on arm is easier to utilize because instructions are more regular, only "losing" slots when instructions are fused.)

bakugo 3y ago

> Do you people honestly believe we can have a real discussion about CPUs on HN? It's not just CPUs, feels like many discussions related to personal computing in general get hijacked into Apple discussions, likely because there's many people here desperate to rationalize their purchase of mediocre hardware at a 10x markup.

FirmwareBurner 3y ago
Agree that Apple fanboys hijacking all CPU threads are indeed annoying (along with the TSMC and ASML chip hipsters) and I wish moderators would handle this so we could enjoy on-topic discussion without the usual "my M1 is so good, every other non-M1 CPU is now pointless" spam, but I think it's also that people would like to have Apple's M1 level of performance and efficiency from other vendors of more open systems and not be conditioned of always buying into the Apple ecosystem for it, which we know isn't gonna happen, as nobody else is as vertically integrated and has the market share and profit margins of Apple to pull off a X86 to ARM transition for consumers like Apple did, nor is there any standardized ARM platform yet, like the trinational IBM PC clones were, where you can just plug in an extern GPU. The transition to ARM will happen first in the server/cloud space, but consumer will have to wait much longer for it to reach PCs, if it ever does, as X86 is also making progress.
- qwytw 3y ago
  > X86 to ARM transition for consumers Apple did. > ARM will happen first in the server/cloud space, but consumer will have to wait much longer. It's not obvious to me that this is somehow inevitable. Yeah power efficiency wise Apple is ahead currently. But are there any reasons AMD/Intel why wouldn't be able to catch up and surpass Apple in a generation or two?
  - FirmwareBurner 3y ago
    Not while Apple is the main investor in TSMCs leading edge nodes, plus, X86 still has a lot of backwards compatibility cruft keeping it back. Eventually the gap will narrow as Apple already picked the lowest hanging fruits with the M1 design, and as we saw the jump to M2 was no longer as impressive, so we just have to wait.

Tuna-Fish 3y ago

> ARM and AMD CPUs have about the same L1 instruction cache size. But don't they have a very different instruction density, giving one a noticeable advantage over the other? Instruction cache sizes are not set by what you want, but by what you can get away with. The fetch path has both a lot of distance to travel and transistors to switch, and is typically a very critical path for clock speed, and while adding more pipeline stages for it helps with clocks, it also directly hurts performance near branches. So in the end you have to limit the size depending on what clocks you target and how many stages you are willing to give the fetch path.