Port-vax archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: static binary timings (Was: Some more patches for GCC on NetBSD/VAX coming soon...)

Thanks for the report. Comments inline...

On 2016-04-02 22:08, David Brownlee wrote:

OK, I've run some pic/nopic timings on simh-3.9.0nb4 (As before on a
T420 laptop throttled down to 800mhz to emphasise any differences). This
is purely a "large differences in simh timing suggest its worth testing
on real hardware" :)

Two identical minimal installs onto simulated ra92s (pic 128M used,
nopic 731M). Only change was to boot once, then add 'makemandb=NO' to
rc.conf, and shutdown.

Timed from hitting return on the NetBSD boot countdown. All times relative

PIC
- First line of dmesg: 10sec
- kern.modulepath shown: 7sec
- rc.conf to login prompt: 140 sec
- Time to login as root: 5 sec

PIC
- First line of dmesg: 10sec
- kern.modulepath shown: 7sec
- rc.conf to login prompt: 114 sec
- Time to login as root: 2 sec

So, the kernel load & start, then autoconfig times are the same (which
is just a nice check - it would be worrying if they differed).
The nopic rc.conf is around 18% faster, which seems a significant
overhead (this is on a simh vax with 256M, so on a typical VAX the VM
savings of shared libraries probably outweigh this, but it does seem
like there may be more overhead in the shared libraries than we
originally thought).
I think the costs comes from disk and file I/O being really bad. Shared libraries implies more files to open and read, and eventually also symbols to resolve (although I would suspect that part would not be the main part of the cost). 


What is really surprising is the 2 sec vs 5 sec time to login, and that
was repeatable.
I think this is also a fallout from the same issue that file and disk operations are bad. Logins also means opening various files, and executables. All of which, with shared libraries, have all this extra overhead. 


That could be an edge case in terms of functionality, but one people are
definitely going to notice :)


Definitely.


Hoping someone has real hardware to hand to test now...
Well, I have some hardware. If you just tell me exactly what to test, and how, and I'll do it. I have at least one spare RA73 to put stuff on.
By the way, just as a pointing out on the problems with I/O. Doing a cvs update from the NetBSD repositoty to a VAX 8650 nowadays takes about 24h. And if you have another terminal where you run systat vmstat, you'd notice that interrupt time is almost 10%, system time about 40%, and user time somewhere around 30%. And the disks are not even kept more than maybe 50% busy. I have no idea what the system is doing the rest of the time... Comparing received data to what's in the disk files, I would assume, but it is a bit surprising that the CPU would be the limiting factor. Else there is something going on in the kernel that is consuming lots of resources for no apparent good reason. 
This is something I would seriously like to figure out...
Seriously. A cvs update should mean lots of network traffic, lots of disk activity, and not much else. So why is the disk sitting so idle, and the cpu chugging away in the kernel the whole time? 

	Johnny



David


On 2 April 2016 at 09:45, David Brownlee <abs%netbsd.org@localhost
<mailto:abs%netbsd.org@localhost>> wrote:

    OK I've put the pic/nopic builds up at
    http://sync.absd.org/vax/timing-images/ including two CD images.

    The nopic did not build with X11, abd even so the iso image is
    larger than a CD. If you wante to boot it in simh you'll need to
    pretend its an ra92 or similar rather than a rrd40. Not an issue for
    the tarfiles (also there :)

    I would strongly suggest a base install for the nopic unless you
    have something bigger than an ra92 onto which to install - they are
    *big* :)

    On 30 March 2016 at 13:55, David Brownlee <abs%netbsd.org@localhost
    <mailto:abs%netbsd.org@localhost>> wrote:

        On 30 March 2016 at 13:45, Johnny Billquist <bqt%update.uu.se@localhost
        <mailto:bqt%update.uu.se@localhost>> wrote:
        > On 2016-03-30 14:11, Anders Magnusson wrote:
        >>
        >> Den 2016-03-30 kl. 13:34, skrev David Brownlee:
        >>>
        >>> Conclusions (albeit with simh timings)
        >>> - having makemandb running makes timings (and the machine) pretty much
        >>> useless
        >>> - NOPAM reduced login time by 33%
        >>> - NOPIC reduced login time by 50%
        >>> - NOPIC reduced boot time by 25%, even allowing for fixed times such
        >>> as kernel boot
        >>>
        >> This is actually very strange, since the generated assembler is
        >> basically the same.
        >>
        >> Maybe if it's the dynamic linking itself and not PIC that is causing the
        >> speed penalty?

        My supposition would be that rc.d startup involves a relatively
        large
        number of short lived processes, so any difference in process
        start up
        costs will weight much more heavily. I would expect the
        performance of
        (say) nginx to be much close on static/dynamic

        >> It would be interesting to test this on real iron (Johnny? :-)  to see
        >> the outcome.
        >
        > The 8650 is up and running. Just point me to tarballs... :-)
        >
        > Dynamic linking definitely have costs. All the file opening and symbol
        > resolving... But also, just image activation I seem to remember being an
        > issue.
        >
        > Davids tests are interesting, but unfortunately, having login data samples
        > at 6,4,3 means we have way too low resoltion and too few samples to draw any
        > real conclusions.
        >
        > And since David asked, yes - I also noticed that makemandb now is run by
        > default at boot time. Was a bit surprised by that one myself. :-)

        The makemandb is an issue for other ports (eg: m68k, and lower
        memory
        i386). I think we should assume that running makemandb on boot is
        entirely inappropriate on vax and just disable it manually for now
        while we investigate the static/dynamic.

        The old timing images are at
        http://sync.absd.org/vax/timing-images/,
        but I think it would be appropriate to run off a new set with
        gcc 5.3
        :)

        Let me get started on that and I'll email back when they're ready.

        David






--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol
Home | Main Index | Thread Index | Old Index