peter@sugar.UUCP (Peter da Silva) (11/03/87)
Fort In.c apparently benchmarked the 68020 and the 80386 under Polyforth. The 80386 was consistently faster. Does anyone know the details of the Polyforth inner interpreter for these two machines? I can't get a DTC Forth NEXT in under 2 instructions on the 68000. The 6809 and PDP-11 can both do it in 1. What about the 80386? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are bit gethe
ihm@nrcvax.UUCP (Ian H. Merritt) (11/16/87)
>Fort In.c apparently benchmarked the 68020 and the 80386 under Polyforth. >The 80386 was consistently faster. Does anyone know the details of the >Polyforth inner interpreter for these two machines? I can't get a DTC >Forth NEXT in under 2 instructions on the 68000. The 6809 and PDP-11 can >both do it in 1. What about the 80386? >-- >-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter >-- Disclaimer: These U aren't mere opinions... these are *values*. I have yet to see any published benchmarks between the Motorola and Intel processors that reflect anything other than what the authors set out to 'prove'. Every benchmark I have read in print has either been tampered with by the introduction of bugs in one or the other side to favor one particular view, or depends entirely on the quality of whatever compiler/interpreter is being used in the benchmark test. In this case, I would guess that a close look at the Polyforth implementations on both machines would disclose certain inefficiencies that work out to favor the 386. From such a comparison we can deduce very little about the performance of either machine; only of the Polyforth implementations. I've said it before and I'll say it again: the only way to obtain a true comparison between the machines themselves, the only way to estimate either's potential power is to have experts on each machine carfully choose a suite of benchmark tests that overall favors neither machine, hand-code in assembly language the best possible coding for each benchmark, and run them on full-speed machines (or calculate the timing manually). The issue of the availability of efficient compilers or systems that fully utilize the potential of each machine is relavent but entirely separate from the machine performance comparison. --i
cdshaw@alberta.UUCP (Chris Shaw) (11/20/87)
In article <1289@nrcvax.UUCP> ihm@minnie.UUCP (Ian Merritt) writes: > >I've said it before and I'll say it again: the only way to obtain a >true comparison between the machines themselves, the only way to >estimate either's potential power is to have experts on each machine >carfully choose a suite of benchmark tests that overall favors neither >machine, hand-code in assembly language the best possible coding for >each benchmark, and run them on full-speed machines (or calculate the >timing manually). The issue of the availability of efficient >compilers or systems that fully utilize the potential of each machine >is relavent but entirely separate from the machine performance >comparison. > > --i The only problem with this is that it is a gross handwave. The variables are no longer the compilers but the Assembler coding people. In fact, the variable hasn't really changed at all, since code generation is still the point of contention. Besides, who would use such a benchmark? I suspect that only people evaluating CPU's in order to select one to put in a new product would use such a metric. Given this scenario, there are so many other cost-oriented considerations that mere CPU speed no longer remains a dominant factor. For anyone else, such a benchmark is useless, because the system one uses includes the compilers used to generate code, the memory system, the disks, and so on. I highly doubt that anyone would code a significant application in assembler, simply because the software development and maintenance costs would be astronomical. The only point of an expert-generated assembler benchmark is to win beer in bar bets. -- Chris Shaw cdshaw@alberta University of Alberta CatchPhrase: Bogus as HELL !
root@cca.ucsf.edu (Computer Center) (11/21/87)
In article <1289@nrcvax.UUCP>, ihm@nrcvax.UUCP (Ian H. Merritt) writes:
:
: I have yet to see any published benchmarks between the Motorola and
: Intel processors that reflect anything other than what the authors set
: out to 'prove'.
The quote from E. Rather (Pres. of Forth Inc.)is reported by
Electronics magazine as:
Rather says the results are surprising because, until the tests
were completed, "we all thought the 68020 was faster."
: Every benchmark I have read in print has either been
: tampered with by the introduction of bugs in one or the other side to
: favor one particular view, or depends entirely on the quality of
: whatever compiler/interpreter is being used in the benchmark test.
:
: In this case, I would guess that a close look at the Polyforth
: implementations on both machines would disclose certain inefficiencies
: that work out to favor the 386. From such a comparison we can deduce
: very little about the performance of either machine; only of the
: Polyforth implementations.
:
Are we supposed to take seriously the suggestion the Forth would
not optimize the most critical part of their system for each
processor? Remember that Forth lets you get down to specifying
the actual machine instructions for critical code as was probably
done here so these results presumably give a better measure
of the chip performance than the typical C or Fortran program
which is dominated by compiler quality.
Thos Sumner (thos@cca.ucsf.edu) BITNET: thos@ucsfcca
(The I.G.) (...ucbvax!ucsfcgl!cca.ucsf!thos)
If he says it's "user friendly" watch out; he's a con artist.
#include <disclaimer.std>alan@pdn.UUCP (Alan Lovejoy) (11/23/87)
In article <1087@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Computer Center) writes:
/Are we supposed to take seriously the suggestion the Forth would
/not optimize the most critical part of their system for each
/processor? Remember that Forth lets you get down to specifying
/the actual machine instructions for critical code as was probably
/done here so these results presumably give a better measure
/of the chip performance than the typical C or Fortran program
/which is dominated by compiler quality.
Except that most benchmarks I've seen that were done in hand-coded
assembly show that the the 68020 averages about twice the speed of the
80386 using slow memory, and about 30% faster using fast memory. The
best such benchmark is the one done by Sperry corporation using the
EDN benchmark suite.
There is also the question of the "equivalence" of the bus and memory
systems in which the two processors were tested, and what sort of
memory management hardware (if any) was used with the 68020 (MMU's
can slow it down significantly).
Besides, attempts at "optimization" are not guaranteed to be successful (or
equally successful on all systems).
--alan@pdnalan@pdn.UUCP (Alan Lovejoy) (11/23/87)
In article <601@pembina.UUCP> cdshaw@pembina.UUCP (Chris Shaw) writes: >The only point of an expert-generated assembler benchmark is to win beer in >bar bets. Not true. Your analysis considers the problem statically, but the situation is dynamic. New compilers and other software, and upgrades thereto, are constantly appearing. A hand-optimized assembly benchmark tells you the limit that will be approached by the code generators (human or program) as time passes. --alan@pdn
greg@xios.XIOS.UUCP (Greg Franks) (11/26/87)
# #For anyone else, such a benchmark is useless, because the system one uses #includes the compilers used to generate code, the memory system, the disks, #and so on. I highly doubt that anyone would code a significant application in #assembler, simply because the software development and maintenance costs would #be astronomical. # Au-contrairie: In the *real world* you will find lots of people merrily coding lots of assembler programs for your new deluxe electronic toaster. Telephone switches have lots of assembler code in them. (one that I worked on had a peripheral controller with a mere 256K of assembler using a 68000). Telephone switches generally do not care about disks. Any new fangled gizmo that has any sort of intelligence at all will have a microprocessor. HINT: they aren't running UN*X. -- Greg Franks XIOS Systems Corporation, 1600 Carling Avenue, (613) 725-5411 Ottawa, Ontario, Canada, K1Z 8R8 utzoo!dciem!nrcaer!xios!greg "There's so much to sea in Nova Scotia"