4 ms·

400Mhz off a 5.4Ghz clock is a little less than a 10% drop. While it'd be a shame if the scheduler used the "wrong" core, if that's the kind of price for a mis

by emn13 4y ago

400Mhz off a 5.4Ghz clock is a little less than a 10% drop. While it'd be a shame if the scheduler used the "wrong" core, if that's the kind of price for a misjudgement, I don't expect it to be all that impactful in practice. IIRC published results from the 5800x3d also showed that quite a few workloads did have a small benefit from the larger l3 - not enough to make it worth it financially, but enough to roughly compensate for the lost frequency. The set of workloads where you'll see the full proportional slowdown due to the clockfrequency, with zero compensation from increased L3 is likely to be fairly small. All in all, this sounds more like a technically really interesting challenge, rather than a high-stakes bet. Even a "bad" scheduler probably won't do much harm. Realistic worst case, quite a few workloads that might have benefited from the new cache don't... but probably aren't hurt much either.

josephg 4y ago
Its interesting to note it will make benchmarking harder. Any benchmark could be 10% faster or slower based on which core your code is running on. On linux you can use 'taskset 0x1 ./bench' to force a process onto a specific mask of cores. Sounds like this sort of thing will be increasingly necessary if you want to compare code variants on these CPUs with precision.
- Moto7451 4y ago
  Good benchmarks are often concerned with core to core latency due to the physical topology of the cores. I imagine we’ll see some expansion into which core complex is in use for a given test and comparing both of them.
- zamadatix 4y ago
  If the change causes the scheduler to put it on the cache heavy cores but it turns out the program runs better on the clock heavy cores then this will cause your benchmark to report things are better than ever when the change really did make it perform worse. If pinning really is the best way to get the application to perform well and you want to implement that then the application or environment should be doing the pinning so the benchmark runner can report what's actually happening not what could happen. Regardless though if you want reliable numbers, even on a CPU with uniform cores, you should be doing multiple runs and comparing average and variance. This will always tell the actual story regardless how the platform underneath behaves that day.
- shaklee3 4y ago
  taskset -c to be pedantic

by emn13 4y ago

josephg 4y ago

Its interesting to note it will make benchmarking harder. Any benchmark could be 10% faster or slower based on which core your code is running on. On linux you can use 'taskset 0x1 ./bench' to force a process onto a specific mask of cores. Sounds like this sort of thing will be increasingly necessary if you want to compare code variants on these CPUs with precision.

Moto7451 4y ago
Good benchmarks are often concerned with core to core latency due to the physical topology of the cores. I imagine we’ll see some expansion into which core complex is in use for a given test and comparing both of them.
zamadatix 4y ago
If the change causes the scheduler to put it on the cache heavy cores but it turns out the program runs better on the clock heavy cores then this will cause your benchmark to report things are better than ever when the change really did make it perform worse. If pinning really is the best way to get the application to perform well and you want to implement that then the application or environment should be doing the pinning so the benchmark runner can report what's actually happening not what could happen. Regardless though if you want reliable numbers, even on a CPU with uniform cores, you should be doing multiple runs and comparing average and variance. This will always tell the actual story regardless how the platform underneath behaves that day.
shaklee3 4y ago
taskset -c to be pedantic