Post by Johnny BillquistPost by Dave McGuireLet's keep this port alive!
You are going to be soooo disappointed. Trying to just build a kernel on
the 11/785 will take an estimated two weeks. Really.
It's not really doable on the 8650 any more either. :-(
Probably much longer. Generating NetBSD 1.2 release took two weeks (on an
780). 11 days to compile the system and 2 days to gzip the tarballs.
Right, so, this points out something which seems obvious to me but perhaps
it's not: *Of course* it takes longer, because the workload is not at all
the same.
When we ran 4.3BSD on our VAXen there was no "gzip". There was barely
a GCC compiler at all, and it did not perform most of the optimizations
it performs today, *particularly* not the ones that consume tens or
hundreds of megabytes of memory per source file. I could go on.
The systems seemed faster in large part because we were not asking them
to do some of the very expensive tasks we ask them to do now.
In around 1991 I was responsible for a 11/750, very much on its last
legs, which handled news and email for a small academic campus, plus
some interactive login (though this had largely been replaced by labs
full of Macintoshes, and one lab of Sun workstations).
News volumes increased dramaticaly and though we had the space to store them,
we got to where we could not transfer a day's worth of Usenet news in a
day with the best modems we could buy.
So, we switched from compress(1) to squeeze(1) which implemented Miller-Wegman
compression. Now, since we were transmitting and receiving news all day long,
we could not handle the CPU load from squeeze(1) while keeping up with the TTY
data!
I did not complain that 4.3BSD had gotten slower and was a bloated pig; I
accepted that we were asking the machine to do more than it had been doing
before and that I needed to find a way to speed it up. And that there was a
going to be a practical limit to this process, which I would hit presently.
The next step was Taylor UUCP, to reduce the workload of actually moving the
data. We also bought new modems, reorganized our UUCP and Usenet feed
structure so we took different groups from different sources. Of course
this increased the workload on the kernel -- now we had to sustain high
data rates on several serial lines at the same time.
We began to look for replacement hardware, though our budget was crushingly
tight (buying four new, faster modems didn't help with that any). But while
we looked we were clearly near the tipping point. I spent my free time for
a week slicing and dicing the kernel and crucial application software into
parts that looked safe to compile with GCC -- 1.45 at the time -- and parts
that clearly did not.
Over spring break that year I rebuilt everything I could with GCC. We're
not talking about a full software distribution, and we're not talking
about GCC 4.8 with its propensity to use hundreds of megs of RAM to do
fancy new optimizations. My clear memory of this is that the kernel,
the userland binaries germane to UUCP and Usenet, and a few key libraries
(most of libc not among them) took most of the week with the compiler
running full-time. I recall very well that I went to bed one night
after launching a build of Taylor UUCP and that it had just finished
in the morning -- at least 6 hours later. Some of this was clearly
because the machine was still moving data; but not all of it (back then
Usenet volumes used to drop dramatically when colleges were on break).
Of course, I blamed 4.3BSD, because the increased workload was clearly the
operating system's fault. I also blamed GCC for taking so long to compile
the software I'd decided to try to speed up with the fancy new compiler.
That was the rational thing to do, right?
Eventualy we found a failed hedge fund that was selling off a pile
of 4/330s and picked on up as a replacement Usenet/UUCP box. It held
us another 2 years or so...
Thor