Re: Example M4 MAX and 7950X3D timing for building lang/rust in my context

On Mar 16, 2025, at 06:47, Søren Schmidt <[email protected]> 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
> [email protected] / [email protected]
> "So much code to hack, so little time"
> 
> 
>> On 16 Mar 2025, at 06.47, Mark Millard <[email protected]> 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