Re: Example M4 MAX and 7950X3D timing for building lang/rust in my context
- In reply to: Søren_Schmidt : "Re: Example M4 MAX and 7950X3D timing for building lang/rust in my context"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 16 Mar 2025 16:35:18 UTC
On Mar 16, 2025, at 06:47, Søren Schmidt <soren.schmidt@gmail.com> wrote: > Hi, > > Just thought I’d see what my lovely little MacMini M4pro/48G/512G could do… > > Blank machine stable-14/60Gdisk/10CPUs/16Gmem using UTM as virtualization. > Note: Only 10 out of 12 cores, disk is on TB4 connected NVMe disk mounted on macOS and seen as virtio block device. I am unusual in wanting to use media that I also use to directly boot the Windows DevKit 2023 and RPi5, moving the media between the systems/contexts. > Grabbed ports tree, and watched it download and compile 50+ (yes fifty) other packages before getting to rust. Hmm. My from-scratch build sequence that first tested a Makefile change built 43 other packages before starting the lang/rust build. The first package built was pkg, of course. (Note: This build failed in lang/rust's stage step because of the Makefile change that I was testing.) [00:00:11] Building 44 packages using up to 14 builders [00:00:11] Hit CTRL+t at any time to see build progress and stats [00:00:11] [01] [00:00:00] Builder starting [00:00:12] [01] [00:00:01] Builder started [00:00:12] [01] [00:00:00] Building ports-mgmt/pkg | pkg-2.0.6 [00:00:35] [01] [00:00:23] Finished ports-mgmt/pkg | pkg-2.0.6: Success . . . [00:05:38] [01] [00:00:11] Finished ftp/curl | curl-8.12.1: Success [00:05:38] [01] [00:00:00] Building lang/rust | rust-1.85.0_1 (The Makefile change lead to failure in stage, so I've not shown the Finished.) That 44 was true of both the M4 MAX and the 7950X3D. > Kernel needs COMPAT_FREEBSD11 ?? Why on earth ?? Rust is tied to an older ABI as I understand. The ABI binding is not changed often. (I've not looked at the detail of what is used from back then.) FreeBSD 12 had the change to having 64-bit inodes. There is or was also use of un-versioned symbols in how rust's libc use was handled, if I understand right. Rust's own build environment for their FreeBSD activity has to be tracking based on the needed versions. I've no clue what those builder machines are based on now. > Make clean in /usr/ports/lang/rust… > > Time make … > > Wait for it to complete > > 987.07 real 8115.10 user 307.51 sys > > That would be 16:27:07 … 16 min, 27 sec and a fraction. (I read that as 16 hours at first.) Using -v as well so that poudriere(-devel) reports the time progression at the start of each step of its sequence for building (and on Success/Failure): [00:00:12] [01] [00:00:00] Building lang/rust | rust-1.85.0_1 [00:00:12] [01] [00:00:00] Allowing MAKE_JOBS for lang/rust | rust-1.85.0_1 [00:00:12] [01] [00:00:00] Status lang/rust | rust-1.85.0_1: check-sanity [00:00:12] [01] [00:00:00] Status lang/rust | rust-1.85.0_1: pkg-depends [00:00:13] [01] [00:00:01] Status lang/rust | rust-1.85.0_1: fetch-depends [00:00:13] [01] [00:00:01] Status lang/rust | rust-1.85.0_1: fetch [00:00:15] [01] [00:00:03] Status lang/rust | rust-1.85.0_1: checksum [00:00:15] [01] [00:00:03] Status lang/rust | rust-1.85.0_1: extract-depends [00:00:15] [01] [00:00:03] Status lang/rust | rust-1.85.0_1: extract [00:00:45] [01] [00:00:33] Status lang/rust | rust-1.85.0_1: patch-depends [00:00:45] [01] [00:00:33] Status lang/rust | rust-1.85.0_1: patch [00:00:45] [01] [00:00:33] Status lang/rust | rust-1.85.0_1: build-depends [00:00:47] [01] [00:00:35] Status lang/rust | rust-1.85.0_1: lib-depends [00:00:47] [01] [00:00:35] Status lang/rust | rust-1.85.0_1: configure [00:00:49] [01] [00:00:37] Status lang/rust | rust-1.85.0_1: build [00:17:41] [01] [00:17:29] Status lang/rust | rust-1.85.0_1: run-depends [00:17:41] [01] [00:17:29] Status lang/rust | rust-1.85.0_1: stage [00:18:22] [01] [00:18:10] Status lang/rust | rust-1.85.0_1: package [00:22:45] [01] [00:22:33] Finished lang/rust | rust-1.85.0_1: Success The sizable contributors were: extract -> patch-depends start (~ 30 sec) build -> run-depends start (~1012 sec) stage -> package start (~ 41 sec) package -> Success (~ 263 sec) (I've no use of ccache or the like, by the way.) Sounds like what you did would omit the package -> Success activity? > (Using 12 cores wins about 30secs, experience shows that leaving 1-2 (efficiency) cores for macOS / UTM is the seed spot) > It shouldn’t be faster that your M4max … Either your disk I/O is heavily hampered or Parallels is just performing badly. For more detailed comparison/contrast, see the above. > Form what I’l tried on VMware, VirtualBox and UTM, UTM is by far the best performing virtualization om Apple silicon. > PS: just got reminded why I don’t use ports, you still get the pony, its entire family and a kitchen sink for no good reason :) With poudriere and pkg you build the pony, family, and kitchen sink. You need not install all of that to your live system, however. > Søren Schmidt > sos@deepcore.dk / sos@freebsd.org > "So much code to hack, so little time" > > >> On 16 Mar 2025, at 06.47, Mark Millard <marklmi@yahoo.com> wrote: >> >> Overall result: >> >> About the same build time for M4 MAX and the 7950X3D, >> each targeting its own kind of context rather than the >> same kind of context. This is despite the difference in >> the number of FreeBSD "cpus" involved. M4 MAX then >> 7950X3D: >> >> [00:22:12] [02] [00:22:07] Finished lang/rust | rust-1.85.0_1: Success >> [00:21:48] [21] [00:21:43] Finished lang/rust | rust-1.85.0_1: Success >> >> >> More detail needed to well interpret the above. . . >> >> >> My normal aarch64 environment is unusual, in that the >> configuration that I normally use targets cortex-a76 >> explicitly in the kernel that I normally boot, the >> aarch64 poudriere jail worlds, and the ports being >> built. That contributes to the below comparison. I've >> not done such tailoring to the 7950X3D type of amd64 >> context. So a possibly "unfair" context variation in >> that respect. (Not that cortex-a76 targeting always >> makes things take less time: it does not.) >> >> (I'll note that cortex-a76 targeting leads to >> compatibility with each of: M4 MAX, Windows DevKit >> 2023, and RPi5B. The same boot media, using the same >> kernel and such, works on all 3.) >> >> >> A 14 virtual core FreeBSD in Parallels in a macOS >> context with a M4 MAX (so: 14 FreeBSD aarch64 "cpus" >> --of 16 cores in the M4 MAX): >> >> [00:22:12] [02] [00:22:07] Finished lang/rust | rust-1.85.0_1: Success >> >> Maximum observed for each of the 3 load averages: 14.92, 11.28, 7.03 >> (My personal adjustment to top tracks that.) No active use of swap space. >> >> NOTE: Parallels is using USB 3.2 Gen 2 to a U2 adapter that >> has an Optane attached that has the FreeBSD. The same >> hardware is used to boot and to operate the Microsoft >> DevKit 2023 and the RPi5B. The macOS file system/media >> does not have any of the FreeBSD materials in it. >> >> >> A 7950X3D (16 SMT cores, so 32 FreeBSD amd64 "cpus"): >> >> [00:21:48] [21] [00:21:43] Finished lang/rust | rust-1.85.0_1: Success >> >> Maximum observed for each of the 3 load averages: 32.81, 25.21, 15.31 >> (My personal adjustment to top tracks that.) No active use of swap space. >> >> NOTE: PCIe Optane media. >> >> >> Overall notes: >> >> Note: The prerequisite packages had been built previously. >> No other builds or such competed significantly for >> resources. rust was listed in TMPFS_BLACKLIST . >> >> Note: Same system source version and ports source version >> are what things are based on. >> >> Note: macOS did not compress any memory. I had configured >> Parallels to provide 64 GiBytes of RAM to FreeBSD, >> of the 128 GiBytes in the M4 MAX in use. macOS seems >> to start compression when RAM use gets to something >> like 100 GiBytes overall for the macOS context. >> macOS got up to something like 89 GiBytes of RAM in >> use. (I've software that monitors such under macOS.) >> >> >> Side notes: >> >> The cortex-a76 code based Microsoft DevKit 2023 context >> builds lang/rust in a few minutes over 2hrs. >> >> Avoiding having FreeBSD push the use of its paging hard >> seems to be important to avoiding OOM kills in an under- >> Parallels usage context. (This is via other, earlier >> experiments.) > === Mark Millard marklmi at yahoo.com