Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!cs.utexas.edu!rice!sun-spots-request
From: khb@sun.com
Newsgroups: comp.sys.sun
Subject: Re: Setting up a Sparcstation lab.
Keywords: Miscellaneous
Message-ID: <3896@brazos.Rice.edu>
Date: 8 Dec 89 02:30:33 GMT
Sender: news@rice.edu
Organization: Sun-Spots
Lines: 52
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n166, Replies: v8n192 v8n194 v8n198 v8n206 v8n211 v8n217
X-Sun-Spots-Digest: Volume 8, Issue 223, message 1 of 14

In article <3269@brazos.Rice.edu> it is written:
>X-Sun-Spots-Digest: Volume 8, Issue 206, message 4 of 15
>
>>It seems to me that 12 is a bad compromise.  Either you limp along with 8
>>or you go whole-hog for 16.  The German Sun Users' group electronic
>>mailing list had a discussion about xview News/X and memory; 12M wasn't
>>quite enough.  The consensus was that future SunOS releases are going to
>>want 16M in a compiling environment and at least 12 MIPS.
>
>Did this (and similar articles) strike anyone like it hit me?  I started
>using Sun workstations with a 2/120.  I could run compiles with 4 or 5
>windows open, plus 2 more processes off the asynch. comm.  ports, and it
>only had 2 (two) Mb of memory.  Sure, it had to do more than a little
>swapping, but it did work.

    [stuff deleted about SunOS 4.0.x's use of memory]

You are confusing a bunch of issues (which is what most of us do when
getting hot and bothered about these topics). The following are all
inter-related: 

1)  users expect _much_ better response times now. If you set up a sun2
and a sun4/60 next to each other, one is surprised at how much slower the
sun2 really is. Back when the sun2 was king, that kind of response was
good (sunview, etc.) .... one remembers being happy, NOT how many
milliseconds a window open took.

2)  users expect much more functionality. Scalable fonts ? outline fonts ?
etc.

3)  users expect/demand much better optimizers. optimization is good for
about 30% speedup on a sun3 (less on a sun2, if memory serves). Often good
for a 4x speedup on large f77 applications .... this does involve more
work for the optimzer, more memory requirements etc. Not enough users
employ prof/gprof/tcov to limit the modules which get the -O4 treatment :>

4)  The window system is a MUCH bigger issue than the OS. In fact, the
debris of sunview are a large part of the bloat. Someday xview will
obviate kernal support for sunview. Alas, that day isn't yesterday. :>

5)  Some of the TOOLs are the real pigs. Since sun does not _yet_ ship
good user-level tools to watch who consumes what memory when, this is
hidden.

6)  It is not clear to me that the Germans are right. I used to have have
an 8mb machine and I was quite happy with its performance. I had to give
that up, now I have a slower CPU, but more RAM (and more local disk, and
more noise, and a high res monitor). 

I speak for myself, not my lords and masters of the payroll. Also, I'm not
part of the windows nor the OS teams ... so I'm liable to be wronger than
usual :>