Date: Sat, 28 Oct 2023 10:48:04 +0200 From: Daniel Engberg <daniel.engberg.lists@pyret.net> To: freebsd-ports@freebsd.org Subject: Re: We need to do something about build times Message-ID: <c35b5dea9d6a810c1e051d620534fa67@mail.infomaniak.com>
next in thread | raw e-mail | index | archive | help
--_=_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 <div>Hi,<br></div><div ><div><br></div><div>Many interesting thoughts about= current situation, here's my take on it and I'm also trying to catch up.<b= r></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div>= <div><br></div><div>Some observations on my end, <br></div><div><br></div><= 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.<br></div><d= iv><br></div><div>What we can do per port level that improves build times a= nd scaling in general: <br></div><div><br></div><div>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.<br></div><div><br></div><div>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. <br></= div><div><br></div><div>If dependencies are unbundled you can save I/O and = processing time by not extracting.<br></div><div>Example: <a href=3D"https:= //cgit.freebsd.org/ports/tree/net-mgmt/netdata/Makefile#n32">https://cgit.f= reebsd.org/ports/tree/net-mgmt/netdata/Makefile#n32</a><br></div><div><br><= /div><div>Best regards,<br></div><div>Daniel (diizzy@)<br></div></div> --_=_swift_1698482884_bda8de780d32cd8a5205a66d62e1d524_=_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c35b5dea9d6a810c1e051d620534fa67>