FFFFFFFOn Tue, 13 Dec 2005, Johnny Billquist wrote:

> Date: Tue, 13 Dec 2005 03:52:55 +0100
> From: Johnny Billquist <johnny.billquist@softjar.se>
> To: James Chacon <jmc@NetBSD.org>
> Cc: Dave McGuire <mcguire@neurotica.com>, port-vax@NetBSD.org
> Subject: Re: Error cross-compiling lib/libc/rpc/svc_vc.c
> 
> James Chacon wrote:
>> On Tue, Dec 13, 2005 at 03:00:07AM +0100, Johnny Billquist wrote:
>> 
>>> James Chacon wrote:
>>> 
>>>> On Tue, Dec 13, 2005 at 01:24:58AM +0100, Johnny Billquist wrote:
>>>> 
>>>>> James Chacon wrote:
>>>>> 
>>>>>> I'd be interested to pinpoint examples here. I'll almost bet that's the
>>>>>> compiler getting slower. It's been fairly well documented that as gcc 
>>>>>> goes
>>>>>> up in versions the slower it gets.
>>>>> 
>>>>> Oh. The fact that we now use build.sh, which runs over the same 
>>>>> directory tree a number of times definitely hurts a lot.
>>>> 
>>>> Umm..we always did. Make obj always ran before make includes and both
>>>> scanned the entire tree.
>>> 
>>> No, we did not.
>>> I remember when we didn't have a build.sh... :-)
>> 
>> So do I and I'm reading the Makefile from 1.5.
>> 
>> It clearly (in make build) does a tree pass of cleandir, a tree pass of 
>> make obj, includes, builds lib, etc and installs it and then does a 
>> complete pass again with dependall.
>
> I didn't do a make build. I don't remember when make build appeared, but I 
> don't even think it existed at the time I started using NetBSD.
> I have actually never used make build myself, as far as I can remember. I 
> finally switched over to using build.sh around the 1.6 or so.
>
>>> And furthermore, the tools directory is passed through a few extra times, 
>>> as is gnu/lib and some other places...
>> 
>> gnu/lib always was.
>
> Not for me. But I guess you can understand that from above.
>
>>>> build.sh just calls make in the end....
>>> 
>>> Yes. A number of times.
>> 
>> I actually doubt it's more than 1 extra pass in the end and even then most
>> of the passes are optmized now to not go any deeper than they need to.
>
> I admit that this has improved a lot from a year or two ago, when we had a 
> separate pass for "depend", followed by the "all" targets, and other extra 
> passes that I've probably forgotten about.
> But it still is heavy work.
>
>>>>> The libcrypto stuff that was included some time ago really added one day 
>>>>> or two to a build on my 8650.
>>>> 
>>>> libcrypto added back around 1.5? (or even before). This is like 5 years 
>>>> ago...
>>> 
>>> Yes.
>> 
>> Ok, so you want the system to be what it was in 1995 basically. Just come 
>> out
>> and say that then. You clearly claimed in your original email it was "stuff
>> from the last year", yet all your examples of *bad* stuff are 5+ years old.
>
> You must read rather sloppy. Or how did you miss pam and NLS?
>
>> If PR's get open they get fixed in general. Maybe not right away but that's
>> the only way we know. The hooks aren't put in so they can't be used. 
>> They're
>> put in so people can use them. If you chose not to, and then complain about
>> how you're getting all this stuff you don't want I really don't have an
>> answer for you...
>
> Sigh. So I complain that building takes for ever, and a big reason is that 
> the system now contains so much more than in the past. You point out that 
> much can be skipped. I point out that this will result in build.sh failing.
> And the answer to that is basically: tough luck. It should work. Wait for a 
> while, and maybe you can build the system.
> That's really comforting. So instead of waiting a week or two to have a new 
> system, I should wait a couple of months or so.
>
>>> You may take it anyway you want to. The basic fact is that building on a 
>>> VAX, any VAX, is becoming so slow it's not doable soon. No matter if you 
>>> call it FUD or not.
>> 
>> Got a modern example of anything that slowed it down significantly? 
>> Something
>> in the last year+? Again...all your examples come down to "in the good old
>> days of 4.4lite it was great!".
>
> I don't know why I get dragged into this discussion every time I mention that 
> the system is becoming larger and slower to build.
> Every time I get the response from people that I should blame gcc. Noone seem 
> to be willing to actually admit that NetBSD has grown a lot, and keep growing 
> and that this hurts performance and builds. Heck, even though you yourself 
> admit that libc has grown by 50% (it would be interesting to know by which 
> measure that is, by the way), you still ask me for examples of things that 
> has slowed down the build. Well, apart from the growth in libc, you have (as 
> I mentioned) pam and NLS for instance. Moving over to having everything 
> linked dynamically also is a performance hit, which I suspect is quite 
> measurable when running so many processes as the build are.
> Hmm, just moving the tools over to static linked images might actually give 
> some gains. But this is just some educated guesses. I haven't done any 
> measurements.
>
>>> And building the whole 4.3BSD took about half a day. Have we really gotten 
>>> that much improvements to motivate a build time increasing from 12 hours 
>>> to 7 days?
>>> Don't even bother answering. I suspect you'll just call it more FUD 
>>> anyway. The basic fact remains, NetBSD will soon not be usable on systems 
>>> older than a few years because it requires too much processing power to do 
>>> just a build, because it contains everything. So I stand by my original 
>>> claim, I believe the VAX will soon not be supported anymore, since it's 
>>> just too slow for the demands of the new versions of NetBSD.
>> 
>> Really? It's not usable or just can't be easily natively compiled? I've
>> yet to hear anything claiming it's becoming unusably slow.
>
> The VAX 8650 is far from the slowest VAX you can find, and yet, doing just a 
> "build.sh build" will take about a week, and then you also have to restart it 
> three times, which adds more time.
> How slow does it need to be before becoming unusably slow? A month for a 
> build? A year? We're probably soon getting there on the slower machines 
> available.
>
>>>> Is there a PR for this?
>>> 
>>> Don't know. I thorugh there was, but searching now I can't find any. There 
>>> should probably be several:
>>> One about build.sh not runnable. People reported it on this list several 
>>> years ago, and I atleast told them that they could rerun the build several 
>>> times until they got past the problem.
>> 
>> not runnable? I don't understand here. If builds crash people should file
>> PR's. Thats the only way things will get fixed long term.
>
> Certainly.
> I'll file a pr right away to make you happy.
>
> 	Johnny
>
> -- 
> Johnny Billquist                  || "I'm on a bus
>                                  ||  on a psychedelic trip
> email: bqt@update.uu.se           ||  Reading murder books
> pdp is alive!                     ||  tryin' to stay hip" - B. Idol
>

-- 
As long as people believe in absurdities they will continue to commit
atrocities.  -Voltaire