22 Dec
2001
22 Dec
'01
8:22 a.m.
In a message dated 12/22/01 Chris Leyson writes:
> How about a straight insertion bubble sort ? A
completely useless task but
it
> does take a defined number of data moves and
compare operations. The array
> to be sorted could be say, 16-bit signed integer, 1k words long and in
reverse
> order. (That should take a while for a 6502 to
sort out).
In a reply dated 12/22/01 Richard Erlacher writes
Yes, maybe something of that sort would be
appropriate. Testing it on
8-bit,
and then 16-bit quantities might be just the thing for
testing the relative
ability, in spite of architectural differences, of handling longer data.
I'd
suggest that larger records might be more appropriate,
i.e. 32-byte records,
etc.
OK 8-bit and 16-bit data is appropriate but would require separate algorithms.
As for record length I would suggest at least 1k (1024) entries. (Eliminates
base page cheating)
BTW, when I was in college, which I realize was some
time ago, but, back
then,
Bubble Sort and Insertion Sort were two different
algorithms ... I don't
remember the differences, but will check my old texts, though they're in
Sanskrit ...
Apologies, that should have read insertion sort OR bubble sort. Bubble sort
runs through the array comparing adjacent values and swaps them whereas
insertion sort moves an array member until it's in the right place. In terms
of
performance they are both slow algoritms.
Here is the code from Numerical Recipies for an insertion sort (Fortran and C)
Sorts an array arr(1:n) into ascending numerical order, by straight insertion.
n is input; arr() is replaced on output by its sorted rearrangement.
integer n
real arr(n)
integer i,j
real a
do j=2,n
a=arr(j)
do i=j-1,1,-1
if (arr(i).le.a) goto 10
arr(i+1)=arr(i)
end do
i=0
10 arr(i+1)=a
end do
{
int i,j;
float a;
for (j=2;j<=n;j++) {
a=arr[j];
i=j-1;
while (i>0 && arr[i] > a );
arr[i+1] = arr[i];
i--;
}
arr[i=1]=a;
}
}
Ignore the floats and reals for the data, they should be ints or chars for the
purposes of our 6502/Z80 benchmark.
Just for the hell of it, I will try this out in DSP56300 assembler.
Chris
21 Dec
21 Dec
6:16 p.m.
CLeyson(a)aol.com wrote:
<snip>
Here is the code from Numerical Recipies for an
insertion sort (Fortran and C)
<snip>
{
int i,j;
float a;
for (j=2;j<=n;j++) {
a=arr[j];
i=j-1;
while (i>0 && arr[i] > a );
arr[i+1] = arr[i];
i--;
}
arr[i=1]=a;
}
}
Ignore the floats and reals for the data, they should be ints or chars for the
purposes of our 6502/Z80 benchmark.
Do they have the "Small C Compiler"
for the 6502? I know you can get a
Z80 or 8080
compiler under CP/M. Note the version #1 does not have for or &&
instructions.
Also BYTE years ago I think had some Small C benchmarks, any body know
if there
is a copy on the web?
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
22 Dec
22 Dec
11:27 a.m.
Let's leave compilers out of the equation. Even the same small-C compiler,
targeted at the two quite different CPU's potentially represent a significant
skew in favor of one or another of the two.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 22, 2001 1:16 AM
Subject: Re: 6502/Z80 speed comparison (was MITS 2SIO serial chip?)
CLeyson(a)aol.com wrote:
<snip>
> Here is the code from Numerical Recipies for an insertion sort (Fortran and
C)
<snip>
> {
> int i,j;
> float a;
> for (j=2;j<=n;j++) {
> a=arr[j];
> i=j-1;
> while (i>0 && arr[i] > a );
> arr[i+1] = arr[i];
> i--;
> }
> arr[i=1]=a;
> }
> }
> Ignore the floats and reals for the data, they should be ints or chars for
the
purposes of
our 6502/Z80 benchmark.
Do they have the "Small C Compiler" for the
6502? I know you can get a
Z80 or 8080
compiler under CP/M. Note the version #1 does not have for or &&
instructions.
Also BYTE years ago I think had some Small C benchmarks, any body know
if there
is a copy on the web?
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
21 Dec
21 Dec
9:44 p.m.
Richard Erlacher wrote:
Let's leave compilers out of the equation. Even the same small-C compiler,
targeted at the two quite different CPU's potentially represent a significant
skew in favor of one or another of the two.
Dick
How can you have skew? That is the whole idea of benchmark is to
compare
two machines. I would expect that the simple C that was given would be a
good test
when judged with other benchmarks. The 8080/Z80/8086 all generate the
same poor
code. This surprised me as shows how poor the 16 bit intel product was.
The PDP-11
version was rather nice but it even has a few quirks.
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
PS. Note all my FPGA machines generate nice 'Small C' code and have a
resonably orthogonal instruction set. The well hacked Small C compiler
self compiles under
24 KB. A similar compiler for the 8080 is about 48KB.
23 Dec
23 Dec
3:58 a.m.
see below, plz.
Dick
----- Original Message -----
From: "Ben Franchuk" <bfranchuk(a)jetnet.ab.ca>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 22, 2001 4:44 AM
Subject: Re: 6502/Z80 speed comparison (was MITS 2SIO serial chip?)
There are lots of ways in which to compare two machines. In one case you
compare how quickly or easily a particular task can be accomplished on that
particular pair of machines. Comparing the 6502 with the Z80 is extremely
difficult in this case because the quality and character of contemporaneous
software was so different. Tools and applications for the Z80, particularly
under CP/M were quite solid and professional in nature, while the "similar"
commercial products for the 6502 were limited, largely, by market forces, not
the architecture, to the Apple][, quite lame by comparison.
The Basic interpreter, for example, is a case you might want to examine. If you
were a real glutton for punishment, you could, point-by-point compare/contrast
the two and would find that the product for the 8080 was quite "serious" and
"professional" in character, the one for the 6502 was less so, being more or
less skewed toward the toy market.
Later versions for the 6502 were similarly skewed, since the 6502 was really
never used in a commercial machine intended for computing use on the U.S.
market. The early Commodore machines might have been an example. I did see a
"PET" machine that had a real keyboard on it in a magazine ad, though I never
saw one "in the flesh." The European version of that model was the only
6502-based machine that I ever knew to support 8" double-density diskettes,
though I didn't see that working "in the flesh" either. I did cash the
check I
got from the folks who sold the adapter, however.
Richard Erlacher wrote:
>
> Let's leave compilers out of the equation. Even the same small-C compiler,
> targeted at the two quite different CPU's potentially represent a
significant
skew in favor
of one or another of the two.
Dick
How can you have skew? That is the whole idea of benchmark is to
compare two machines. I would expect that the simple C that was given would
be a
good test when judged with other benchmarks.
If you can come up with a 'C' compiler of the '70's that you believe
generated
comparably good/poor machine code for both CPU's from the same source syntax I'd
be really interested to know about it.
The 8080/Z80/8086
I don't find it appropriate to lump the 8086 family together with the 8080 and
Z80. The former is a pitifully poor architecture, designed by the marketing
department and not by competent engineers, as a quick solution to the problems
Intel was faced with in the late '70's, since their architecture was
structurally limited while their principal competitor's product line was not.
The 8080 was, for its time, a solid and well-thought-out architecture, designed
for maximal effectiveness within the confines of the field of applications for
which it was designed. The Z80 was yet another step in that direction, though
it lacked some simple but vital features the lack of which made its enhanced
features much more difficult to use than they might have been.
all generate the same poor code.
The CPU's don't generate the code. Some programmer somwhere takes his best shot
at a code generator, and the rest of us have to choose whether to use it or not.
During the timespan over which I was using 6502's and Z80's, I didn't ever
come
across a 'C' compiler for the 6502. AFAIK, there's only one of them around
now
that amounts to anything and even that's somewhat of a mystery. There's never
been a native development environment of the class, even of CP/M which, though
quite functional, was less than most folks wanted. It was quite a bit more than
anything I ever encountered for the 6502, however, which explains why I used
CP/M.
This surprised me as shows how poor the 16 bit intel
product was.
Perhaps that's because the Intel product was only partly a 16-bit product, owing
much of its benefit and many of its limitations to its predecessors.
The PDP-11 version was rather nice but it even has a
few quirks.
--
Ben Franchuk --- Pre-historic Cpu's --
www.jetnet.ab.ca/users/bfranchuk/index.html
PS. Note all my FPGA machines generate nice 'Small C' code and have a
resonably orthogonal instruction set. The well hacked Small C compiler
self compiles under > 24 KB. A similar compiler for the 8080
is about 48KB.
22 Dec
22 Dec
11:25 a.m.
I think a much larger number of records, and longer records would give a more
thorough test. On a level playing field, the 6502 will always outrun the Z80 in
strictly 8-bit quantities, and the Z80 may have a bit of an advantage with
strictly 16-bit quantities. With, say 48 or 64-bit quantities, things begin to
look different, and with 1K, or even 1/2-K 32-byte records, things look VERY
different. A simple sort-in-place such as this would possibly be a reasonable
test, but the special cases have to be neutralized by doing something that makes
them insignificant. 16-bit values are an advantage to the processor with 16-bit
registers, while 8-bit values are an advantage to the processor without them.
Most data records, e.g. a customer name, however, being longer than that, might
be more of a challenge, as well as being more realistic. The 8-bitter is
favored with bytes, one with 16-bit registers has a distinct advantage with
words, but neither of them has a substantial advantage if the records range in
length between 1 and 32 bytes, with more or less random distribution of length.
A larger array of data might be more convenient for measuring the relative
performance of the CPU's, too, particularly if the comparison is closer than
first anticipated.
The relatively inefficient algorithm might actually provide a better test than a
more efficient one, e.g. shell- or quick-sort.
more below ...
Dick
----- Original Message -----
From: <CLeyson(a)aol.com>
To: <classiccmp(a)classiccmp.org>
Sent: Saturday, December 22, 2001 3:22 PM
Subject: Re: 6502/Z80 speed comparison (was MITS 2SIO serial chip?)
In a message dated 12/22/01 Chris Leyson writes:
Yes, ... order n^2, IIRC.
> How about a straight insertion bubble sort ?
A completely useless task but
it
> does take a defined number of data moves and
compare operations. The array
> to be sorted could be say, 16-bit signed integer, 1k words long and in
reverse
> order. (That should take a while for a 6502
to sort out).
In a reply dated 12/22/01 Richard Erlacher writes
Yes, maybe something of that sort would be
appropriate. Testing it on
8-bit,
and then 16-bit quantities might be just the
thing for testing the relative
ability, in spite of architectural differences, of handling longer data.
I'd
suggest that larger records might be more
appropriate, i.e. 32-byte records,
etc.
OK 8-bit and 16-bit data is appropriate but would require separate algorithms.
As for record length I would suggest at least 1k (1024) entries. (Eliminates
base page cheating)
BTW, when I was in college, which I realize was
some time ago, but, back
then,
Bubble Sort and Insertion Sort were two different
algorithms ... I don't
remember the differences, but will check my old texts, though they're in
Sanskrit ...
Apologies, that should have read insertion sort OR bubble sort. Bubble sort
runs through the array comparing adjacent values and swaps them whereas
insertion sort moves an array member until it's in the right place. In terms
of
performance they are both slow algoritms.
Here is the code from Numerical Recipies for an insertion sort (Fortran and C)
Sorts an array arr(1:n) into ascending numerical order, by straight insertion.
n is input; arr() is replaced on output by its sorted rearrangement.
integer n
real arr(n)
integer i,j
real a
do j=2,n
a=arr(j)
do i=j-1,1,-1
if (arr(i).le.a) goto 10
arr(i+1)=arr(i)
end do
i=0
10 arr(i+1)=a
end do
{
int i,j;
float a;
for (j=2;j<=n;j++) {
a=arr[j];
i=j-1;
while (i>0 && arr[i] > a );
arr[i+1] = arr[i];
i--;
}
arr[i=1]=a;
}
}
Ignore the floats and reals for the data, they should be ints or chars for the
purposes of our 6502/Z80 benchmark.
Just for the hell of it, I will try this out in DSP56300 assembler.
Chris
8353
days inactive
8354
days old
5 comments
3 participants
participants (3)
-
bfranchuk＠jetnet.ab.ca -
CLeyson＠aol.com -
edick＠idcomm.com