Subject: Re: Benchmarking MOL
From: Samuel Rydh (samuel@ibrium.se)
Date: Fri May 11 2001 - 18:31:17 MDT
On Thu, May 10, 2001 at 09:47:59PM -0400, Quentin Mason wrote:
>
>
> > You don't want to even see the graphics test. If anybody wants, I can send
> > them the macbench and my testing files. WHen I get closer to building the
> > web site, I'll ask for people to submit tests to me...
> >
> > I was under the impression that the linux disk handling would be better
> > (which it is), but I really was suprised by the processor efficiency.
> > Is this all overhead? Mabye not an appropriate area for this discussion.
There is one *MAJOR* source of error to benchmark results - the measurement of
elapsed time. MOL/MacOS might not run with correctly calibrated timers.
This affects in particular the oldworld setting (MacOS < 8.6).
The timer calibration is better in the newworld setting, but
probably not perfect (and the frequencies are somewhat dependent upon
what MOL/MacOS does).
The best method to really compare performance is doing a specific task,
measuring the elapsed time with an old fashioned watch. Nevertheless,
I've run MacBench 5 on the following configuration:
G3/350, 192 MB RAM, MacOS 9.0.4.
Linux kernel 2.4.4-pre7, MOL in full-screen mode.
The results:
Processor Floating Point Disk
===========================================
MacOS 1148 1152 2314
MOL 1008 1069 2303(*)
...playing around with the VBL frequency:
MOL 1028 1078
MOL 1040 1082
MOL 1066 1101
(*) disk benchmarks in particular should never be
trusted.
Graphics test MOL MacOS MacOS
(kilopixels/sec) unaccel. accel.
==================================================
EraseArc 16662 9857 56411
FillArc 16826 9881 58056
FrameArc 548 552 488
InvertArc 45203 1709 3238
PaintArc 57134 9888 17326
CopyBits, srcCopy 18831 19923 19567
CopyBits, srcOr 2726 1631 19520
CopyBits, srcBic 2725 1631 19533
CopyBits, srcXor 2729 1631 19523
CopyBits, notSrcCopy 2728 1631 19503
CopyBits, notSrcOr 2726 1631 19479
CopyBits, notSrcBic 2730 1632 19513
CopyBits, notSrcXor 2728 1631 19503
CopyBits, addOver 2729 1598 1600
CopyBits, addPin 2707 1511 1512
CopyBits, subOver 2726 1598 1600
CopyBits, subPin 2708 1510 1512
CopyBits, adMax 2728 1552 1553
CopyBits, adMin 2727 1551 1552
CopyBits, blend 2726 1598 1600
CopyBits, transparent 2730 1604 19603
CopyBits, hilite 2725 1576 1577
CopyBits, copyMask 1877 1208 1208
CopyBits, copyDeepMask 1832 1208 1207
DrawPicture 4776 4867 5220
DrawPicture scaled 5285 4397 4431
ScrollRect 10339 2155 68321
LineTo (horizontal) 8509 9466 10578
LineTo (vertical) 6600 6781 6666
LineTo (diagonal) 7785 7389 6970
EraseOval 19605 10640 130042
FillOval 19626 10642 130984
FrameOval 1874 1832 1295
InvertOval 3591 1743 71901
PaintOval 19974 10653 130669
ErasePoly 16669 10102 43028
FillPoly 16695 10076 42566
FramePoly 2798 2739 1427
InvertPoly 2832 1700 36684
PaintPoly 17879 10205 44324
EraseRect 20554 10871 167674
FillRect 20574 11245 168301
FrameRect 9141 8003 6743
InvertRect 3530 1754 80897
PaintRect 20654 21371 168858
EraseRgn 20644 10868 167588
FillRgn 20637 11244 168084
FrameRgn 2670 4217 5551
InvertRgn 3532 1754 80853
PaintRgn 20647 21369 168687
EraseRoundRect 20362 10860 160896
FillRoundRect 20450 10858 160460
FrameRoundRect 6940 5749 3262
InvertRoundRect 3526 1752 78611
PaintRoundRect 20620 10865 161711
DrawChar 281 303 307
DrawString 2238 2254 2261
DrawText 2244 2259 2267
Note that MOL in general beats MacOS if video accelerator
extensions are disabled. The reason for this is that MOL
uses write-trough caching for frame-buffer access (poor man's
video accelerator) while MacOS disables the cache for VRAM.
I also did some real-life tests, measuring elapsed time by hand:
Booting MacOS 9.0.4
===================
MOL: 36s (38s)
MacOS: 38s (68s)
The measurements were done after a real reboot (to ensure
the disk-cache was empty). The first value is the time
difference between the appearance of the MacOS splash
screen and the appearance of the control strip in Finder.
The value within the parenthesis is the complete startup time
(measured from the 'startmol' command and the power on
press, respectively). MacOS takes longer here due to
- OpenFirmware initialization (Forth is slooooow)
- The forth driver for my AEC62xx card (an Ultra 66
IDE controller) is unusually slow.
AppleTalk was enabled in both cases.
Other tests MOL MacOS
====================================================
Compiling the video driver 10s 10s
PhtoShop: Artistic Col. Pencil 5s 5s
...tests that run longer are necessay...
Copying 6264 files (214 MB)... MOL MacOS
====================================================
between volumes 125s 85s
within the same volume 125s 66s
It should be noted that the linux driver for the AEC64xx card
is not as fast as it should be (hdparm reports 18 MB/s in linux
while bench tests in Mac OS give significantly higher
transfer rates). But... I think the MOL block driver could
be improved - in particular support for asynchronous transfer
is lacking.
/Samuel
----------------------------------------------------------
E-mail <samuel@ibrium.se> WWW: <http://www.ibrium.se>
Phone/fax: (home) +46 8 4418431, (work) +46 8 7908470
----------------------------------------------------------
This archive was generated by hypermail 2a24 : Fri May 11 2001 - 17:38:48 MDT