Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!ritcv!rocksvax!martyl
From: mar...@rocksvax.UUCP (Marty Leisner)
Newsgroups: comp.os.minix
Subject: minix C compiler performance
Message-ID: <1131@rocksvax.UUCP>
Date: Sat, 30-May-87 12:01:02 EDT
Article-I.D.: rocksvax.1131
Posted: Sat May 30 12:01:02 1987
Date-Received: Mon, 1-Jun-87 05:44:07 EDT
Organization: Xerox: Henrietta, NY
Lines: 34
Well, I finally got my copy of Minix running on my harddisk on my 10 Mhz PC
AT.
I felt it took an awfully long time to recompile/link the kernel, so once
I was up on a harddisk, I ran dhrystone to get an idea of performance
(yeah, it ain't perfect, but it is a compute intensive benchmark).
Under Minix, dhrystone (at least the copy I got from netlib) turned about
250 dhrystones/second. Under Aztec C/MS-DOS on the same hardware, dhrystone
turned 1200+ dhrystones/second.
A few questions about the Minix C compiler and the distribution disks:
1) which compiler was the AT kernel/utilities compiled with?
When I recompiled the kernel, the sizes of the linked files
didn't agree with the distribution versions.
2) While running dhrystone under the time utility, it reported
99%+ time was user (something like 3:00 user, :01 system, 3:02
real -- there wasn't anything else running at the time).
This would indicate dhrystone did as intended -- benchmark the
C compiler and not minix itself.
Are there any plans to improve the Minix C compiler? Or am I doing something
wrong? In the Minix book, Andy Tanenbaum asserts clean code is more
important than highly optimized code -- and I agree with this premise and
feel Minix looks (from a browsing level) like a very clean software project.
But a factor of 5 in C compiler performance is somewhat unacceptable.
Any comments out there?
marty leisner
xerox corp.
leisner.h...@xerox.com
mar...@rocksvax.uucp
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!botter!ast
From: a...@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: minix C compiler performance
Message-ID: <1192@botter.cs.vu.nl>
Date: Sun, 31-May-87 15:25:43 EDT
Article-I.D.: botter.1192
Posted: Sun May 31 15:25:43 1987
Date-Received: Tue, 2-Jun-87 02:15:34 EDT
References: <1131@rocksvax.UUCP>
Reply-To: a...@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 58
Marty Leisner recently posted a note saying the MINIX C compiler ran
20% the speed of an MS-DOS compiler. This figure disagrees with an
earlier posting about dhrystones, and also disagrees with my comparisons
with other compilers. The MINIX binaries were made with the PC-IX compiler,
and these are typically about 15% smaller and faster than the MINIX ones.
I think the dhrystone tests must use some feature that the MINIX compiler
is poor at (like it doesn't use registers), but I can't imagine that you
will get a factor of five difference across the board with real programs.
It would be interesting to see measurements of real programs (e.g.,
commands/*.c) with MINIX and other compilers.
The main problem with the C compiler is that it is completely table driven,
and the code quality depends on how much work the table writer put into
optimization etc. This particular table writer, who shall remain nameless
here, did not especially like the 8088 architecture, and wanted to get the
job done as fast as he could. As soon as the compiler worked correctly, and
passed a large battery of compiler test programs that are part of ACK, he
stopped work. The only way to improve it is for someone who has ACK to
go back to his tables and optimize them. Our 68020 compiler, for example,
which uses the same software but has a much better driving table, produces
code that is better than Motorola's own compiler.
The table improvement can't be done from the "source" you can get from
UniPress/Transmediair, because it requires running the compiler-compiler system,
and the C compiler "source" for MINIX is the compiler, not the compiler-compiler
(which runs on VAXes and SUNs with 30 or 40 megabytes of free disk space,
and definitely not on PCs). Since universities can get the complete ACK
source for $995 from UniPress or Transmediair, perhaps some professor who
is interested in compilers can get it and have a student work on improving
the quality as a Master's thesis. Code optimization on the 8088 ought to
provide plenty of food for thought for the student. It obviously can be done,
but requires some thinking.
Another thing that might be worthwhile would be for someone who knows the
8088 assembly language fairly well to just look at the assembly code of a
few simple programs, and see if there are any obvious places where the
compiler messes up, other than not using registers. If there are, there
might be a possibility of making another optimizer that reads in the
assembly code and outputs an optimized version of same. The current
optimizer, /lib/opt, works on the intermediate code only, and does not
include any 8088-specific optimizations.
I am starting to think about the MINIX 1.2 distribution. It will probably
mostly contain bugs fixes and some of the new programs that have been
posted here. I will describe it at great length later, but if you have
been collecting bug reports and have been waiting until you get 100 of them
before posting, now might be a good time to post them anyway. Likewise,
if you have any useful programs that you intended to post but haven't yet,
now is a good time.
To repeat, I will get back to this subject at length later, and will post
all the differences between 1.2 and 1.1 for the benefit of people with 1.1.
The Atari version, incidentally, is coming along, but is still not finished,
and will not be in 1.2.
Andy Tanenbaum (a...@cs.vu.nl)
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!clyde!cbosgd!ihnp4!occrsh!uokmax!rmtodd
From: rmt...@uokmax.UUCP (Richard Michael Todd)
Newsgroups: comp.os.minix
Subject: Re: minix C compiler performance
Message-ID: <582@uokmax.UUCP>
Date: Sun, 31-May-87 23:44:13 EDT
Article-I.D.: uokmax.582
Posted: Sun May 31 23:44:13 1987
Date-Received: Tue, 2-Jun-87 07:10:52 EDT
References: <1131@rocksvax.UUCP>
Organization: University of Oklahoma, Norman, OK
Lines: 40
Summary: main difference may be register variables
In article <1...@rocksvax.UUCP>, mar...@rocksvax.UUCP (Marty Leisner) writes:
> Under Minix, dhrystone (at least the copy I got from netlib) turned about
> 250 dhrystones/second. Under Aztec C/MS-DOS on the same hardware, dhrystone
> turned 1200+ dhrystones/second.
Well, what little testing I've done doesn't show that drastic a difference
between the two compilers, but there is a difference in execution times.
I'm not familiar with the Dhrystone benchmark--does it use register variables
heavily? You see, the Minix compiler apparently ignores register
declarations, whereas Aztec C (I have the developer's system, v3.40a), seems
to handle up to two int-sized register vars, one in si, one in di. It makes
a good bit of difference. I just recently did a slightly modified sieve,
(I upped the number of iterations to 100 from 10) compiling both with and
without register declarations, and linking with the Minix library and
running them through dos2out, so that the two Aztec-compiled versions
(with & without register declarations) would run under Minix. This
ensures that we aren't accidentally including any differences arising
from the different operating environments (DOS and Minix). Timing them
and the sieve compiled under Minix's compiler gave these results
(all results are user time given by /usr/bin/time, CPU is 8088 at 4.77MHz)
Aztec cc with register declarations: 96.5 sec.
Aztec cc without register declarations: 132.4 sec.
Minix cc 141.0 sec.
You can see that without register declarations, Aztec's code gives
performance slightly better than the Minix cc. The register variables
make a huge difference.
Of course, the sieve is a rather limited benchmark; other benchmarks like
Dhrystone will get different improvements by addition/subtraction of
register variables.
> A few questions about the Minix C compiler and the distribution disks:
> 1) which compiler was the AT kernel/utilities compiled with?
> When I recompiled the kernel, the sizes of the linked files
> didn't agree with the distribution versions.
Apparently it was the PC/IX compiler. The Minix compiler produces somewhat
larger code. From my limited experimentation with Aztec C -- recompiling
the shell and fs -- the code size produced is roughly comparable to the
PC/IX output.
--------------------------------------------------------------------------
Richard Todd
USSnail:820 Annie Court,Norman OK 73069
UUCP: {allegra!cbosgd|ihnp4}!okstate!uokmax!rmtodd
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!amdcad!sun!texsun!smu!mcomp!authorplaceholder
From: w...@mcomp.UUCP
Newsgroups: comp.os.minix
Subject: Re: minix C compiler performance
Message-ID: <222500026@mcomp>
Date: Mon, 1-Jun-87 09:17:00 EDT
Article-I.D.: mcomp.222500026
Posted: Mon Jun 1 09:17:00 1987
Date-Received: Fri, 12-Jun-87 01:28:27 EDT
References: <1131@rocksvax.UUCP>
Lines: 31
Nf-ID: #R:rocksvax.UUCP:-113100:mcomp:222500026:000:1555
Nf-From: mcomp.UUCP!wnp Jun 1 08:17:00 1987
rocksvax.UUCP!martyl (Marty Leisner) writes:
> ...
> I felt it took an awfully long time to recompile/link the kernel, so once
> I was up on a harddisk, I ran dhrystone to get an idea of performance
> (yeah, it ain't perfect, but it is a compute intensive benchmark).
>
> Under Minix, dhrystone (at least the copy I got from netlib) turned about
> 250 dhrystones/second. Under Aztec C/MS-DOS on the same hardware, dhrystone
> turned 1200+ dhrystones/second.
> ... In the Minix book, Andy Tanenbaum asserts clean code is more
> important than highly optimized code -- and I agree with this premise and
> feel Minix looks (from a browsing level) like a very clean software project.
> But a factor of 5 in C compiler performance is somewhat unacceptable.
In the Minix book AST says that the compiler is the "Amsterdam Compiler Kit"
C compiler, "which was shoehorned onto the 8088 with some loss in performance".
I don't know which machine the ACK compiler was originally written for.
I guess it's up to us, the users, to come up with a better compiler. Has anyone
inquired yet how much the compiler sources would cost?
> 1) which compiler was the AT kernel/utilities compiled with?
> When I recompiled the kernel, the sizes of the linked files
> didn't agree with the distribution versions.
I understand that the MINIX distribution was compiler with the PC/IX compiler.
-----------------------------------------------------
Wolf N. Paul, 290 Dogwood, Plano, Tx. 75075
UUCP: ihnp4!convex!mcomp!wnp
Phone: (214) 578-8023 W.U.ESL: 6283-2882
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!ur-tut!tfra
From: t...@ur-tut.UUCP (Tom Frauenhofer)
Newsgroups: comp.os.minix
Subject: Re: minix C compiler performance
Message-ID: <1413@ur-tut.UUCP>
Date: Mon, 1-Jun-87 15:30:22 EDT
Article-I.D.: ur-tut.1413
Posted: Mon Jun 1 15:30:22 1987
Date-Received: Wed, 3-Jun-87 01:36:01 EDT
References: <1131@rocksvax.UUCP> <582@uokmax.UUCP>
Reply-To: t...@tut.cc.rochester.edu.UUCP (Tom Frauenhofer)
Organization: Univ. of Rochester Computing Center
Lines: 11
[Et tu, line-eater?]
I've run dhrystone using both the Aztec and Microsoft C compilers under
"good ole" (:-) MS-Dos. You can compile it with flags for either register or
no register execution (also with direct structure assignments as well as
memcpy's). Aztec C was about twice as fast as Microsoft during execution
of the .EXE's generated (in fact, the Aztec C LARGE memory model was about
1 1/2 times as fast as the Microsoft SMALL model!). Either Aztec has done
something incredibly right with their compiler or the dhrystone benchmark
is written in such a way as to "favor" Aztec's compiler (a longshot
considering how the benchmark evolved).
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!vrdxhq!bms-at!stuart
From: stu...@bms-at.UUCP (Stuart D. Gathman)
Newsgroups: comp.os.minix
Subject: Re: minix C compiler performance
Message-ID: <404@bms-at.UUCP>
Date: Mon, 1-Jun-87 22:12:29 EDT
Article-I.D.: bms-at.404
Posted: Mon Jun 1 22:12:29 1987
Date-Received: Wed, 3-Jun-87 04:12:29 EDT
References: <1131@rocksvax.UUCP> <1192@botter.cs.vu.nl>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 25
Summary: My complaint is different
I find the generated code quality of the MINIX compiler to be acceptable.
What is not acceptable is the amount of time it takes to compile.
I literally do the following while trying to fix fsck:
a) plan changes and edit
b) start compile
c) prepare and eat dinner
d) check to see if it's done yet
This is with a hard disk! I goes twice as fast on my diskette only
Toshiba 1100+, so I have been using that instead. But it is still
a major snack break.
I bought an MS-DOS compiler from aztec a while back that runs in small model
(and generates small model). It is very fast at compiles (compiles fsck in
a few minutes). The code quality is slightly better than MINIX.
I wish one of these companies (Borland especially) would sell a fast compiler
for MINIX.
P.S. asld seems to be reasonably fast.
--
Stuart D. Gathman <stu...@bms-at.uucp>
<..!seismo!dgis!bms-at!stuart>