On 5/30/26 15:58, Bugs Beastie wrote: > May 31, 2026 00:14:52 void <[email protected]>: > >> On Sat, May 30, 2026 at 05:26:37PM +0200, Bugs Beastie wrote: >> >>> Just finished one build: >>> [4D:08:25:51] [01] [21:03:31] Finished devel/electron39 | >>> electron39-39.8.10_1: Success >>> 21 hours for electron39, this is on 4x3.3GHz core i5! >>> [electron41 failed in a strange way in fetch/checksum phase, no data for it >>> now] >> >> [07:51:54] [01] [06:04:22] Finished devel/electron41 | electron41-41.7.1: >> Success >> > Well, scales very well up to now! > > Probably this is the most reasonable direct way to go, to introduce "desktop > builder(s)"! It will get all "small" packages already built from regular > builders. It will crunch heavy desktop ports with only single poudriere > builder, but with all available cores given to MAKE_JOBS!
A small, even trivial, rust program does not fit that model: rust has to be built and available already, with the small program building later. (It is just a type example of several: in this case rust being the source of the example.) When the toolchain used is not from the system, the toolchain is built before what requires the toolchain. (toolchains can be far more than compilers, linkers, and the like.) > > Note that such setup is almost opposite to "regular builders" that have a > small amount of cores per poudriere builder, but large number of poudriere > builders! Official poudreire bulk -ca (from scratch) build something like 36000 port packages to manage resource use for those builds. As a fraction, the large portion of those are individually relatively small port-package builds, after prerequisites are available. Personal "just one end target" from-scratch builds are tiny by comparison. Normally targeting a single individual port-package vs. normally doing poudriere bulk -a (or -ca) can be rather different contexts. What minimizes overall elapsed time need not be the same for both, even ignoring other resource management. My usual personal way of bulk building [including bulk -a (and -ca)] is different than both and has historically scaled okay for the likes of (figures from memory): ) 32 FreeBSD OS cpus (16 cores), 192 GiBytes of RAM, 704 GiBytes of RAM+SWAP. (a 7950X3D amd64 context; storage media room for SWAP space had to trade off with other storage space use, so not 912 GiBytes for RAM+SWAP) ) 32 FreeBSD OS cpus (16 cores), 128 GiBytes of RAM, 608 GiBytes of RAM+SWAP. (a Threadripper 1950X amd64 context) ) 16 FreeBSD cpus/cores, 64 GiBytes of RAM, 304 GiBytes of RAM+SWAP. (a Honeycomb aarch64 context, not `bulk -a` tested to completion) ) 8 FreeBSD cpus/cores, 32 GiBytes of RAM, 150 GiBytes of RAM+SWAP. (a Windows Dev Kit 2023 aarch64 context, USB media, not `bulk -a` tested to completion) Scaling down from that tends to mean managing more tradeoffs: working somewhat differently. And, even presuming plenty of storage space, scaling up would not scale far as well: for the above there are #cpu bulders, each allowed to have #cpu make jobs (for ports that respect such, some to not). That is #cpus*#cpus for the make jobs upper limit (ignoring the odd ports). Port-packages that would end up with huge or large tmpfs are disabled from having such (thus needing the file system storage space). Some port-packages are set up to be mutually exclusive for when they build. > >> Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz / 384GB RAM hw.ncpu=16 SHT=off >> > If it scales good further, 96 cores will manage electron in one hour! :) With RAM scaled to match: 2304 GiBytes? (No mention of SWAP was made.) I wonder what the time for SHT=on (32 FreeBSD cpus) would be for the overall build ( not just devel/electron41 )? > > -- === Mark Millard marklmi at yahoo.com
