Xref: utzoo comp.unix.xenix:1904 comp.sys.ibm.pc:14281
Path: utzoo!mnetor!uunet!mcvax!enea!tut!santra!hsu
From: hsu@santra.UUCP (Heikki Suonsivu)
Newsgroups: comp.unix.xenix,comp.sys.ibm.pc
Subject: Re: 386 questions
Message-ID: <11764@santra.UUCP>
Date: 7 Apr 88 16:23:44 GMT
References: <4219@ihlpf.ATT.COM> <10208@steinmetz.steinmetz.ge.com>
Reply-To: hsu@santra.UUCP (Heikki Suonsivu)
Organization: Helsinki University of Technology, Finland
Lines: 43
Keywords: 386 unix uport
Summary: Uport 386 is less buggy than V/AT

In article <10208@steinmetz.steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>In article <4219@ihlpf.ATT.COM> weave@ihlpf.ATT.COM (Weaver) writes:
>| -What is an adequate configuration?  Interactive Systems recommends
>| >= 4 M of ram and >= 40 M hard disk.  Are their recommendations valid?
>
>  I certainly wouldn't go any smaller than that.

I was running microport in 1.6 M or ram. It worked but was painfully
slow. Now I have 3.6 M and it still feels slow when doing lots of
compilations on the background. Bottleneck does seem to be hard disk,
not CPU or memory.  Comparing to my old convergent miniframe, speedup
is not much, and after two compilations in both machines miniframe
with one meg of memory (swap, swap) feels a bit nicer to use, it has
better response time, swapped out emacs comes back quicker, and so on,
though timing compilations gives worse results. I agree with both
recommendations, and there is still more speedup available with more
memory and faster disks.

>problems. I evaluated the IS C compiler for a business, and my opinion
>is that it's a real piece of... NO! I am trying not to do flames, just

I have compiled gnu emacs, some public domain stuff floating around
and few hundred kb of my own source form microport without any
problems, I was surprised as I expected much worse as an owner of
V/AT. 

I had some funny things happening when I had lots of stuff in memory,
probably I run out of swap as I had gnuemacs in all windows, two
compilations and lint going on, and killing other emacses cured the
problem (telling me out of memory could be nicer instead of syntax
error in the end of all files or /bin/as exiting with random values,
though). *= problem with chars which is documented in the manuals
occured once when compiling gnu emacs (etags) and fns.c compiled with
-O made emacs to core dump when called without parameters. No other
problems in cc has occured yet. My own code is quite portable as I
have to make it run on PCs also.

cc is not specially fast, it beats miniframe 3:1 but that's not too
well for 3.6M:1M and 80386@16MHz@1w:68010@10MHz@0w, uport has more
buffer memory than miniframe core in total !-) (hard disks have same
size and speed). This may be because of disk io, olivetti probably
thought that people would be using a mess dos anyway so why bother
with fast hard disk io.