From nobody Sat Oct 28 08:48:04 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 4SHY8X70n6z4yc8r for ; Sat, 28 Oct 2023 08:48:12 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Received: from smtp-bc0b.mail.infomaniak.ch (smtp-bc0b.mail.infomaniak.ch [45.157.188.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "relay.mail.infomaniak.ch", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SHY8T5TjSz4JBb for ; Sat, 28 Oct 2023 08:48:09 +0000 (UTC) (envelope-from daniel.engberg.lists@pyret.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pyret.net header.s=20231006 header.b=iPQm5hFj; spf=pass (mx1.freebsd.org: domain of daniel.engberg.lists@pyret.net designates 45.157.188.11 as permitted sender) smtp.mailfrom=daniel.engberg.lists@pyret.net; dmarc=pass (policy=reject) header.from=pyret.net Received: from smtp-3-0001.mail.infomaniak.ch (unknown [10.4.36.108]) by smtp-2-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4SHY8N3QLpzMq0NR for ; Sat, 28 Oct 2023 08:48:04 +0000 (UTC) Received: from unknown by smtp-3-0001.mail.infomaniak.ch (Postfix) with ESMTPA id 4SHY8N0fw2zMpnPj for ; Sat, 28 Oct 2023 10:48:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pyret.net; s=20231006; t=1698482884; bh=37I7lxrgZDIHsDNEsgDxedeYyxouzedQrTHibpPU+cU=; h=Date:Subject:From:Reply-To:To:From; b=iPQm5hFj1EAi+gFtKJqpBTi/1m0Frk2hBoo5li8znxOzdPuukrH2ePf+ngHQE5Dpi sPUwY7XoZnhwH5TTcxcz67T5ndbxRtipi7H9qhLqjlXy4XAvIkE/RFYj0BnFfpElH0 DqkABTAf1RYe1UXzCqUFP+5FJDMqlY+1JXhBLWOEGiTf4QKL9aeNlEh5CDC0y2LupS b5CJINMQID0E4CNHCmalEyDjn9UjXqzG+ldhFmB25wLM/RZRbOIc7XOAbTItS2GBGQ R3yZK5P8p8LiPv54QjdHzWA1sG6A3Uo3s3uhl2w7IlPmCBO0Xyx497AHGJX00Fh5bI 59eo2JbT6+GYw== Message-ID: Date: Sat, 28 Oct 2023 10:48:04 +0200 Subject: Re: We need to do something about build times From: Daniel Engberg Reply-To: Daniel Engberg To: freebsd-ports@freebsd.org 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 Content-Type: multipart/alternative; boundary="_=_swift_1698482884_bda8de780d32cd8a5205a66d62e1d524_=_" X-WS-User-Origin: eyJpdiI6IllieHBKL1Jxc1V0ZjEwNWIybkNaSUE9PSIsInZhbHVlIjoiVzRycGd4Zno0dlFLeGNHSGVrU1lzZz09IiwibWFjIjoiOTRkMGQ4YWQ5NGM2ODEwMzZhZGQ1NDEzOTExZjVlYmY3MjExMWZhNjliMjE3MDcxMTJiNGEwNGM3YmQ2NjI5YSIsInRhZyI6IiJ9 X-WS-User-Mbox: eyJpdiI6IkZuM2xNdWhDUHVSVzROWGJLeFJWMkE9PSIsInZhbHVlIjoiaFplRFJNTjNIdUFaN3ZkZnRoVjF5Zz09IiwibWFjIjoiYzQ3YTljZmI2YzcwYzQzY2YyNGEyOGNmNTU5YTgyZDU5YTEwOGE0MGEzNWUyMDE0NDZkOTg0ZmViMmIxZjc0MSIsInRhZyI6IiJ9 X-WS-Location: eJxzKUpMKykGAAfpAmU- X-Mailer: Infomaniak Workspace (1.3.581) X-Infomaniak-Routing: alpha X-Spamd-Result: default: False [-3.11 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FAKE_REPLY(1.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.910]; DMARC_POLICY_ALLOW(-0.50)[pyret.net,reject]; R_SPF_ALLOW(-0.20)[+ip4:45.157.188.8/29]; RWL_MAILSPIKE_VERYGOOD(-0.20)[45.157.188.11:from]; R_DKIM_ALLOW(-0.20)[pyret.net:s=20231006]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MLMMJ_DEST(0.00)[freebsd-ports@freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-ports@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[45.157.188.11:from]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; HAS_REPLYTO(0.00)[daniel.engberg.lists@pyret.net]; ASN(0.00)[asn:29222, ipnet:45.157.188.0/22, country:CH]; TO_DN_NONE(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; DKIM_TRACE(0.00)[pyret.net:+]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4SHY8T5TjSz4JBb X-Spamd-Bar: --- --_=_swift_1698482884_bda8de780d32cd8a5205a66d62e1d524_=_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Many interesting thoughts about current situation, here's my take = on it and I'm also trying to catch up. Some ports do require quite a= lot of CPU time and memory to build, I fully understand that not everyon= e is using the latest hardware available but there's little we can do abo= ut upstream projects overall since the ports tree is after all intended f= or packaging not maintaining. By that I mean there will likely be little = to no action taken if you report upstream that lets say Rust don't build = with 12Gbyte of RAM. I do agree that if we can consolidate dependencies= it's for the better in terms of build times, disk footprint (for insta= lled ports, might not be much of an issue these days) and potential overl= apping libraries/dependencies. What we need to accept is that 4 cores and= 16Gb RAM isn't a "powerhouse" that will build whatever you throw at it, = that's the reality. We can't adapt ports to some arbitrary "hardware requ= irement", that's not viable nor do we have anywhere near the manpower to = do so however if we can streamline the build with little effort by all me= ans, go for it. What I have concerns about is adapting port options th= at by default potentially will harm performance and disk footprint in fav= our of "it builds faster". I would at least like to claim that we primari= ly use FreeBSD to run applications not to build ports. If we can combine = both that would be great but the former should be prioritized over latter= . If we can make packages smaller in size we should because it benefits= "everyone" however if it is of a very little gain and adds a lot of ti= me to the build it should be evaluated. For example we do apply LTO and a= few other optimizations to all Rust (Cargo based) ports because it great= ly reduces binary size and in some cases also increases peformance while = increasing total build by a bit. There are already other distros looking = into enabling LTO "treewide" so we're likely going to head there too even= tually. Porters Handbook covers unbundling and is also a policy for se= veral other distros. I think we do a pretty good about about it in genera= l however some projects makes it very hard or impossible to unbundle he= avy dependencies, all we can do here is to discuss it with upstream. Whil= e we could "maintain" our own set of patches it's for certain a recipe fo= r ports getting abandoned due to maintence burden sooner than later. In s= hort, please upstream and have a discussion with upstream about such conc= erns. We already miss out in some cases quite significant performance= enhancements with pre-built packages for ports that do not support run= -time detection of hardware capatibilities so we probably need to look at= difference target branches for each arch futher down the road adding mor= e overall load. Some observations on my end,=20 Without carefully m= easuring I do find that my Poduriere instances in many cases spends quite= a bit of time not building but spending quite a bit of time in configure= stage and struggle to scale over ~4-6 jobs. What we can do per port l= evel that improves build times and scaling in general:=20 If upstream = uses GNU Autotools, use upstream release archives as they usually contain= s a configure script ready to run which means that you can avoid USES=3D = autoreconf which is slow and adds unncessary dependencies. If upstre= am provides an alternative to GNU Autotools and/or gmake, libtool such as= CMake or Meson it will likely run configure stage faster and build quick= er, sometimes by quite a bit especially if you have a system with many "s= low" cores (such as ARM but even x86 to some degree).=C2=A0 On some ports= you can cut down build times ~40-50% because of better scaling and proce= ssing, avoiding USES=3D autoreconf and friends. You likely wont see that = much of a difference overall but 10-20% isn't impossible (slow systems su= ch as RockPro64 tend to see better improvements). There might be some qui= rks switching build framework that you might need to work out with upstre= am but it's usually worth the effort in the end. Not saying that it'll co= mpensate for spending 8h build LLVM/Clang but if we can "convert" lets sa= y100 ports or more we will probably reduice the overall build time by qui= te a bit.=20 If dependencies are unbundled you can save I/O and proces= sing time by not extracting. Example: https://cgit.freebsd.org/por= ts/tree/net-mgmt/netdata/Makefile#n32 Best regards, Daniel (diizz= y@) --_=_swift_1698482884_bda8de780d32cd8a5205a66d62e1d524_=_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

Many interesting thoughts about= current situation, here's my take on it and I'm also trying to catch up.

Some ports do require quite a lot of CPU time a= nd memory to build, I fully understand that not everyone is using the lates= t hardware available but there's little we can do about upstream projects o= verall since the ports tree is after all intended for packaging not maintai= ning. By that I mean there will likely be little to no action taken if you = report upstream that lets say Rust don't build with 12Gbyte of RAM. I do ag= ree that if we can consolidate dependencies it's for the better in terms of= build times, disk footprint (for installed ports, might not be much of an = issue these days) and potential overlapping libraries/dependencies. What we= need to accept is that 4 cores and 16Gb RAM isn't a "powerhouse" that will= build whatever you throw at it, that's the reality. We can't adapt ports t= o some arbitrary "hardware requirement", that's not viable nor do we have a= nywhere near the manpower to do so however if we can streamline the build w= ith little effort by all means, go for it.

Wha= t I have concerns about is adapting port options that by default potentiall= y will harm performance and disk footprint in favour of "it builds faster".= I would at least like to claim that we primarily use FreeBSD to run applic= ations not to build ports. If we can combine both that would be great but t= he former should be prioritized over latter. If we can make packages smalle= r in size we should because it benefits "everyone" however if it is of a ve= ry little gain and adds a lot of time to the build it should be evaluated. = For example we do apply LTO and a few other optimizations to all Rust (Carg= o based) ports because it greatly reduces binary size and in some cases als= o increases peformance while increasing total build by a bit. There are alr= eady other distros looking into enabling LTO "treewide" so we're likely goi= ng to head there too eventually.

Porters Handb= ook covers unbundling and is also a policy for several other distros. I thi= nk we do a pretty good about about it in general however some projects make= s it very hard or impossible to unbundle heavy dependencies, all we can do = here is to discuss it with upstream. While we could "maintain" our own set = of patches it's for certain a recipe for ports getting abandoned due to mai= ntence burden sooner than later. In short, please upstream and have a discu= ssion with upstream about such concerns.

We al= ready miss out in some cases quite significant performance enhancements wit= h pre-built packages for ports that do not support run-time detection of ha= rdware capatibilities so we probably need to look at difference target bran= ches for each arch futher down the road adding more overall load.
=

Some observations on my end,

<= div>Without carefully measuring I do find that my Poduriere instances in ma= ny cases spends quite a bit of time not building but spending quite a bit o= f time in configure stage and struggle to scale over ~4-6 jobs.

What we can do per port level that improves build times a= nd scaling in general:

If upstream uses GNU A= utotools, use upstream release archives as they usually contains a configur= e script ready to run which means that you can avoid USES=3D autoreconf whi= ch is slow and adds unncessary dependencies.

I= f upstream provides an alternative to GNU Autotools and/or gmake, libtool s= uch as CMake or Meson it will likely run configure stage faster and build q= uicker, sometimes by quite a bit especially if you have a system with many = "slow" cores (such as ARM but even x86 to some degree).  On some ports= you can cut down build times ~40-50% because of better scaling and process= ing, avoiding USES=3D autoreconf and friends. You likely wont see that much= of a difference overall but 10-20% isn't impossible (slow systems such as = RockPro64 tend to see better improvements). There might be some quirks swit= ching build framework that you might need to work out with upstream but it'= s usually worth the effort in the end. Not saying that it'll compensate for= spending 8h build LLVM/Clang but if we can "convert" lets say100 ports or = more we will probably reduice the overall build time by quite a bit.

If dependencies are unbundled you can save I/O and = processing time by not extracting.

<= /div>
Best regards,
Daniel (diizzy@)
--_=_swift_1698482884_bda8de780d32cd8a5205a66d62e1d524_=_--