geoff@utstat.uucp (Geoff Collyer) (08/09/89)
We realise that C inews is slow and have some ideas about how to speed it up. One important property of inews as a shell script is that it should in general be easier to modify to suit local policies than equivalent C code would be. C inews has become large and tricky enough, in part from trying to cope with different Unixes, that I am considering making some of its components C programs, where those components are generally useful and don't imply much about local policy. Richard Todd: > I don't have any good benchmarks on C News vs B News processing of > incoming batches, but it seems to take roughly the same amount of time > to unpack comparably sized batches of news on servalan and on uokmax (a > Multimax running B2.11 News under BSD4.2). If B news doesn't take at least ten times as much elapsed and CPU time as C news to process identical input batches on the same machine, after subtracting uncompress or bdecode or uudecode time, then something is seriously wrong, possibly with your C news configuration. Given the vast amount of disk i/o performed by B rnews, it just isn't possible for B news and properly-configured C news to be even close in running times (if it were, we would still be running B news!). However, posting 300 separate cancellations via inews isn't sensible, under B or C news. The way to cope with 300 cancellations is to generate the articles mechanically as one batch and feed it to relaynews. About the only non-trivial thing inews does it to add a unique Message-ID:, and that may be worth breaking out and reimplementing in C. It still amazes me that people use inews directly at all. > Amazing what you can learn just by reading the documentation :-). Indeed. If we could only get people to read it *before* installing, we would get a lot less mail. ``... users of a tool are willing to meet you halfway; if you do ninety percent of the job, they will be ecstatic.'' - Software Tools, p.136. Please note that we view this as a requirement upon users of our software, not merely an observation. :-) -- Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu
rmtodd@servalan.uucp (Richard Todd) (08/10/89)
In article <1989Aug9.042147.10335@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes: >Richard Todd: >> I don't have any good benchmarks on C News vs B News processing of >> incoming batches, but it seems to take roughly the same amount of time >> to unpack comparably sized batches of news on servalan and on uokmax (a >> Multimax running B2.11 News under BSD4.2). > >If B news doesn't take at least ten times as much elapsed and CPU time >as C news to process identical input batches on the same machine, after >subtracting uncompress or bdecode or uudecode time, then something is >seriously wrong, possibly with your C news configuration. Given the >vast amount of disk i/o performed by B rnews, it just isn't possible >for B news and properly-configured C news to be even close in running >times (if it were, we would still be running B news!). Well, the machines I looked at are *not* the same; perhaps I should have been more clear about this. Uokmax (the B News machine) is a BSD4.2 machine, whereas servalan (the C News machine) is SVR2, meaning it has the stock braindead System V filesystem, and the stock 80Meg drive Apple supplies is not the world's fastest either. (Complaints about the mediocre I/O performance of Apple's Unix are fairly common on comp.unix.aux). From looking at some results of the Musbus benchmarks suite, it looks like uokmax has at least a 4 to 1 advantage over servalan as far as disk I/O goes. (One might also note that servalan does *not* run the replacement stdio library routines provided with C News; as I pointed out some time back, said replacement routines don't work properly under A/UX.) Anyway, given the fairly hefty advantages the B News machine had on its side in this comparison, I'm satisfied in the performance of C News. The point of my original article was not to give a rigorous comparison, but merely to point out that C News had reasonable performance under normal use (unpacking incoming batches), and that the slow performance of the 300 separate inews invocations is not representative of C News as a whole. Anyone out there done any more rigorous tests of C News vs B News performance? -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp Motorola Skates On Intel's Head!
geoff@utstat.uucp (Geoff Collyer) (08/11/89)
> Anyone out there done any more rigorous tests of C News vs B News performance?
Have you seen "News Need Not Be Slow", Geoff Collyer and Henry Spencer,
Proc. Winter Usenix Conf. Washington 1987, pp. 181-190? Running the
same ~300k batch into B 2.10.1 news (B 2.11 is ~5% faster) and into a
pre-alpha C news on the same VAX 750 running 4.2BSD, C news took ~5%
the elapsed and CPU times of B news.
One aspect of those timings that we haven't talked much about is that
the decreased elapsed time reflects a huge decrease in the amount of
disk i/o done by C news as compared to B news. The single biggest
improvement we noticed in the early days was not that we had lots of
spare cycles (a 750 hasn't got many to start with) nor that incoming
news was being processed quickly, but rather that our machines no
longer suffered the degradation of interactive response which is
characteristic of B news unbatching and processing incoming news. In
our B news days, we would feel a machine suddenly get very sluggish and
within a few seconds we would recognise the familiar pattern of slow
response from the disks and think "ah, incoming news".
--
Geoff Collyer utzoo!utstat!geoff, geoff@utstat.toronto.edu