--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Fri, Jun 29, 2018 at 8:31 PM, Florian Weimer <f...@deneb.enyo.de> wrote: > * Luke Kenneth Casson Leighton: > >> that is not a surprise to hear: the massive thrashing caused by the >> linker phase not being possible to be RAM-resident will be absolutely >> hammering the drives beyond reasonable wear-and-tear limits. which is >> why i'm recommending people try "-Wl,--no-keep-memory". > > Note that ld will sometimes stuff everything into a single RWX segment > as a result, which is not desirable. florian, thank you for responding: i've put a copy of the insights that you give into the bugreport at https://sourceware.org/bugzilla/show_bug.cgi?id=22831#c16 > Unfortunately, without significant investment into historic linker > technologies (with external sorting and that kind of stuff), yes, ah ha! funnily enough the algorithm that i was asked to create back in 1988 was an external matrix-multiply, i take it you are talking about the same thing, where linking is done using explicit load-process-save cycles rather than relying on swap. > I don't > think it is viable to build 32-bit software natively in the near > future. i noted an alternative strategy in the bugreport: if binutils *at the very least* were to look at the available resident RAM and only malloc'd and used up to that amount, and kept only a few (or even just one) object file in memory at a time and did all the linking for that, it would be infinitely better than the current situation which is *only going to get worse*. > Maybe next year only a few packages will need exceptions, but > the number will grow with each month. well... that ignores the fact that at some point in the next few years there will be a package that needs 16 GB of resident RAM to link. and a few years after that it will be 32 GB. and that's on 64-bit systems. the package's name will probably be "firefox", given the current growth rate. does debian *really* want to have to upgrade all 64-bit systems in the build farm first to 16 GB RAM and then to 32 GB and then to 64 GB?? can the powerpc64 systems and all other 64-bit architectures even *be* upgraded to 16 GB then 32 GB then 64 GB of RAM?? basically the problems faced by 32-bit systems are a warning shot across the bows about ld not really being kept up-to-date with the increases in software complexity that's being thrown at it. it's *NOT* just about 32-bit. this problem can basically be faced REactively... or it can be faced PROactively: the historic linker strategies that you mention are i feel going to be needed in some years' time *even for 64-bit*. l.
