4 ms·

Modern schedulers like Window's multilevel feedback queue and Linux's CFS (Completely Fair Scheduler) have advanced a lot in the last decade. It would be annoy

• formerly_proven 4y ago
  Unlike P/E cores you can't handle this generically, because the performance delta is workload-dependent. For E cores you can more or less just punt "background tasks" on them and pull tasks that are using a significant amount of CPU to the P cores. With X3D vs non-X3D cores which one is going to be faster depends on the workload. Most games benefit (sometimes drastically so), a lot of other stuff doesn't / is slower roughly in proportion to the clock reduction - just look at the 5800X and 5800X3D of the prior generation to see how split the benchmarks are; virtually every synthetic benchmark and most intensive things - compiling, encoding, running JS and other interpeters - suffer, games win. I suppose a good heuristic for desktop users would be to pin processes using the GPU to the X3D cores.
  • mlyle 4y ago
    I don't think it's quite as bad as you're saying, because reaching to the other chiplet for L3 isn't terrible in latency compared to hitting "close" L3. So probably the higher boost cores win overall in either case.
    • deagle50 4y ago
      This is a good point. If the cores in the non-stacked CCD miss in local L3, it's still quicker to ask the stacked CCD instead of going to RAM. But GP's question is valid, how do you prefer the non-stacked CCD for certain high-intensity tasks without hardcoding their names/IDs?
      • AndrewDavis 4y ago
        I'd love to see a benchmark with the 3d vcache ccd cores disabled and benched against the non 3d part it is based on with one ccd disabled. Would be interesting to see at comparable clocks what the performance uplift of hitting the huge cache more often on the other ccd vs hitting main memory.
        • wtallis 4y ago
          Can it actually hit the cache on the other chiplet? I thought that Zen's L3 caches were somewhat private to the local CCX/CCD, such that threads running on one chiplet have no way to cause new data to be prefetched or spilled in to someone else's L3.
          • deagle50 4y ago
            My assumption was the IO die had a directory of cache lines and would route a request to the other CCD if it were present there. You can't evict to a remote L3 but you can snoop it, I think.
            • mlyle 4y ago
              Yes, this is correct... Now, thinking about it... you can't evict to the distant L3, though. So, it really depends on the workload and whether the remote big L3 is "warmed" suitably for you.
              • deagle50 4y ago
                Yea... Bummer about the hybrid layout, voltage control will be disbled anyway to prevent killing the 3D die so I don't really care for high boost CCD. If it weren't for the EDC VID bug on Zen 3 taming PBO, I'd be running a manual OC to keep high load voltage and temps in check. Might as well have two tamed 3D CCDs.
      • usrusr 4y ago
        So one might look at the stacked cores as extravagant "L4" controllers serving their faster peers that might occasionally throw in some compute of their own for particularly parallel workloads? Seems rather wasteful, but perhaps it's actually less bad than the performance per watt tradeoffs at high clock rates.
  • dathinab 4y ago
    > faster depends on the workload. but also for most daily desktop workloads the difference is irrelevant tbh. games already should be pinned to one CCD for max performance compilation and similar will optimally spawn across both CCDs making it not matter (through you want to only split parallel computation units across CCDs but parallel code gen for the same unit should be on the same CCD) So I don't thinks it matters outside of artificial "challenges" to try to maximize performance beyond what is normally reasonable for a desktop system (due to work/time involved in doing so).