Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-evaluate defaulting --jobs to number of CPU cores #487

Open
jimeh opened this issue Aug 11, 2024 · 0 comments
Open

Re-evaluate defaulting --jobs to number of CPU cores #487

jimeh opened this issue Aug 11, 2024 · 0 comments
Assignees
Labels
Milestone

Comments

@jimeh
Copy link

jimeh commented Aug 11, 2024

Description

Please correct me if I'm wrong, but my understanding from #93, is that if someone wants to make use of parallel builds, they should themselves specify a --jobs <N> flag to ruby-install.

Based on some of my own testing, and seeing as #93 is from 2013, maybe it's time to re-evaluate if a default -j value equal to number of CPU cores on the machine is reasonable to pass to make if no --jobs argument is provided at all to ruby-install?

Steps To Reproduce

I have been testing this on a MacBook Pro with a M3 Max (16 cores, 12P/4E), and the high number of cores offers much faster build times if they're fully utilized.

Below are the different commands I ran, and the time they took to complete:

  • ruby-install --install-dir "$(pwd)/ruby-install/3.3.4" ruby 3.3.4 — 3m 13s
  • ruby-install --install-dir "$(pwd)/ruby-install/3.3.4-jobs" --jobs ruby 3.3.4 — 2m 38s
  • ruby-install --install-dir "$(pwd)/ruby-install/3.3.4-jobs16" --jobs 16 ruby 3.3.4 — 1m 38s

My understanding is that if --jobs is given without a value, it should allow make to use an unlimited number of jobs, but that doesn't seem work as well as explicitly specifying the number of jobs to match the number of CPU cores.

For comparison, I also tried ruby-build, which does default to running make with -j 16 on my machine, which is made obvious by it printing the make command it's running. Below is the command I used and the time it took to complete:

  • ruby-build 3.3.4 "$(pwd)/ruby-build/3.3.4" — 1m 36s

Expected Behavior

I think it would be nice if ruby-install defaulted to taking full advantage of the the CPU cores on the machine, as it can cut the build time by as much as half on some hardware.

Actual Behavior

Builds take much longer than they need to on hardware with many CPU cores.

Environment

$ ruby-install --version
ruby-install: 0.9.3
$ uname -a
Darwin noct 23.6.0 Darwin Kernel Version 23.6.0: Fri Jul  5 17:56:15 PDT 2024; root:xnu-10063.141.1~2/RELEASE_ARM64_T6031 arm64
$ cc --version
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$ openssl version
OpenSSL 3.3.1 4 Jun 2024 (Library: OpenSSL 3.3.1 4 Jun 2024)
$ sysctl -a | grep -E 'machdep\.cpu|hw\.perflevel.+cpu'
hw.perflevel0.physicalcpu: 12
hw.perflevel0.physicalcpu_max: 12
hw.perflevel0.logicalcpu: 12
hw.perflevel0.logicalcpu_max: 12
hw.perflevel0.cpusperl2: 6
hw.perflevel1.physicalcpu: 4
hw.perflevel1.physicalcpu_max: 4
hw.perflevel1.logicalcpu: 4
hw.perflevel1.logicalcpu_max: 4
hw.perflevel1.cpusperl2: 4
machdep.cpu.cores_per_package: 16
machdep.cpu.core_count: 16
machdep.cpu.logical_per_package: 16
machdep.cpu.thread_count: 16
machdep.cpu.brand_string: Apple M3 Max
@jimeh jimeh added the bug label Aug 11, 2024
@postmodern postmodern self-assigned this Aug 11, 2024
@postmodern postmodern added feature and removed bug labels Aug 11, 2024
@postmodern postmodern added this to the 0.10.0 milestone Aug 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants