Re: Bountysource campaign for gcc-vax

[Jason Thorpe <thorpej%me.com@localhost>]

Can you file a bug on that?

Thx!

-- thorpej
Sent from my iPhone.

> On May 2, 2021, at 6:23 PM, Maciej W. Rozycki <macro%orcam.me.uk@localhost> wrote:
> 
> On Sun, 2 May 2021, John Klos wrote:
> 
>> Thank you for this. I don't have much time to give this as much attention as
>> it deserves, so this is the perfect amount of a how-to to at least get
>> started. I'll give it a go, hopefully some time this week.
> 
> I'm glad to be of help!
> 
>> -j 64? Must be nice ;)
> 
> Quite so, though for a VAX cross-compiler build the speed up is only 
> ninefold or so with `time' giving:
> 
> 8896.42user 346.68system 7:18.98elapsed 2105%CPU (0avgtext+0avgdata 533760maxresident)k
> 0inputs+7809792outputs (16778major+18136652minor)pagefaults 0swaps
> 
> for `-j 64' vs:
> 
> 3785.87user 263.91system 1:06:53elapsed 100%CPU (0avgtext+0avgdata 532608maxresident)k
> 0inputs+7257088outputs (293major+17848903minor)pagefaults 0swaps
> 
> for `-j 1' here.  Still it does make a huge difference.
> 
>> For NetBSD you can use `sysctl -n hw.ncpu`.
> 
> Good to know, thanks!  Sadly lizzie only says:
> 
> $ sysctl -n hw.ncpu
> 1
> $ 
> 
> On the positive side she also says:
> 
> $ uptime
> 4:21AM  up 212 days,  9:33, 2 users, load averages: 0.02, 0.01, 0.00
> $ 
> 
> after all that beating with GCC verification. :)  She tends to lose NTP 
> synchronisation though as the system clock drifts very badly when the load 
> becomes excessive, which I suppose is due to a kernel bug in setting the 
> scheduling priority for `ntpd'.  It's now off by well over an hour.
> 
>  Maciej