Skip to content

Conversation

@k0kubun
Copy link
Member

@k0kubun k0kubun commented Aug 15, 2024

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%.

@k0kubun k0kubun requested a review from a team August 15, 2024 18:28
@maximecb maximecb merged commit ca6b1c6 into ruby:main Aug 15, 2024
@k0kubun k0kubun deleted the pin-p-cores branch August 15, 2024 20:03
@eregon
Copy link
Member

eregon commented Aug 15, 2024

Why not simply using the first core?

@k0kubun
Copy link
Member Author

k0kubun commented Aug 15, 2024

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.

@maximecb
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants