386 questions

[Heikki Suonsivu]

In article <10208 at steinmetz.steinmetz.ge.com> davidsen at crdos1.UUCP (bill davidsen) writes:
>In article <4219 at ihlpf.ATT.COM> weave at 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 at 16MHz@1w:68010 at 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.