From nobody Thu Nov 16 04:50:21 2023 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SW6zf0PSyz518mq for ; Thu, 16 Nov 2023 04:50:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4SW6zc3Tmvz3CYC for ; Thu, 16 Nov 2023 04:50:36 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=qVtjVpwe; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.148 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700110234; bh=/Me5x+poyd+r3mjshrGrRlQ1UHOsMJ2MklQLiY1ICcY=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject:Reply-To; b=qVtjVpweDNjh9VmIMXSVln73N26VQKUSPRH0hyz+zuNxa7Fz6/p0Tdxrclr4E0L/yhaSVxaaRqM1H0SvhqLAt6UcZjGRaG8ugQxaEWaHdI7NxtNHqMQ0no5WPzUxE4PVI3HJ77R8+VXW47R3nZPx/tq3BHLN6ZyFICVgXk4T4vQ01P5Tu8mCj6/uC4dNd+okJwHl2VQJVKCe09MLh9yWycXJ6tZXE5i3tNlIgX11FNIHxHxi4wUCG4Y13vduic5l6/pN4zzYKS8C3/kshzdGvpovwXZEdxmiU4oM5dbeGa6RurEnAqO1jliF6TSzHZl6XrOUV5lmQRGTk9+XI7n3EA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1700110234; bh=5WtHq++WIJQqFIKwBzgXTDtVAq/9NWsBnZLwKKAIQ4p=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=jpUtrUcITZO1XAYKtGOZHWaYd28zmQT52KiZXwA02A3jKnHOUqpXvZd2wizSDGPZrlCaRelwww1hRV5aXcnsb95zcNG6jx0Wx3uG7fJl2b88tvZRAsgRmMs/OEJQMejyMjedW0VQGLxtYZSGBkeGdEMIRHDwfDYIFMZAYl+r2/BCWww50yNs94VZkSaD1nnsZTzuOaTSI+k2MRcI/uK3qybjs3PZOJGzVeMQe2PNFWblqwgm2LqsH3HUUR+3L3ClZoEgmxJU6i+qzscIQ2a/ohZeIoPoipMcYCvjL3jCa1WoG+dKlZzV/tTrXPBXiyjyyv4fWQnAara7LHUPMjPRQA== X-YMail-OSG: xibnQiIVM1ms0yuhg_QPzum1_wf2FBqSQWNq3rHsuZg9Xe7g1w2luXeWRyV9_Wo pvMaYyUGWheKKwiaWm1lF_T_LtuQw8t2X6WqQ8Cf79MpyudAEzzVyTIuWKrhyBUvdyfM2uBnaA9p skDuTyfloKqIGX.FgmhGhbID15PFRzAgcl.426iVPcGvgcaQfmypDZu5hcdwSd6igJlfps4v2aY7 Rkcc7LGWzql3GM143q79nxQLMVB09GycmHWcs1HO_h32p6HE3Sgp8b1x1XK1ErFZTsZlFNpBJwJn lzsQ6Q8LRKSYNnHnbAigDr1aU_8UNFwc.S53u4K.njy_0QJm_gkhmHod5Z_vJPyadP4Fqqh3DPNE kI6Ean28zzJ_Tmg8Qx_rfzxFzQN1Dn3Cb5h9c59Hk4Zpd2ORYJdCDcKB16aoL.hLP5SWX.90VCRE vegsK72ooBegMqkTOnJ_cdjoZ6jS5wHFQkMVV46weJHOqDJavu.IPrsSL1jM61Qf8cGiiQ1ERohI oI4kVCD.oOV4uocJbryYBnKLFMFcKevO5N6WgTyIX51M0CMI5PY01Dg0A1YJ.zWRlc4NVmpdw61M PggpnJoN22nJJnB5iAvLV6mcm6YSkewmTtPkcIqtCUkOw3OCgBfMODfBVGov8xiKiJzaovDGBDAh oed2pH2LJvrXTDMkvi7ZRvH1zloL2_Kh27h_juVEin4ZJKZ9vboS.g1g_THiUMYyxzOUsTyj4fUa ktsiQNy_Oao3TLIALicv8UgFI.xIYVNj4ChcD1oExwmnA69ohw4H4ShRDakp9YjObPhB1dlmzbo2 m4iOAQs0527x0pzu6bJ0Yakc8BANMKEDnuzBdn3W.S6gxlePHY.OmbtdwSlkas.WhilIAs.RLhAm zibiNBbkiIxOAVhA6mSqti6HGVuFtDFpQ6mNifJTjHr8ihdYvRIBjgSiTQrTYd5rLiXf.R5yHDJX Fzz17PD0o0V372VliVZ.3OYTdNq5LECMJLll3oA5oTErSf4X_0.TRwbotXb_l4TToVtp3gNinEig 45Faptsm44EH2Izf0KckYlWfsgXY3yjILtPc1OOyZdTm7Vn4WpNHA3rT7K_wUa6xPshDL4jeu_wO hmc4wQJpThIcdq8Z_0f_jZ5XlKbkyUZPZZXsraXNNUgCaAU6poQ7gMrW3vqcYaA1pJ0nBsZBX.De ghoLdwPaCX1KhS.MwrYCOHi67RXPpGZ002Sbd3sqnduEcRQR8EKs3knS20r_TVeTgv16lVvCoXfz 8ircVVUiwl2XTJ4JNJFMJzRWsXobY2wDcajhTI3xeffxsSArE.j8tA.qfrHc1xnULZMb_vC.m1t6 xl1cOEvfFeC90zlFnU6ItgwZe7qaBzaTktGBZ18kQkP2tIRxNi4ghZj4ZUj6GhkKyP1RFHxBnR_h anuWTzMOyZSQlyo5oYyOK09z_yIQsvYve3KVGd_TUmZiboUibD1fXMCGQ8Q0FysE1395.M6EliRT Brt442lA_atQZQxLfYT9FtErqtydQH1xR5KSnlBBGtk7FBt9s3jAtnN6tPVz9nqUFY22OvPxAXPa 3nm4oqfLkKDdB9D4DY8Ei3UCqpoJh6XWw.ZSOsNxgOsrPbATz8IjOEwgAnUwvrcGJQRtt2R76oFX Tne6DE_De8AQRxIGNzJq9ixRf072rhX5uHYjUXG3iSbjTfz.XSj5VjR0d4._4.iLwwhnqhSSPcQl YwFGahu.87U2lGuHbJig3HhGnMjXSi.cRL.ZVstqHpnrCImHdomb9YNgbJ2GcmmpFhCmQ3pC6wvh pcHxkNqfXWMlzSosE_ZcxsXAJZ5v3CBOosc0FfeVOZ0f_cflXLnAjUZUmBA5axoxN7qxVQaQnJzk Ckc4FMZe1usJDQ3pjgaILBFHFYSHkQz4IjRUZVXrZhgheqvfuJrPhYNHHdjMLl_dWRoKK2Z7zFGh 22lK19kX_FOmlMnakOdfROTh9qzHIT6SAGS2_5tomHWQtrnMMjjWZRhmFJbyJkjLkWXRmTPnBp9R X.6eWwyBbQtz3KpaN2tkFD6oly1AsPG7bkyKiKWhQDtiw8sRkRyKPfPGPT8SBXu4fSTs5yI2doBh sOFi9ZJ.ic_16Vh4u56mmys17.5k1XjepqoAh8yW6n3EYUSYPe0U5XjLFR0MmtNhiecV1oCypkS. 52DSlpi2wAJvZRyKpAAP8INDSvrhx1yFyvErot.lwsaitWhiLli6AylAA7wUTUuk_ZtpCWZ5zzE4 NbUA1bJqg_ZddsZaFizJwpL6.kIPOS3DmSwRNkrKmGsvEEBaTYGGlADtccUsPZFelZREorvAD.g- - X-Sonic-MF: X-Sonic-ID: 45ac0303-8285-4ed0-b289-078fa5c259e3 Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Nov 2023 04:50:34 +0000 Received: by hermes--production-gq1-59b5df67b6-srhh5 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d53f5e077ee6609f13a0b5e09ae42976; Thu, 16 Nov 2023 04:50:32 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\)) Subject: Re: Ryzen 9 7950X3D bulk -a times: adding an example with SMT disabled (so 16 hardware threads, not 32) Date: Wed, 15 Nov 2023 20:50:21 -0800 References: <88907269-7ECD-4539-AA3D-AD0A31B13CA7@yahoo.com> <4596CD14-82EF-4213-9CD8-D065A2F7E073@yahoo.com> To: FreeBSD Hackers , FreeBSD Mailing List In-Reply-To: <4596CD14-82EF-4213-9CD8-D065A2F7E073@yahoo.com> Message-Id: X-Mailer: Apple Mail (2.3774.200.91.1.1) X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.148:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.148:from]; DKIM_TRACE(0.00)[yahoo.com:+]; TO_DN_ALL(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.com]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SW6zc3Tmvz3CYC X-Spamd-Bar: --- On Nov 12, 2023, at 18:00, Mark Millard wrote: > On Nov 9, 2023, at 17:26, Mark Millard wrote: >=20 >> Reading some benchmark results for compilation activity that showed = some >> SMT vs. not examples and also using my C++ variant of the old HINT >> benchmark, I ended up curious how a non-SMT from scratch bulk -a = would >> end up (ZFS context) compared my prior SMT based run. >>=20 >> I use a high load average style of bulk -a activity that has = USE_TMPFS=3Dall >> involved. The system has 96 GiBytes of RAM (total across the 2 = DIMMs). >> The original under 1.5 day time definitely had significant swap space = use >> (RAM+SWAP =3D 96 GiBYtes + 364 GiBytes =3D=3D 460 GiBytes =3D=3D = 471040 MiBytes). >> The media was (and is) a PCIe based Optane 905P 1.5T. ZFS on a single >> partition on the single drive, ZFS used just for bectl reasons, not = other >> typical use-ZFS reasons. I've not controlled the ARC size-range = explicitly. >>=20 >> So less swap partition use is part of contribution to the results. >>=20 >> The original bulk -a spent a couple of hours at the end where it was >> just fetching and building textproc/stardict-quick . I have not = cleared >> out /usr/ports/distfiles or updated anything. >>=20 >> So fetch time is also a difference here. >>=20 >> SMT (32 hardware threads, original bulk -a): >>=20 >> [33:10:00] [32] [04:37:23] Finished emulators/libretro-mame | = libretro-mame-20220124_1: Success >> [35:36:51] [23] [03:44:04] Finished textproc/stardict-quick | = stardict-quick-2.4.2_9: Success >> . . . >> [main-amd64-bulk_a-default] [2023-11-01_07h14m50s] [committing:] = Queued: 34683 Built: 33826 Failed: 179 Skipped: 358 Ignored: 320 = Fetched: 0 Tobuild: 0 Time: 35:37:55 >>=20 >> Swap-involved MaxObs (Max Observed) figures: >> 173310Mi MaxObsUsed >> 256332Mi MaxObs(Act+Lndry+SwapUsed) >> 265551Mi MaxObs(Act+Wir+Lndry+SwapUsed) >> (So 265551Mi of 471040Mi RAM+SWAP.) >>=20 >> Just-RAM MaxObs figures: >> 81066Mi MaxObsActive >> (Given the complications of getting usefully comparable wired figures = for ZFS (ARC): omit.) >> 94493Mi MaxObs(Act+Wir+Lndry) >>=20 >> Note: MaxObs(A+B+C) <=3D MaxObs(A)+MaxObs(B)+MaxObs(C) >>=20 >> ALLOW_MAKE_JOBS=3Dyes was used. No explicit restriction on = PARALLEL_JOBS >> or MAKE_JOBS_NUMBER (or analogous). So 32 builders allowed, each = allowed >> 32 make jobs. This explains the high load averages of the bulk -a : >>=20 >> load averages . . . MaxObs: 360.70, 267.63, 210.84 >> (Those need not be all from the same time frame during the bulk -a .) >>=20 >> As for the ports vintage: >>=20 >> # ~/fbsd-based-on-what-commit.sh -C /usr/ports/ >> 6ec8e3450b29 (HEAD -> main, freebsd/main, freebsd/HEAD) devel/sdts++: = Mark DEPRECATED >> Author: Muhammad Moinur Rahman >> Commit: Muhammad Moinur Rahman >> CommitDate: 2023-10-21 19:01:38 +0000 >> branch: main >> merge-base: 6ec8e3450b29462a590d09fb0b07ed214d456bd5 >> merge-base: CommitDate: 2023-10-21 19:01:38 +0000 >> n637598 (--first-parent --count for merge-base) >>=20 >> I do have a environment that avoids various LLVM builds taking >> as long to build : >>=20 >> llvm1[3-7] : no MLIR, no FLANG >> llvm1[4-7] : use BE_NATIVE >> other llvm* : use defaults (so, no avoidance) >>=20 >> I also prevent the builds from using strip on most of the install >> materials built (not just toolchain materials). >>=20 >>=20 >> non-SMT (16 hardware threads): >>=20 >> Note one builder (math/fricas), the last still present, was >> stuck and I had to kill processes to have it stop unless I >> was willing to wiat for my large timeout figures. The last >> builder normal-finish was: >>=20 >> [39:48:10] [09] [00:16:23] Finished devel/gcc-msp430-ti-toolchain | = gcc-msp430-ti-toolchain-9.3.1.2.20210722_1: Success >>=20 >> So, trying to place some bounds for comparing to SMT (32 hw threads) >> and non-SMT (16 hw threads): >>=20 >> 33:10:00 SMT -> 39:48:10 non-SMT would be over 6.5 hrs longer for = non-SMT >> 35:36:51 SMT -> 39:48:10 non-SMT would be over 4 hrs longer for = non-SMT >>=20 >> As for SMT vs. non-SMT Maximum Observed figures: >>=20 >> SMT load averages . . . MaxObs: 360.70, 267.63, 210.84 >> non-SMT load averages . . . MaxObs: 152.89, 100.94, 76.28 >>=20 >> Swap-involved MaxObs figures for SMT (32 hw threads) vs not (16): >> 173310Mi vs. 33003Mi MaxObsUsed >> 256332Mi vs. 117221Mi MaxObs(Act+Lndry+SwapUsed) >> 265551Mi vs. 124776Mi MaxObs(Act+Wir+Lndry+SwapUsed) >>=20 >> Just-RAM MaxObs figures for SMT (32 hw threads) vs not (16): >> 81066Mi vs. 69763Mi MaxObsActive >> (Given the complications of getting usefully comparable wired figures = for ZFS (ARC): omit.) >> 94493Mi vs. 94303Mi MaxObs(Act+Wir+Lndry) >>=20 >=20 > I've added a section for a plot for the 7950X3D to the end of: >=20 > = https://github.com/markmi/acpphint/blob/master/Some_acpphint_curves_with_n= otes.md >=20 > It is from a C++ variant of the old HINT benchmark and includes > showing RAM caching consequences for the benchmark. The about > 32 MiByte and about 96 MiByte cache sizes for the 2 CCDs are > observable. >=20 > I'll also note that for the devices present (active and not), > at fully active the 7950X3D seems to use 225 Watts .. 235 Watts > at the power cable for FreeBSD. Idle FreeBSD: more like 96 > Watts. >=20 > (No video card. 2 forms of Optane 905P 1.5TB, one active. One > Samsung 960 Pro 2TB, inactive. One Samsung 970 EVO Plus 2TB, > inactive. 96 GiBytes of RAM total across 2 DIMMs. Fans and > AIO cooling. Keyboard and mouse USB powered. USB3 Ethernet > dongle. Monitor connection.) >=20 >=20 > ThreadRipper 1950X "bulk -a" test in progress: >=20 > I'm running a from-scratch USE_TMPFS=3Dall "bulk -a" on the > ThreadRipper 1950X (128 GiBytes of RAM). =46rom what I've seen > so far, it looks to likely take over 72 hr, so 2x+ as long > as the 7950X3D. (Samgsung 960 Pro 1TB system media and > Optane 900 480 GB swap space media in use, 447 GiByte I as I > remember). The ZFS partition on the 960 Pro has ashift=3D14 .) > It has a slightly modified copy of the ZFS from the 7950X3D > as far as starting content goes. It does have openzfs-2.2 > compatibility fully enabled for its pool, including block > cloning, unlike any other ZFS I have around > (openzfs-2.1-freebsd). ThreadRipper 1950X: . . . [85:21:50] [27] [02:06:01] Finished databases/mongodb60 | = mongodb60-6.0.11: Success [85:34:00] [28] [03:23:06] Finished biology/ncbi-cxx-toolkit | = ncbi-cxx-toolkit-27.0.0_1: Success [85:46:31] [30] [08:19:30] Finished cad/kicad-library-packages3d | = kicad-library-packages3d-7.0.2_2: Success [87:07:02] [03] [13:00:45] Finished emulators/libretro-mame | = libretro-mame-20220124_1: Success But one port that normally takes little time got stuck (in kqread, apparently against a child process), resulting in (later): # poudriere status -b [main-amd64-bulk_a-default] [2023-11-11_17h59m25s] [parallel_build:] = Queued: 34683 Built: 33807 Failed: 173 Skipped: 382 Ignored: 320 = Fetched: 0 Tobuild: 1 Time: 88:17:59 ID TOTAL ORIGIN PKGNAME PHASE PHASE TMPFS = CPU% MEM% [05] 17:27:25 ftp/curlie | curlie-1.6.7_15 check-sanity 17:27:15 1.28 = GiB =20 =3D>> Logs: = /usr/local/poudriere/data/logs/bulk/main-amd64-bulk_a-default/2023-11-11_1= 7h59m25s So it looks like: Ryzen 9 7950X 96 GiBytes RAM (5600MT/s): 33 hr or so. ThreadRipper 1950X 128 GiBytes RAM (2400MT/s): 87 hr or so. For reference (both 32 hardware threads): Ryzen 9 7950X: 265551Mi MaxObs(Act+Wir+Lndry+SwapUsed) ThreadRipper 1950X: 245564Mi MaxObs(Act+Wir+Lndry+SwapUsed) (The 96 GiByte vs. 128 GiByte RAM size difference makes other figures messier to compare.) I have updated the 7950X UEFI and am rerunning the from-scratch bulk -a test in the ZFS context to check on system stability for such. =3D=3D=3D Mark Millard marklmi at yahoo.com