Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!thumper!ulysses!andante!mit-eddie!bbn!rochester!udel!mmdf
From: mmdf@udel.UUCP
Newsgroups: comp.os.minix
Subject: Minix C compiler (again)
Message-ID: <2855@louie.udel.EDU>
Date: 2 Jun 88 21:45:55 GMT
Sender: mmdf@udel.EDU
Lines: 43
Posted: Thu Jun  2 17:45:55 1988

According to ast:
No concessions are being made to MS-DOS or any of its compilers. 
 A number of people have said that the MINIX
C compiler is slow.  Since I don't have (or want) any MS-DOS compiler, I
can't make a comparison, but I did run the following timing test.  I removed
all the .s files from fs and typed: time make.  The 20 compilations plus
the link took 5:57 real time on my Z-248, which has 1.5 MB RAM and an ST-225
hard disk (70 msec access time).  It seems to me that this isn't so awful.
Obviously a PC will be slower, but that should hold proportionally for all
compilers.


I have a copy of Minix I purchased right after the textbook came out.  In order
to get it to run on my hard disk (I use genuwine PC-ATs) I had to start
recompiling Minix out of the box.  The performance of the C compiler was
horrendous.  To make the kernel was something which seemed I recall took on the
order over 1/2 hour.  While the system was running on floppy disks, it didn't
appear to be I/O bound on floppy disks.  Compiling things like printf("hello
world\n") took noticable amounts of time (on the order of a minute).  Still does
with my distribution C compiler.  Which is why I stopped using the Minix C
compiler.  Which is why I'm (somewhat) anxiously looking for other solutions to
native compiling on Minix (gcc? small-c?).  

Andy reports make fs takes 5:57.  On my 8Mhz AT with Aztec, it takes a shade
under 5 minutes.    5:57 is more than acceptable.  What I don't understand is
why my Minix C compiler out of the box is so bad.  I may look at the problem
some more -- maybe one of the sizes is wrong so one of the programs is doing
byte by byte I/O (instead of buffered).  Anyone out there have any answers?  I
may start timing each pass and see what's going on my system.  HELP!!

BTW -- At the moment, I'm finding the dreaded Ms/Dos far pointers most useful.
Instead of the S/D/T segments, I'm going to start having kernel/fs/mm handle 32
bit pointers and map in user space before operating on it.  This will lead to
the ability to run more complicated memory models (specifically 1 64K code
segment/1 64K initialized data/1 64K stack/N 64K heap segments for moderate N).
Anyone else doing this?
  
marty
ARPA:	leisner.henr@xerox.com
GV:  leisner.henr
NS:  martin leisner:henr801c:xerox
UUCP:	nsc!nscimg!amps!marty