rjtatz@hpuxa.ircc.ohio-state.edu (Robert J. Tatz) (04/14/90)
I don't normally read this news group, but someone suggested I might get
some info. If you could reply to rjtatz@hpuxa.ircc.ohio-state.edu
with suggestions or to tell me what a stupid idea it is. Thanks, Bob
We all know that statistics lie and that benchmarks can be mis-used.
For example, MIPS cannot be used to compare CISC and RISC chips. Due to
different version numbers, quoting dhrystones can be questionable. And
checking out hard drives speeds can be dependent on how optimized or how
full the hard drive is. However, it is also abundantly clear that the
graphical user interface (GUI) is here to stay no matter who is selling
the hardware.
It is very typical for high-end graphics workstations (CAD-CAM, 3-d
modeling) to quote speed for pixels/vectors drawn, polygons filled, etc.
The CPU's involved tend to different in design and speed - the only thing
in common is what's going to the screen in at least comparable resolution.
So why isn't there a benchmark to determine speed of the graphics on
the various hardware platforms currently (or soon to be) available?
One drawback to testing GUI speed is the great variation in the OS
available. So what I propose is the following benchmark. Unix and
X-windows is a standard which is or will be supported on IBM, Mac, Amiga,
Sun, NeXT, etc. A program written in c for X-windows running under Unix
should open a) a window to draw text, b) a window to draw circles or
squares, c) a window to animate a cube, d) a window to ??? . These
windows should then be cycled so the screen needs to be updated. Of
course, all of these operations would be timed. Also, putting menus up
should be automated and timed. Finally, an option would have some CPU
intensive calculation running in the background.
Ideally, the benchmark program would then be run on the top end of
each manufacturer's machine, keeping the resolution and # of colors as
similar as possible and clearly noting the resolution/# of colors used.
This would provide a comparison between manufacturers top of the line,
relatively free of the personal bias we have recently heard so much of.
Of course, if the manufacturer had a brand new machine with a 16Mhz and
a 25Mhz version of the 68030 running Unix, these could be compared to
each other. And if the manufacturer came out with a drop-in 68040 card,
this new high-end machine could be tested. In addition, comparisons
could be made for a single computer on changing the resolution or # of
colors used. The effect of installing a special video card could also
be tested.
Finally, it would be useful if the benchmark program could be ported
to Amiga Workbench, Mac OS, OS/2, NeXT-Step, MS-DOS w/Windows, etc. to
see what these GUI's can do.
No easy task? Ideas, suggestions, volunteers? Can it be shown
that a set of 16 bit, 7.14 Mhz custom graphics chips can make a 25 Mhz
68030 Amiga compete with a 40 Mhz 68030 Mac? I hope we can generate a
little light with this project without all the heat.
If you want to email me -> rjtatz@hpuxa.ircc.ohio-state.edu .
BTW, I have a room full of 24 A1000's at the Ohio State University
Dept. of Chemistry running proprietary chemistry intructional software.
Over the past three years with the machines running 45 hrs./week, I
have put only one monitor and one machine in for repair - not a bad
track record.
Regards,
Bob rjtatz@hpuxa.ircc.ohio-state.edutoddpw@tybalt.caltech.edu (Todd P. Whitesel) (04/14/90)
[ Advance apologies if this is straying from pure 'arch' a bit ] rjtatz@hpuxa.ircc.ohio-state.edu (Robert J. Tatz) writes: > No easy task? Ideas, suggestions, volunteers? Can it be shown >that a set of 16 bit, 7.14 Mhz custom graphics chips can make a 25 Mhz >68030 Amiga compete with a 40 Mhz 68030 Mac? I hope we can generate a >little light with this project without all the heat. As long as you are talking GUI performance, this would be a good lesson to Apple management -- they could have developed a standard graphics coprocessor for both the Apple IIGS and the Macintoshes long before now. Rumor has it they were working on a very nice chip to do sprites and cheap windows (with Apple's interface one hardware-implemented window at a time is enough), and used VRAMs to get maximal blit bandwidth -- but for some inane reason the project was axed. Since most people care more about the GUI response than the actual CPU speed (I can wait for a recalc but drawing windows at least should be fast), this is where the coprocessing hardware is a big win. Apple will not be able to make a feasible 'low cost color Mac' without it, IMHO. Not that a low cost Mac is going to be a reasonable product, mind you -- so far the rumors indicate that it would be a lot cheaper for Apple to finally make the IIGS a respectable machine (far easier than most people realize) and let it be their low cost color 'Mac'. The GS's O/S was designed much better than the Mac's (hindsight, plus some real vision for once) and only needs a piddly 7 mhz to be a joy to use, without any kind of special graphics hardware. Todd Whitesel toddpw @ tybalt.caltech.edu