HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/28/90)
All results refer to dhrystone.c as posted with 1.5.10, but with
TIMES defined instead of TIME, and NOENUM and NOSTRUCTASSIGN are NOT
defined.
running it, compiled with the ACK compiler, on an ACK compiled
1.5-System yields
726 Dhrystones,
compiling it with the c68 compiler yields
932 Dhrystones
the same, with a c68-compiled library yields
1019 Dhrystones. (<== was: 926 Dhrystones under ST-1.1)
The same figure comes out when using a c68-compiled system, so the
weak points of the ST-1.1-version are eliminated. BTW, the same binary
that makes 1019 Dhrystones under 1.5 makes only 926 Dhrystones under
an ACK-compiled ST-1.1-System.
C.v.W.F35KER%DHHDESY3.BITNET@cunyvm.cuny.edu (Kerst van Raden) (05/30/90)
> Date: Mon, 28 May 90 07:23:20 GMT > From: Christoph van Wuellen <HBO043%DJUKFA11.BITNET@CUNYVM.CUNY.EDU> > Subject: benchmarking MINIX-ST > > BTW, the same binary > that makes 1019 Dhrystones under 1.5 makes only 926 Dhrystones under > an ACK-compiled ST-1.1-System. > C.v.W. How comes? I thought, dhrystone only measures user mode execution times!? Kerst van Raden F35KER @ DHHDESY3 (.BITNET 8-( )
evans@ditsyda.oz (Bruce.Evans) (05/31/90)
+> From: Christoph van Wuellen <HBO043%DJUKFA11.BITNET@CUNYVM.CUNY.EDU> +> BTW, the same binary +> that makes 1019 Dhrystones under 1.5 makes only 926 Dhrystones under +> an ACK-compiled ST-1.1-System. +> C.v.W. +How comes? I thought, dhrystone only measures user mode execution +times!? 1.1 was spending 10% of its time processing clock interrupts. It spent almost 20% on a 5MHz PC (60 messages * approx. 3 msec per message = 180 msec). This is not much affected by the compiler used on the kernel. -- Bruce Evans evans@ditsyda.syd.dit.csiro.au
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (05/31/90)
Of course, dhrystone measures only user mode execution times, but everything that is done during interupts is charged for the current process. On an otherwise idle system, where only your process runs, every clock tick is charged for you (thus your times(3)-time is wallclock-time), but not only your process, but also the clock interrupt handler consumes CPU cycles. C.v.w.
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (06/01/90)
I must disagree with bruce Evans on his statement that the compiler used
to compile the ST-1.1 Kernel did not affect the percentage of the total
time spent during clock interrupts: I found that my compiler did it much
better because:
1.) It generates much better code for assignment of short structures
(it is evident that this is important on a message-passing system)
( The compiler generates loops of move.l (an)+,(am)+ and it unrolls
this loop for short structures like messages)
2.) The compiler uses the 68000 short*short=long multiply instructions
for pointer additions instead of calling a (bad) library function
(this is an enourmous gain).
The weakness of the ACK compiler with respect to these points has been
circumvented by other tricks in ST-1.5.
C.v.W.