3 ms·

They need to ship these in a better SKU. 2 P-core and 4 E-core just isn't that great in today's market. The lousy 4 CU iGPU is even worse. At a minimum, I'd li

by hajile 3y ago

They need to ship these in a better SKU. 2 P-core and 4 E-core just isn't that great in today's market. The lousy 4 CU iGPU is even worse. At a minimum, I'd like to see 4 P-cores and 4 E-cores plus 8 CU (preferably 16-24 CU).

wmf 3y ago
That's coming next year.
- hajile 3y ago
  Next year isn't great timing as they'll be going up against Qualcomm's new Oryon CPU which looks to be both powerful and tiny (165mm2 with 12 full-size cores).
  - onli 3y ago
    Will we have a working ARM Windows version next year? A translation layer in Windows and Linux to run x86 apps, like games? If not, and I think we won't, then the Qualcomm chip won't be a relevant alternative to the Ryzen processor.
    - pinkgolem 3y ago
      that translation layer on windows exists, its just has pretty shit perfomance last time i checked it out. https://learn.microsoft.com/de-de/windows/arm/apps-on-arm-x86-emulation https://learn.microsoft.com/de-de/windows/arm/apps-on-arm-x8... In linux you have a pretty good support for just recompiling everything as native arm binarys, atleast server side it works without any problems for me.
      - onli 3y ago
        I ran into problems with that on the server back then, but always only some edge cases - so that might work mostly now. But mentioning games was no accident - a slow translation layer won't cut it for them, and you can't recompile proprietary games. We have steam on Linux -> not supporting them is a non-starter. Worked for apple because they had no relevant gaming market share to begin with, and their translation layer actually worked well.
    - hajile 3y ago
      Native devs need to start always cross-compiling their apps for multiple ISAs from the start. Outside of a very tiny amount writing their own SIMD assembly, this isn't usually a huge deal. WASM is also finally becoming a decent solution to not just cross-ISA, but cross-platform too. It's not yet performant enough for everything, but even among native stuff, I'd guess it's good enough for most.
  - wmf 3y ago
    Strix Point sounds pretty close to Oryon.
undersuit 3y ago
https://buy.hpe.com/us/en/options/processors/amd-epyc-processors/amd-epyc-processors/amd-epyc-9754-2-25ghz-128-core-360w-processor-for-hpe/p/p60463-b21 https://buy.hpe.com/us/en/options/processors/amd-epyc-proces... Are the GPU cores that necessary?
- wmf 3y ago
  We're talking about laptop processors so yeah, the GPU matters. Most laptops don't have a discrete GPU so whatever GPU is included in the main SoC is what you get.
- hajile 3y ago
  It depends on what you're using your system for. I want something I can use as a light Steam Laptop in addition to other workloads.
makomk 3y ago
These aren't really E-cores like the ones Intel or ARM have though - they're microarchtecturally identical to a full Zen 4 core with all the execution units, L1+L2 cache, and out-of-order magic and in theory perform identically to one when running at the same clock speed. They just use less die area at the cost of a lower maximum clock. This is different from Intel's E-cores or ARM's little cores which are simpler and have worse clock for clock performance.
- spott 3y ago
  > use less die area at the cost of a lower maximum clock. This makes no sense to me. Lower die area means smaller feature sizes (ie a process size change) or fewer transistors (ie features change). I’m not sure how you have the same features in a smaller die area and (presumably) be at the same process node and “just” sacrifice clocks. Do you have a source for that? Or more information about how that is possible?
  - sudosysgen 3y ago
    It does have less L3, and maybe it's routed for longer critical paths, thereby allowing for denser packing?
  - wmf 3y ago
    Circuit design has some interesting nuances. For example, within a given process transistors are available in different sizes: low-Vt transistors are physically larger and faster while high-Vt are smaller but slower (and there are multiple in-between sizes). Using the same design but different transistors it's possible to trade off area and clock frequency, which is exactly what AMD has done in this case. There may also be thermal considerations; a dense high-frequency design could have unacceptable hot spots so they space it out a bit to spread the heat. At a lower frequency the hot spots would be less of a problem. I can also imagine that delivering high current to a small area could cause voltage droop in the power delivery network.

by hajile 3y ago

wmf 3y ago

That's coming next year.

hajile 3y ago
Next year isn't great timing as they'll be going up against Qualcomm's new Oryon CPU which looks to be both powerful and tiny (165mm2 with 12 full-size cores).
- onli 3y ago
  Will we have a working ARM Windows version next year? A translation layer in Windows and Linux to run x86 apps, like games? If not, and I think we won't, then the Qualcomm chip won't be a relevant alternative to the Ryzen processor.
  - pinkgolem 3y ago
    that translation layer on windows exists, its just has pretty shit perfomance last time i checked it out. https://learn.microsoft.com/de-de/windows/arm/apps-on-arm-x86-emulation https://learn.microsoft.com/de-de/windows/arm/apps-on-arm-x8... In linux you have a pretty good support for just recompiling everything as native arm binarys, atleast server side it works without any problems for me.
    - onli 3y ago
      I ran into problems with that on the server back then, but always only some edge cases - so that might work mostly now. But mentioning games was no accident - a slow translation layer won't cut it for them, and you can't recompile proprietary games. We have steam on Linux -> not supporting them is a non-starter. Worked for apple because they had no relevant gaming market share to begin with, and their translation layer actually worked well.
  - hajile 3y ago
    Native devs need to start always cross-compiling their apps for multiple ISAs from the start. Outside of a very tiny amount writing their own SIMD assembly, this isn't usually a huge deal. WASM is also finally becoming a decent solution to not just cross-ISA, but cross-platform too. It's not yet performant enough for everything, but even among native stuff, I'd guess it's good enough for most.
- wmf 3y ago
  Strix Point sounds pretty close to Oryon.

undersuit 3y ago

https://buy.hpe.com/us/en/options/processors/amd-epyc-processors/amd-epyc-processors/amd-epyc-9754-2-25ghz-128-core-360w-processor-for-hpe/p/p60463-b21 https://buy.hpe.com/us/en/options/processors/amd-epyc-proces... Are the GPU cores that necessary?

wmf 3y ago
We're talking about laptop processors so yeah, the GPU matters. Most laptops don't have a discrete GPU so whatever GPU is included in the main SoC is what you get.
hajile 3y ago
It depends on what you're using your system for. I want something I can use as a light Steam Laptop in addition to other workloads.

makomk 3y ago

These aren't really E-cores like the ones Intel or ARM have though - they're microarchtecturally identical to a full Zen 4 core with all the execution units, L1+L2 cache, and out-of-order magic and in theory perform identically to one when running at the same clock speed. They just use less die area at the cost of a lower maximum clock. This is different from Intel's E-cores or ARM's little cores which are simpler and have worse clock for clock performance.

spott 3y ago
> use less die area at the cost of a lower maximum clock. This makes no sense to me. Lower die area means smaller feature sizes (ie a process size change) or fewer transistors (ie features change). I’m not sure how you have the same features in a smaller die area and (presumably) be at the same process node and “just” sacrifice clocks. Do you have a source for that? Or more information about how that is possible?
- sudosysgen 3y ago
  It does have less L3, and maybe it's routed for longer critical paths, thereby allowing for denser packing?
- wmf 3y ago
  Circuit design has some interesting nuances. For example, within a given process transistors are available in different sizes: low-Vt transistors are physically larger and faster while high-Vt are smaller but slower (and there are multiple in-between sizes). Using the same design but different transistors it's possible to trade off area and clock frequency, which is exactly what AMD has done in this case. There may also be thermal considerations; a dense high-frequency design could have unacceptable hot spots so they space it out a bit to spread the heat. At a lower frequency the hot spots would be less of a problem. I can also imagine that delivering high current to a small area could cause voltage droop in the power delivery network.