Closed k0kubun closed 3 months ago
Why not simply using the first core?
I'm personally fine with that, but I thought we didn't do that with the assumption that OS would pick the first core for other tasks when every core is unused (which should be the case in a benchmarking environment) and the first core may have more noise than later cores in that case. If it's not really the case in reality, I guess it's fine to just pick the first core.
It seems very likely that some operating systems may default to the first core for either the OS itself or as a default core to assign tasks to.
imo we should either use the logic from this PR or give up on core pinning, but it did seem like core pinning did increase stability of the results in the past. I would default to sticking to this solution.
This PR changes
run_benchmarks.rb
to avoid pinning CPU to the last core.My CPU, Intel Core i7-12700KF, has 8 "P-Cores" and 4 "E-Cores", 12 in total. In the CPU core list, 8 (or 16 with HT) P-Cores are placed first and then 4 E-Cores follow. Therefore, the current
run_benchmarks.rb
uses an E-Core. E-Cores are much slower than P-Cores, so it makes benchmarking slow and stressful for me.To choose a P-Core, I changed the CPU core index from 100% of
nproc
to 50% of that. In my environment, this change speeds up Optcarrot by 70%.