F30-A1200 benchmarks!
Heiko Hartmann
and an A1200:
Notes:
The A1200 has NO FastRAM (if there is an Amiga-User with FastRAM: please
type in the benchmarks und post the time the A1200 needs!). Sorry, but i
can't get one with FastRAM.
There is no use of the DSP build in the Falcon. With special DSP-code you
can get more then 10times faster programs.
--------------------------------BENCH1---------------------------------
bench1:
move.l #$40,d6
loop0:
move.l #$ffffff,d7
loop1:
move.l buffer,d0
add.l #10,d0
divu #10,d0
move.l d0,buffer
muls #20,d0
dbra d7,loop1
dbra d6,loop0
rts
buffer:
blk.l 10
This is a loop repeated 1073741760 times. There are moves, some arithmetics
and at least some branches.
F30 (640x200x4 60 Hz): 21.3 s
A1200 (640x200x4 60 Hz): 31.1 s
dito with forbid(): 30.5 s
(forbid() stops all other tasks -> no multitasking).
F30 (640x240x256 60 Hz): 24.5 s
A1200 (640x240x256 60 Hz): 40.1 s
dito with forbid(): 39.0 s
F30 with both caches off: 43.1 s
Now the same benchmark with words instead of longwords:
F30 (640x240x256 60 Hz): 21.5 s
A1200 (640x240x256 60 Hz): 32.7 s (with forbid())
Results:
Loss caused by higher resolution: F30 -13%
A1200 -22%
Loss caused by Longs instead Words: F30 -12%
A1200 -16%
Overall: The F30 is about 34% faster than the A1200 in this benchmark.
------------------------------BENCH2-------------------------------------
bench2:
move.l $40,d6
loop0:
move.l $ffffff,d7
loop1:
movem.l buffer,a1-a6/d0-d5
movem.l a1-a6/d0-d5,buffer
dbra d7,loop1
dbra d6,loop0
rts
buffer:
blk.l 20
This is a test of memory-movement.
F30 (640x240x256 60 Hz): 48.6 s
A1200 (640x240x256 60 Hz): 126.1 s
dito with forbid(): 124.2 s
Now with words instead of longwords:
F30 (640x240x256 60 Hz): 34.3 s
A1200 (640x240x256 60 Hz): 68.8 s
Results:
Loss caused by longwords instead of words: F30 -30%
A1200 -45%
Overall: The Falcon is 55% faster than the A1200 in this benchmark.
-------------------------------BENCH3------------------------------------
bench3:
move.l #$40,d6
loop0:
move.l #$ffffff,d7
loop1:
move.l buffer,d2
add.l #10,d2
divu #10,d2
move.w buffer,d3
or.w d2,d3
cmp.w d2,d3
move.w d2,buffer
move.l d3,d1
muls #20,d2
movem.l d1-d3,buffer
lsl.w #3,d2
sub.l d2,d3
cmp.w d2,d1
bchg #0,d2
move.l d2,buffer
dbra d7,loop1
dbra d6,loop0
rts
buffer:
blk.l 10
This is an enhanced version of bench1 (with logical arithmetics, shifts,
bit-operations, comparisons etc.).
F30 (640x200x4 60 Hz): 38.8 s
A1200 (640x200x4 60 Hz): 48,4 s (with forbid())
F30 (640x240x256 60 Hz): 42.5 s
A1200 (640x240x256 60 Hz): 54.5 s
Results:
Loss caused by higher resolution: F30 -9%
A1200 -11%
Overall: The F30 is 22% faster than the A1200 (relativly to A1200).
Ok folks, that's all. No comments on this! I'm waiting for the figures of
an Amiga 1200 with FastRAM...
All figures can be easily checked by yourself!
Ciao, Heiko
(zcam...@rpool9.rus.uni-stuttgart.de)
Flip
Heiko Hartmann <zcam...@rpool9.rus.uni-stuttgart.de> wrote:
>Ok guys, here are the first benchmarks which i have made with my Falcon 030
>and an A1200:
>
>Notes:
>The A1200 has NO FastRAM (if there is an Amiga-User with FastRAM: please
>type in the benchmarks und post the time the A1200 needs!). Sorry, but i
>can't get one with FastRAM.
>There is no use of the DSP build in the Falcon. With special DSP-code you
>can get more then 10times faster programs.
>
[benchmarks and results deleted]
>
>Ok folks, that's all. No comments on this! I'm waiting for the figures of
>an Amiga 1200 with FastRAM...
>All figures can be easily checked by yourself!
>
>Ciao, Heiko
>(zcam...@rpool9.rus.uni-stuttgart.de)
Heiko,
I admit I think the benchmarks look solid, but there are some things
that should be probably be done to make it a bit fairer. For example,
I'd like to see more results of what happens when the loops exceed the
size of the 68030's data/instruction cache. Another thing I think should
be done (out of fairness) is to run the Falcon benchmarks under MultiTOS
if possible to get an idea of how much of a punishment we would take with
that.
Personally, though, I feel vindicated because this proves the Falcon isn't
the "dog" some people were saying it was. Although I'm hesitant to say it
is 50% faster than the Ami in terms of raw CPU power. :)
P.S., One last question.. what assemblers were used for the test?
Brian Grier Perpk
> Ok guys, here are the first benchmarks which i have made with my Falcon 030
> and an A1200:
>
> Notes:
> The A1200 has NO FastRAM (if there is an Amiga-User with FastRAM: please
> type in the benchmarks und post the time the A1200 needs!). Sorry, but i
> can't get one with FastRAM.
> There is no use of the DSP build in the Falcon. With special DSP-code you
> can get more then 10times faster programs.
>
<much deleted>
>
> Overall: The F30 is 22% faster than the A1200 (relativly to A1200).
>
> Ok folks, that's all. No comments on this! I'm waiting for the figures of
> an Amiga 1200 with FastRAM...
> All figures can be easily checked by yourself!
>
Your processor bench marks look reasonable but you did not mention the cache
mode on anything other than the Falcon in the first test. Could you continue your
testing and get numbers for all tests with and without the instrucion caches
enabled and disabled on both machines.
Over all your numbers are coming in line with my previous predictions
about the memory access speeds of a no mod A1200 and a no mod Falcon,
the Falcon would show approximately 40% faster memory access, due to the
extra 3 wait states that A1200 requires to access it's standard RAM.
The fact that the overall system performance difference is not 40% shows
that the video contention is about what most people feared (I sure wish they
had used video-rams and basically removed video contention from the system,
but most Amiga Users will have the same complaint)
Thank you for this informative post and I'll look forward to the rest of
your results. Maybe someone else can create a set of tests that would cover
hard disk copies, and that type of thing.
Brian
--
Disclaimer: The opinions expressed are mine not those of BNR.
____________________________________________________________________________
| Brian, WS1S (ST/TT User/Developer) | If I wanted a computer to play games |
| Bell Northern Research | on I'd buy an Amiga. However I have |
| Research Triangle Park, NC | real work to do. So please get lost! |
|____________________________________|_______________________________________|
Gavan Martin Moran
cme...@wam.umd.edu ('Flip') writes of the benchmarks performed by
Heiko Hartmann <zcam...@rpool9.rus.uni-stuttgart.de> .......
> Personally, though, I feel vindicated because this proves the Falcon isn't
>the "dog" some people were saying it was. Although I'm hesitant to say it
>is 50% faster than the Ami in terms of raw CPU power. :)
Well, Its no surprise that the F030 is faster than the chipram
only A1200. It was only about 50% faster in one test though...
around 25% on avg in the others. Dont forget that adding fastram to
the A1200 typically speeds it up by 2x. This would bring it level in
that test and put it ahead in the others. I dont have Fastram on my
machine .. Yet ;-) so I cant do the tests, but someone should be
able to.
By the way, I have seen 3.84 MIPs quoted for the F030 and 2.96
for the A1200 with fastram. The tests would seem to indicate that
the 16-bit bus and shared ram do cut down considerably on the
actual delivered power as on CPU MIPs terms, the F030 would over
2.5x the speed in all the tests. Also, program size can influence
the cache hit rate - a small benchmark sitting almost entirely in
the cache may or may not be representative.
gavan
Brian Grier Perpk
I suggested posting results of all test with and with out instruction caches
enabled, which he did for the Falcon on the first test. I like the testing under
Multi-TOS idea.
|>
|> Personally, though, I feel vindicated because this proves the Falcon isn't
|> the "dog" some people were saying it was. Although I'm hesitant to say it
|> is 50% faster than the Ami in terms of raw CPU power. :)
|>
I never thought that the Falcon would be slow, just not fast enough to warrant
replacing my TT :) It definitely is not 50% more CPU just more memory bandwidth
than on an A1200 without FastRAM. The numbers comapring a A1200 with Fast-RAM
are what I'm interested in, I've predicted that the A1200 will be able to access
Fast-RAM slightly faster, 15%, than a Falcon can access standard ram.
|> P.S., One last question.. what assemblers were used for the test?
|>
Nice part about assembly language is that the assembler does not add another
variable into the equation. I prefer the assembler that comes with Pure C,
the GNU assembler uses a bastardised variation of the motorla syntax that
is damned annoying, IMHO of course.
Johan Klockars
>Ok guys, here are the first benchmarks which i have made with my Falcon 030
>and an A1200:
>--------------------------------BENCH1---------------------------------
>bench1:
> move.l #$40,d6
>loop0:
> move.l #$ffffff,d7
>loop1:
> dbra d7,loop1
> dbra d6,loop0
> rts
>buffer:
> blk.l 10
>
>This is a loop repeated 1073741760 times. There are moves, some arithmetics
>and at least some branches.
Actually that should be ($40 + 1) * ($ffff + 1) = 4259840 times. The dbra
instruction only uses the bottom 16 bits.
>F30 (640x200x4 60 Hz): 21.3 s
>A1200 (640x200x4 60 Hz): 31.1 s
> dito with forbid(): 30.5 s
> (forbid() stops all other tasks -> no multitasking).
>F30 (640x240x256 60 Hz): 24.5 s
Did you run this 640x240x256 test on a VGA monitor or was it really 640x200x256
on a TV? On a VGA the 240 line modes use line doubling, which means that you
would get exactly the same results if you tried 640x480x256.
If it was tried on a VGA you should rerun it in 640x480x256 on both machines to
get a fair comparison.
...
>------------------------------BENCH2-------------------------------------
>bench2:
> move.l $40,d6
>loop0:
> move.l $ffffff,d7
>loop1:
> movem.l buffer,a1-a6/d0-d5
> movem.l a1-a6/d0-d5,buffer
> dbra d7,loop1
> dbra d6,loop0
> rts
>buffer:
> blk.l 20
>
>This is a test of memory-movement.
>
>F30 (640x240x256 60 Hz): 48.6 s
>A1200 (640x240x256 60 Hz): 126.1 s
> dito with forbid(): 124.2 s
>
>Now with words instead of longwords:
>F30 (640x240x256 60 Hz): 34.3 s
>A1200 (640x240x256 60 Hz): 68.8 s
>
>Results:
>Loss caused by longwords instead of words: F30 -30%
> A1200 -45%
When you say "words instead of longwords" do you mean that you simply exchange
the .l for .w in the movems? If you do, does that mean that the '020 can
concatenate the 16 bit words into 32 bit ones before writing to memory? Is this
a special feature of the movem.w instruction?
Anyway, the impressive numbers you get from the Falcon is of course because of
the data cache. The read will not access memory after the first time through
the loop. To make the test more realistic, try using post increment.
...
>Ok folks, that's all. No comments on this! I'm waiting for the figures of
>an Amiga 1200 with FastRAM...
>All figures can be easily checked by yourself!
I haven't checked your figures, but the benchmarks themselves are much more
data cache friendly than any "real" programs. Also, all the programs fits in
the instruction cache which is very good for the Falcon.
I'm sure this will cause the Amiga people to start running tests too. ;-)
By the way, I posted a bus speed test here during the summer. Has anyone run it
on the A1200? If you missed it, I'll be happy to mail it to you.
The test wrote .5M nop:s in memory and executed them a hundred times or so.
This probably gives a rather good indication of the bus speed since the cache
will be useless.
--
Chalmers University | Why are these | e-mail : d8k...@dtek.chalmers.se
of Technology | .signatures | Address: Johan Klockars
| so hard to do | Foreningsgatan 32/408
Gothenburg, Sweden | well? | 411 27 Gothenburg, SWEDEN
A.S.C.Pomianowski
>I haven't checked your figures, but the benchmarks themselves are much more
>data cache friendly than any "real" programs. Also, all the programs fits in
>the instruction cache which is very good for the Falcon.
Am I missing something here? The 68020 and 68030 both have a 256 byte instruction
cache so this shouldn't matter. Does the 68EC020 lack the instruction cache? This
would be a rather serious omission if this is the case, because the instruction
cache can have a significant effect on the speed of carefully written code.
The other benefits reported in the benchmarks seem reasonable, simply disable
the 68030 data cache before running them to see the effect of memory access.
Cheers
- Andy.
Eyvind Bernhardsen
Well, since the entire point is to see how the Falcon is degraded by
its 16-bit memory access, using a cache defeats the purpose of the
benchmarks...
> - Andy.
--
//| Eyvind Bernhardsen | eyv...@lise.unit.no
// | |
\\ //--| Finger me for my | Amigoid and Linux advocate.
\X/ | public PGP key :) | Save the whalers!
Brian Grier Perpk
|>
|>
|> cme...@wam.umd.edu ('Flip') writes of the benchmarks performed by
|> Heiko Hartmann <zcam...@rpool9.rus.uni-stuttgart.de> .......
|>
|> > Personally, though, I feel vindicated because this proves the Falcon isn't
|> >the "dog" some people were saying it was. Although I'm hesitant to say it
|> >is 50% faster than the Ami in terms of raw CPU power. :)
|>
|> Well, Its no surprise that the F030 is faster than the chipram
|> only A1200. It was only about 50% faster in one test though...
|> around 25% on avg in the others. Dont forget that adding fastram to
|> the A1200 typically speeds it up by 2x. This would bring it level in
|> that test and put it ahead in the others. I dont have Fastram on my
|> machine .. Yet ;-) so I cant do the tests, but someone should be
|> able to.
I'll agree with this. Let's get at least one A1200, with Fast-RAM, user to
run these test, both with and without the instruction caches enabled.
|>
|> By the way, I have seen 3.84 MIPs quoted for the F030 and 2.96
|> for the A1200 with fastram. The tests would seem to indicate that
|> the 16-bit bus and shared ram do cut down considerably on the
|> actual delivered power as on CPU MIPs terms, the F030 would over
|> 2.5x the speed in all the tests. Also, program size can influence
|> the cache hit rate - a small benchmark sitting almost entirely in
|> the cache may or may not be representative.
|>
|> gavan
Actually 3.8mips, and 3.0mips are Motorola's numbers for the processors in each
machine. Both processors can access memory much faster than they typically
need it for most operations. Again I suggest we wait and see what the numbers
come out like both with and without instruction caches enabled. Then
compare the machines only with caches disabled to create a more level
playing ground.
Brian
p.s. Didn't the original poster request no comments?
(I was the first to ignore that request, to the best of my knowledge)
Brian Grier Perpk
|> Anyway, the impressive numbers you get from the Falcon is of course because of
|> the data cache. The read will not access memory after the first time through
|> the loop. To make the test more realistic, try using post increment.
|>
I might get burned for this but...
If MTOS/TOS works on my TT the same as the Falcon, and since its th same
program I think this can be safely assumed. Then disabling the cache disables
both the instruction AND data cache.
|> ...
|> >Ok folks, that's all. No comments on this! I'm waiting for the figures of
|> >an Amiga 1200 with FastRAM...
|> >All figures can be easily checked by yourself!
|>
|> I haven't checked your figures, but the benchmarks themselves are much more
|> data cache friendly than any "real" programs. Also, all the programs fits in
|> the instruction cache which is very good for the Falcon.
|> I'm sure this will cause the Amiga people to start running tests too. ;-)
But then he did post the numbers for bench1 with the caches disabled :)
|>
|> By the way, I posted a bus speed test here during the summer. Has anyone run it
|> on the A1200? If you missed it, I'll be happy to mail it to you.
|> The test wrote .5M nop:s in memory and executed them a hundred times or so.
|> This probably gives a rather good indication of the bus speed since the cache
|> will be useless.
|>
Again let's see if any future tests are with the caches enabled and disabled.
Anyway since the Falcon does have a data cache, though very small, it is part
of the standard system, though would invalidate these particular tests.
Brian
Johan Klockars
>In article 8...@news.chalmers.se, d8k...@dtek.chalmers.se (Johan Klockars) writes:
>>I haven't checked your figures, but the benchmarks themselves are much more
>>data cache friendly than any "real" programs. Also, all the programs fits in
>>the instruction cache which is very good for the Falcon.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Am I missing something here? The 68020 and 68030 both have a 256 byte instruction
>cache so this shouldn't matter. Does the 68EC020 lack the instruction cache? This
My point was that the Falcon would take a much larger performance hit if it had
to go to RAM to fetch the instructions because of its 16 bit bus. With the code
in the cache the only accesses to the bus are the data writes.
Flip
Eyvind Bernhardsen <eyv...@Lise.Unit.NO> wrote:
>
>Well, since the entire point is to see how the Falcon is degraded by
>its 16-bit memory access, using a cache defeats the purpose of the
>benchmarks...
>
Actually, that may be why Atari chose to go with the 68030 in the Falcon...
it had the built-in MMU (needed for MultiTOS/MiNT memory protection, but
not a concern on the Amiga), and had a built-in cache that on some cases
might make a big difference.... although it the '020 includes a
cache, does it not?
Gavan Martin Moran
Re: caches....
I think Andy from umist wrote....
> Am I missing something here? The 68020 and 68030 both have a 256 byte instru
ction
>cache so this shouldn't matter. Does the 68EC020 lack the instruction cache?
This
AFAIK, the 030 has both data and instruction caches but the 020 has
only an instruction cache. Also, I think the 030s caches are 256
bytes but the 020s is only 64 bytes????
I think the MultiTos idea was good for the tests as lets not forget
that a multitasking OS imposes overheads. Not just that, but also
multitasking tends to gronk caches as the `locality of reference`
thing goes out of the window...
gavan
Borge Noest
Well, I took the time to study the benchmark programs. Were you serious
about them???
1. The code fits in the cache (both 1200 and F030).
2. The data fits in the cache on the F030.
3. In the first benchmark you can't just exchange all memory references
from .l to .w and expect the result to be the same. Using .w takes close to
twice as long time.
4. You should longword align all branch targets and data. (I expect the
F030 would loose(sp??) less if not longword aligned.)
I also suggest that benchmarks should be run with all multitasking and
interrupts off, and then with all on.
(No, I don't have a 1200, I just tested on my 2000.)
--
|/// bor...@stud.cs.uit.no (Boerge Noest) | Amiga B2000 \\\|
|// Box 218, 9001 Tromsoe, Norway | Remember to :-) when needed \\|
|/ The worlds northernmost university | Life is worth living. \|
#Disclaimer: This university does not speak for me.
Rickard Troedsson
EB> Well, since the entire point is to see how the Falcon is degraded by
EB> its 16-bit memory access, using a cache defeats the purpose of the
EB> benchmarks...
The entire point is to show the Amiga fanatics that claim the A1200 to be
*FASTER* than the Falcon that it's a GAMES MACHINE ..
+ _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
+ _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
+-------------- Official RATSoft/ST and Climax SoftWare Support Site +
+ Synchron Assembly ------------ 2:200/612 - 7:102/102 - 90:1101/112 +
+ SYNC -------- Opinions expressed are definitely not my own! -------+
Eyvind Bernhardsen
> The entire point is to show the Amiga fanatics that claim the A1200 to be
> *FASTER* than the Falcon that it's a GAMES MACHINE ..
Go back to kindergarten and let the adults figure out which machine is faster.
> + _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
Michael van Elst
> Am I missing something here? The 68020 and 68030 both have a 256 byte instruction
>cache so this shouldn't matter.
No, but using the cache hides the Falcons memory problems. Real-life programs
_are_ larger than the cache. The benchmarks are tweaked to show 030 advantages
anyway, but again, this has less impact on real-life programs than with these
artifical tests.
Regards,
--
Michael van Elst
UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p55...@mpirbn.mpifr-bonn.mpg.de
"A potential Snark may lurk in every tree."
Michael van Elst
>AFAIK, the 030 has both data and instruction caches but the 020 has
>only an instruction cache. Also, I think the 030s caches are 256
>bytes but the 020s is only 64 bytes????
No, the 020 has a 256 byte instruction cache. It is still a bit inferior
to the 030 instruction cache as the 020 can't fetch an instruction from
the cache while moving data on the external bus (i.e. no hardware
architecture).
Michael van Elst
*sigh*.. should read Harvard architecture in my last posting.
Rickard Troedsson
EB> Go back to kindergarten and let the adults figure out which machine is
EB> faster.
Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
A1200, before we do benchmarks?
Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
than the A1200. Final.
+ _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
Eyvind Bernhardsen
> Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
> A1200, before we do benchmarks?
Because the REASON the Falcon is considered crippled is its 16-bit bus!
The test *I'd* like to do would compare a 32-bit Falcon with the current
16-bit Falcon, caches off. Too bad there ain't no 32-bit Falcon around.
> + _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
Gerry Mon
>
>Because the REASON the Falcon is considered crippled is its 16-bit bus!
>The test *I'd* like to do would compare a 32-bit Falcon with the current
>16-bit Falcon, caches off. Too bad there ain't no 32-bit Falcon around.
>
You're missing the entire point. No one would run a Falcon with the
cache OFF. If the cache can "hide" the performance bottleneck of a
16-bit memory interface, then why should it be considered a "crippled"
architecture?
The real test of an architecture is how well it performs in a real
environment. Not in artificial benchmarks designed to show it at its
worst (or best).
Cache are designed to make a slower memory system perform like a
faster memory system but at a lower cost. I think it's silly to try
to judge an architecture by trying to "remove" the benefits of some of
it's features (like a cache).
For example, let's suppose we are trying to design two computer
systems.
1) Computer A uses a 66Mhz cpu with no cache. But we use very fast
(and expensive) memory to keep up with the cpu.
2) Computer B uses a 66Mhz cpu with a 128K cache. The cache has a
very high hit rate. This allows us to use much slower (and cheaper)
memory to give basically the same performance on many real
applications as Computer A.
The main point to note is that Computer A is going to be much more
expensive than Computer B. But Computer B offers approximately the
same performance. Which is the better computer? From a consumer's
standpoint, Computer B is better.
Are you going to say that Computer B is "crippled"? And that we
should only compare Computer A and Computer B by first turning off the
cache? But the cache is one of the key architectural features of
Computer B! Turning it off doesn't make sense to me.
In the same way, turning off the Falcon's cache to compare it with
another computer doesn't make sense. The cache is a key part of its
architecture.
--Gerry
A.S.C.Pomianowski
>In <26q5v3...@bhars12c.bnr.co.uk> ap...@bhars42a.bnr.co.uk (A.S.C.Pomianowski) writes:
>> Am I missing something here? The 68020 and 68030 both have a 256 byte instruction
>>cache so this shouldn't matter.
>No, but using the cache hides the Falcons memory problems. Real-life programs
>_are_ larger than the cache. The benchmarks are tweaked to show 030 advantages
>anyway, but again, this has less impact on real-life programs than with these
>artifical tests.
Using the data cache might give the Falcon an advantage over the A1200, and
I agree that the benchmarks should be written so that the Falcon has to look
outside the data cache so that we can see how its 'real life' memory access
fares (it is easy enough to disable the data cache anyway, and then run the
benchmark). I _don't_ think that using the instruction cache 'favours'
the Falcon (any more than it should) over the A1200 - since most 68000
instructions are of word (16 bit) length anyway, I wouldn't expect the Falcon
to be crippled by its bus for instruction fetches for the majority of
instructions. Turn the 030 and 020 instruction caches off before running
the benchmarks if you really want to check out the worst case 100 percent
cache miss scenario.
How else were the benchmarks tailored to show 030 advantages? (No flame -
I'm just interested.)
>Michael van Elst
- Andy.
Ricardo Hernandez Muchado
|> >I haven't checked your figures, but the benchmarks themselves are much more
|> >data cache friendly than any "real" programs. Also, all the programs fits in
|> >the instruction cache which is very good for the Falcon.
|> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|>
|> Am I missing something here? The 68020 and 68030 both have a 256 byte instruction
|> cache so this shouldn't matter. Does the 68EC020 lack the instruction cache?
Yes. The point is that 1) Heiko doesn't mention if he's using the '020 cache
and 2) In a real-world application, the cache will not save the '030
[stuff deleted]
|>
|> Cheers
|>
|> - Andy.
--
-------------------------------------------------------------------------
Raist A1200/CSA '12 Gauge' 030/882 @ 50Mhz, 16 megs Fast Ram, 200 meg HD
// >>> I LOVE IT <<<< My comments are my own, not of my employer
\X/ 256,000 + colors, 24-bit palette Real 3D V2, Image FX, Scala MM210
>>> New internet address: ra...@vnet.ibm.com <<<<
Ricardo Hernandez Muchado
|> In article <26plhk$u...@info2.rus.uni-stuttgart.de>,
|> Heiko Hartmann <zcam...@rpool9.rus.uni-stuttgart.de> wrote:
|> >Ok guys, here are the first benchmarks which i have made with my Falcon 030
|> >and an A1200:
[stuff deleted]
|> >
|> >Ciao, Heiko
|> >(zcam...@rpool9.rus.uni-stuttgart.de)
|>
|>
|> Heiko,
|>
|> I admit I think the benchmarks look solid,
^^^^^^^^^^^^^^^^^^^^^^^^^
/ To me, they don't. They are 68xxx instructions though, which
means they must be a program :-)
|> but there are some things
|> that should be probably be done to make it a bit fairer. For example,
|> I'd like to see more results of what happens when the loops exceed the
|> size of the 68030's data/instruction cache.
EXACTLY! :-)
|> Another thing I think should
|> be done (out of fairness) is to run the Falcon benchmarks under MultiTOS
|> if possible to get an idea of how much of a punishment we would take with
|> that.
Yep. So those benchmarks weren't run in a Falcon multitasking environment?
Let's talk about 'objectiveness here' Heiko.
|> Personally, though, I feel vindicated because this proves the Falcon isn't
|> the "dog" some people were saying it was. Although I'm hesitant to say it
|> is 50% faster than the Ami in terms of raw CPU power. :)
Flip, I like you because you are among the few Atarians that are objective.
I would say anyway that watch out with those benchmarks anyway and take them
with salt because the caches are playing a role there that usually they don't.
Like I said on a reply, the caches are doing the machine 75% faster on the first
benchmark (Falcon) which is something that I would wish to be true considering
I have a '030 machine. This is *obviously* not true on a real-application.
If you had a '040 the caches (since they are bigger) start playing a much bigger
role. I think that not even 75% even with the '040 caches...
|>
|> P.S., One last question.. what assemblers were used for the test?
|>
|>
--
Ricardo Hernandez Muchado
True. But the deal is in that on those benchmarks the '30 of the Falcon
benefits *big time* since those benchmarks fit almost entirely in memory,
something that is not true in a real-world application. Same will go
for the '020 in the A1200.
Ricardo Hernandez Muchado
|> Ok guys, here are the first benchmarks which i have made with my Falcon 030
|> and an A1200:
Well, let's see how fair are your benchmarks...
|>
|> Notes:
|> The A1200 has NO FastRAM (if there is an Amiga-User with FastRAM: please
|> type in the benchmarks und post the time the A1200 needs!). Sorry, but i
|> can't get one with FastRAM.
|> There is no use of the DSP build in the Falcon. With special DSP-code you
|> can get more then 10times faster programs.
|>
|> --------------------------------BENCH1---------------------------------
|> bench1:
|> move.l #$40,d6
|> loop0:
|> move.l #$ffffff,d7
|> loop1:
|> move.l buffer,d0
|> add.l #10,d0
|> divu #10,d0
|> move.l d0,buffer
|> muls #20,d0
|> dbra d7,loop1
|> dbra d6,loop0
|> rts
|> buffer:
|> blk.l 10
|>
|> This is a loop repeated 1073741760 times. There are moves, some arithmetics
|> and at least some branches.
|> F30 (640x200x4 60 Hz): 21.3 s
|> A1200 (640x200x4 60 Hz): 31.1 s
|> dito with forbid(): 30.5 s
|> (forbid() stops all other tasks -> no multitasking).
|> F30 (640x240x256 60 Hz): 24.5 s
|> A1200 (640x240x256 60 Hz): 40.1 s
|> dito with forbid(): 39.0 s
|> F30 with both caches off: 43.1 s
|>
|> Now the same benchmark with words instead of longwords:
|> F30 (640x240x256 60 Hz): 21.5 s
|> A1200 (640x240x256 60 Hz): 32.7 s (with forbid())
|>
|> Results:
|> Loss caused by higher resolution: F30 -13%
|> A1200 -22%
|> Loss caused by Longs instead Words: F30 -12%
|> A1200 -16%
|> Overall: The F30 is about 34% faster than the A1200 in this benchmark.
Problems that still make your benchmark not reliable:
1. Benchmark is short. Fits entirely inside the instruction cache
of the '030, and some data inside the data cache. In this benchmark
the effects of the cache are just too generous.
2. No mention if the '020 cache of the A1200 was turned on or off
3. You didn't try the benchmark with words on a lower resolution, less
colors mode on the A1200 and F30.
|> ------------------------------BENCH2-------------------------------------
|> bench2:
|> move.l $40,d6
|> loop0:
|> move.l $ffffff,d7
|> loop1:
|> movem.l buffer,a1-a6/d0-d5
|> movem.l a1-a6/d0-d5,buffer
|> dbra d7,loop1
|> dbra d6,loop0
|> rts
|> buffer:
|> blk.l 20
|>
|> This is a test of memory-movement.
|>
|> F30 (640x240x256 60 Hz): 48.6 s
|> A1200 (640x240x256 60 Hz): 126.1 s
|> dito with forbid(): 124.2 s
|>
|> Now with words instead of longwords:
|> F30 (640x240x256 60 Hz): 34.3 s
|> A1200 (640x240x256 60 Hz): 68.8 s
|>
|> Results:
|> Loss caused by longwords instead of words: F30 -30%
|> A1200 -45%
|> Overall: The Falcon is 55% faster than the A1200 in this benchmark.
Problems that make your benchmark not reliable:
1. Again, benchmark is short. Fits entirely inside the cache (both caches)
of the '030 of the Falcon. Here the effect of non-reliability is even
*more pronnounced* as all the data can fall in the data cache with
no problem, since the buffer DOES NOT CHANGE.
2. Again, no mention if the '020 of the A1200 was on or off
3. You ran *ALL* the benchmarks in at 60Hz, which the bus contention
on the A1200 starts to make a stronger mark. If you had Fast RAm
the results would be damn different.
|> -------------------------------BENCH3------------------------------------
|> bench3:
|> move.l #$40,d6
|> loop0:
|> move.l #$ffffff,d7
|> loop1:
|> move.l buffer,d2
|> add.l #10,d2
|> divu #10,d2
|> move.w buffer,d3
|> or.w d2,d3
|> cmp.w d2,d3
|> move.w d2,buffer
|> move.l d3,d1
|> muls #20,d2
|> movem.l d1-d3,buffer
|> lsl.w #3,d2
|> sub.l d2,d3
|> cmp.w d2,d1
|> bchg #0,d2
|> move.l d2,buffer
|> dbra d7,loop1
|> dbra d6,loop0
|> rts
|> buffer:
|> blk.l 10
|>
|> This is an enhanced version of bench1 (with logical arithmetics, shifts,
|> bit-operations, comparisons etc.).
|>
|> F30 (640x200x4 60 Hz): 38.8 s
|> A1200 (640x200x4 60 Hz): 48,4 s (with forbid())
|> F30 (640x240x256 60 Hz): 42.5 s
|> A1200 (640x240x256 60 Hz): 54.5 s
|>
|> Results:
|> Loss caused by higher resolution: F30 -9%
|> A1200 -11%
|> Overall: The F30 is 22% faster than the A1200 (relativly to A1200).
Problems that make your benchmark unreliable:
1. Again, benchmark is too short. Fits entirely inside the instruction cache
and some data is cached on the data cache. Again, a real-life situation
is not so forigiving!
2. Again, no mention if the icache of the '020 in the A1200 was on or off
3. Same comment of running @60Hz with no fast ram.
|>
|>
|> Ok folks, that's all. No comments on this! I'm waiting for the figures of
|> an Amiga 1200 with FastRAM...
|> All figures can be easily checked by yourself!
I did, check my comments. The information you present is not reliable. Did
you see what happened when you turned the Falcon caches off? The machine
ran 75% slower in the first test. If you are telling me that on a real-world
application (Word processor, DTP, Database, etc.) you gain 75% more speed
on a '030, I have a bridge to sell for you.
Look down below and you'll see that I'm using a '030. I have seen that
the best I have obtained on my accelerator is about 20% with an average of 8%<->12%.
|>
|> Ciao, Heiko
|> (zcam...@rpool9.rus.uni-stuttgart.de)
Borge Noest
>You're missing the entire point. No one would run a Falcon with the
>cache OFF.
Of course not, but the point is that the benchmark should not fit in the data
cache if you wish to measure memory speed. Most real-world data does not fit
too well in the cache. Code often fits somewhat better.
>--Gerry
Michael van Elst
>Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
>than the A1200. Final.
The benchmarks were biased towards 030, display modes were chosen that make
the Falcon look good and much information about the setup was missing.
Real-world applications will be a complete different thing, so will be
neutral benchmarks.
Michael van Elst
>You're missing the entire point. No one would run a Falcon with the
>cache OFF. If the cache can "hide" the performance bottleneck of a
>16-bit memory interface, then why should it be considered a "crippled"
>architecture?
The cache can hide the performance bottleneck. But how good is that ?
For the benchmarks the cache made _any_ memory bottleneck invisible
(and that was the purpose of the 'benchmark').
>The real test of an architecture is how well it performs in a real
>environment. Not in artificial benchmarks designed to show it at its
>worst (or best).
Exactly :)
>Cache are designed to make a slower memory system perform like a
>faster memory system but at a lower cost. I think it's silly to try
>to judge an architecture by trying to "remove" the benefits of some of
>it's features (like a cache).
But still you have to 'simulate' a 'real environment' with your benchmarks.
>2) Computer B uses a 66Mhz cpu with a 128K cache. The cache has a
>very high hit rate. This allows us to use much slower (and cheaper)
>memory to give basically the same performance on many real
>applications as Computer A.
A _256 byte_ cache has not a very high hit rate except for these benchmarks.
Michael van Elst
>benchmark). I _don't_ think that using the instruction cache 'favours'
>the Falcon (any more than it should) over the A1200 - since most 68000
>instructions are of word (16 bit) length anyway, I wouldn't expect the Falcon
>to be crippled by its bus for instruction fetches for the majority of
>instructions.
Well, that would be true IF the 020 or 030 would fetch instructions
individually. But in reality they always do 32bit prefetches. (On a 32bit
bus the 030 would even burst in 4 32bit words in a row very quickly).
> How else were the benchmarks tailored to show 030 advantages? (No flame -
>I'm just interested.)
One easy thing is the fact that the memory write appeared just before a
long internal operation (MUL). On a 030 this hides the write completely.
Tim Wilson
>>Michael van Elst
>
>- Andy.
This is awfully funny...people are screaming "Let's see the benchmarks!" Then,
when the benchmarks finally come out, they're not "good enough" for you. Give
me a break!
--
Tim Wilson
t...@rider.cactus.org
"The pain of war cannot exceed the woe of aftermath..."
- Led Zeppelin
Iain....@barclays.co.uk
|>
|> EB> Go back to kindergarten and let the adults figure out which machine is
|> EB> faster.
|>
|> Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
|> A1200, before we do benchmarks?
|>
|> Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
|> than the A1200. Final.
for the price difference, the Falcon damned well ought to be faster!
|> +-------------- Official RATSoft/ST and Climax SoftWare Support Site +
What is RATSoft? I used to use this name for PD I did on the 8bit Atari many
years ago - circa '84.
+---------------+-------------------------------------------------------------+
| Iain R Laskey | Atari Falcon user and very happy with it! |
+---------------+-------------------------------------------------------------+
Warwick Allison
>ap...@bhars42a.bnr.co.uk (A.S.C.Pomianowski) writes:
>
> > >the instruction cache which is very good for the Falcon.
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Well, since the entire point is to see how the Falcon is degraded by
>its 16-bit memory access, using a cache defeats the purpose of the
>benchmarks.
On the contrary. I think the point is to see which is the best
trade-off: "32 bit bus, no cache, 14.4MHz" or "16 bit bus, cache, 16MHz".
A1200 has no cache, Falcon has 16-bit bus.
I expect that a benchmark could be written which makes either more impressive.
A real test would be to do something real and compile the code with GNU C on
both machines.
Q: Does the 68EC030 have the high-speed shifting circuitry?
--
Warwick
_-_|\ war...@cs.uq.oz.au |||||| AMS = C++ game library |
/ * <-- Computer Science Department, |||||| GEM++ = C++ GEM library |
\_.-._/ University of Queensland, _// || \\_ Both are Free Software |
_____ v ____ Brisbane, Australia. ______ |_/ || \_| ________________________|
Warwick Allison
>I think the MultiTos idea was good for the tests as lets not forget
>that a multitasking OS imposes overheads. Not just that, but also
>multitasking tends to gronk caches as the `locality of reference`
>thing goes out of the window...
What a crock. If the timeslice is, say, 200ms, then you've got 3 million
clock cycles that can take advantage of locality of reference*.
Are these things so hard for people to work out for themselves?
Does Gavan think Unix boxes don't have or need caches?
* Locality of Reference is the tendency in real-world programs for the
processing point (both program counter and data addresses referenced)
to jitter in small areas for mouch of the time. For example, loops
in code, records in data. Caching is designed to take advantage of
this tendency by remembering recently used locations and (in spare time)
by loading in more from an area of memory than the code is actually
asking for. RISC processors take additional use of locality of reference
by using this latter approach of sucking in extra data to the point where
it even starts executing instructions that are AFTER a branch, in
anticipation that half the time that branch won't be taken!
Warwick Allison
>Real-life programs are larger than the cache.
But real-life loops are not. Do you think they put caches in chips
for no reason? Are you aware that many chips have over 1/3 of the
silicon devoted to cache?
Numerous experiments have been done with real-world code and found
that a cache seriously enhances performance. There are a lot of other
things you can do with 1/3 of your silicon (eg. shifters, fast multipliers,
etc.)
Hands up A1200 owners with GCC 2.x.x installed on there system, then we can
do some real-world measurements.
Eyvind Bernhardsen
[...]
> On the contrary. I think the point is to see which is the best
> trade-off: "32 bit bus, no cache, 14.4MHz" or "16 bit bus, cache, 16MHz".
> A1200 has no cache, Falcon has 16-bit bus.
Um, yes. There IS also the small point that the 1200 uses an '020, while
the Falcon uses an '030.
> I expect that a benchmark could be written which makes either more impressive.
> A real test would be to do something real and compile the code with GNU C on
> both machines.
Hmm... That depends on how good the GCC port is, though... What you want
is a machine code benchmark that doesn't fit in the cache (no "serious"
benchmarks do, I think %), but leave the caches on. Running high-speed
loops in the cache doesn't prove anything about anything.
> Warwick
Rickard Troedsson
EB> Because the REASON the Falcon is considered crippled is its 16-bit bus!
EB> The test *I'd* like to do would compare a 32-bit Falcon with the current
EB> 16-bit Falcon, caches off. Too bad there ain't no 32-bit Falcon around.
Okay, then I guess I'll have to write this for the THIRD time:
According benchmarks, the 16Mhz Falcon030 is 50% the speed of a 32Mhz TT030
(which has 32 bit FASTRAM).
Does that sound crippled to you?
Nope, not to me either.
+ _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
+ _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
+-------------- Official RATSoft/ST and Climax SoftWare Support Site +
Warwick Allison
>Because the REASON the Falcon is considered crippled is its 16-bit bus!
>The test *I'd* like to do would compare a 32-bit Falcon with the current
>16-bit Falcon, caches off. Too bad there ain't no 32-bit Falcon around.
The TT comes pretty close to the mark. And tests have shown that the
TT is approximately twice as fast. Since the processor is twice as fast,
you could very fairly guess that when running at half the speed it would
operate at near to the speed of the Falcon... yet the Falcon has 16 bit
bus while the TT has a 32 bit bus.
(For those who doubt this last statement, the details as I understand
them are that there is a 32bit but from RAM to CPU in all except the
first machines which had a 16bit bus, and a 16MHz CPU [ie. the same
as the Falcon !!], the TT has a 64bit path from RAM to video, and there
is no measurable difference in performance in any mode [my experience])
Warwick Allison
>A _256 byte_ cache has not a very high hit rate except for these benchmarks.
Wrong. Grab some real-world code and COUNT the number of loops that are
less than 256 bytes. You will be amazed. Do you think Motorola just put
the 512 bytes of cache in the 68030 so it would run well on artificial
benchmarks? Motorola doesn't think the computer industry is full of fools
(unlike Intel, with their 8048638808286088 chunk of chip which has more
escape characters than a TV prison).
Warwick Allison
>>Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
>>than the A1200. Final.
>The benchmarks were biased towards 030, display modes were chosen that make
>the Falcon look good and much information about the setup was missing.
>Real-world applications will be a complete different thing, so will be
>neutral benchmarks.
Post them then. The only way to argue that a benchmark is biased is to
give an example of what you consider is "neutral". In fact, try to find
some examples which show the A1200 in a brighter light - that's fine too.
Can you do it?
A.S.C.Pomianowski
>>>Michael van Elst
>>- Andy.
>This is awfully funny...people are screaming "Let's see the benchmarks!" Then,
>when the benchmarks finally come out, they're not "good enough" for you. Give
>me a break!
I was not among those 'screaming' for benchmarks, although I was interested
in seeing results. If you felt that the benchmarks that were posted were
representative of 'real' performance then you are only deluding yourself.
The benchmarks would certainly show the Falcon in a somewhat better light
than they should. I'm saying this, and I'm a Falcon owner - figure out for
yourself if the benchmarks were really 'good enough'. Benchmark results are
always questionable anyway, but these benchmarks are definitely naive and
I would not place any wager on the accuracy of the results obtained.
- Andy.
A.S.C.Pomianowski
>In article <26plhk$u...@info2.rus.uni-stuttgart.de>, zcam...@rpool9.rus.uni-stuttgart.de (Heiko Hartmann) writes:
> Well, let's see how fair are your benchmarks...
>|> Notes:
>|> The A1200 has NO FastRAM (if there is an Amiga-User with FastRAM: please
>|> type in the benchmarks und post the time the A1200 needs!). Sorry, but i
>|> can't get one with FastRAM.
Note this statement carefully.
>|> bench1:
[...]
>|> Problems that still make your benchmark not reliable:
[...]
> 3. You didn't try the benchmark with words on a lower resolution, less
> colors mode on the A1200 and F30.
Hmmm... Ok, I'll let you get away with this statement this time.
>|> bench2:
[...]
> 3. You ran *ALL* the benchmarks in at 60Hz, in which the bus contention
> on the A1200 starts to make a stronger mark. If you had Fast RAm
> the results would be damn different.
But I won't let you get away with it this time.
What resolution do _you_ suggest he runs the tests in? He has used the
same resolutions on both machines - if the A1200 has bad bus contention in these
modes and the Falcon doesn't then _TOUGH COOKIES_. The A1200 bus contention
is obviously crippling its performance, and this is a factor that must be
taken into account, as it would cripple its performance in real operation as
well. You want benchmarks that show the 'crippling' effect of the Falcon's
16 bit bus in a bad light, but you want the same benchmarks to be run in a
video mode that conceals the A1200's bus contention? That's _very_ hypocritical
I'm afraid.
The A1200's bus contention is as much a factor in its performance as the
Falcon's 16 bit memory bus.
I recall people in this group making a big thing about the Falcon's bus
contention in its bigger video modes when it first appeared. Are you
saying that the A1200's bus contention is _worse_ than the Falcon's in any
given video mode unless you add Fast RAM?
Now before you start going on about how you can add x Megs of Fast RAM
to the A1200 for the same price as a Falcon, the original poster stated very
clearly, more than once, that he was using a base A1200 with no Fast RAM
since he did not have access to an upgraded one. By all means run some
benchmarks on an upgraded A1200 against a Falcon and tell us the results,
just don't criticise the original poster for using what was available to him.
I do concede that the Fast RAM will improve the A1200's performance, but
let's just have a range of results that show how the machines fare given
various different hardware configurations.
Before we proceed we must get straight in our minds what we are comparing?
Are we comparing a base Falcon (1 Meg no HD) with a base A1200? Are
we allowing the A1200 to be upgraded with FastRAM to make up the price
differential?
[...]
>|> bench3:
> 3. Same comment of running @60Hz with no fast ram.
Tough. I agree that the benchmarks themselves are not representative, but
this comment about the choice of video modes is just daft. If the video
modes chosen are the same, then that aspect (at least) of the benchmark is
fair. Period.
>|> I'm waiting for the figures of an Amiga 1200 with FastRAM...
See, I told you he stated clearly the conditions he was using. I would
assume that he did not disable the 68EC020's instruction cache unless he
states otherwise. :-)
- Andy.
Michael van Elst
>What a crock. If the timeslice is, say, 200ms, then you've got 3 million
>clock cycles that can take advantage of locality of reference*.
Of course a timeslice is more 5..20 milliseconds and a multitasking system
usually makes more use of interrupts. With a small 256 Byte cache this
becomes noticable.
Michael van Elst
>>Real-life programs are larger than the cache.
>But real-life loops are not. Do you think they put caches in chips
>for no reason? Are you aware that many chips have over 1/3 of the
>silicon devoted to cache?
>Numerous experiments have been done with real-world code and found
>that a cache seriously enhances performance. There are a lot of other
>things you can do with 1/3 of your silicon (eg. shifters, fast multipliers,
>etc.)
And now back to reality. We were talking about 68020 and 68030 which have
_small_ caches. Nothing even close to 1/3 of your silicon.
If you do 'numerous experiments' on these CPUs you will see that you either
have loops larger than the cache or loops that extensively hit memory for
data with say a Mandelbrot set calculation being a rare exception.
Stefan Boberg
>In a message of 10 Sep 93 19:21:39, Eyvind Bernhardsen wrote:
>EB> Well, since the entire point is to see how the Falcon is degraded by
>EB> its 16-bit memory access, using a cache defeats the purpose of the
>EB> benchmarks...
>The entire point is to show the Amiga fanatics that claim the A1200 to be
>*FASTER* than the Falcon that it's a GAMES MACHINE ..
And the Falcon is.... ? What is it, anyway?
Let's just say that they are both hobby machines. Both can be used as
tools for entertainment and programming.
>+ _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
>+ _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
--
Stefan Boberg, Amiga/CD32/SEGA Programmer - Team 17 Software / LhA Devel.
EMail: bob...@lysator.liu.se FIDO: 2:204/404.7
========== Disclaimer: I only speak for myself - not Team 17. ===========
Rickard Troedsson
I> What is RATSoft? I used to use this name for PD I did on the 8bit Atari
*THE* BBS program for Ataris (and soon PCs) written by Steve Hughey, he's also
been around on the 8-bit and used the same name there .. (He used Rat Master as
alias)
If you want more info on RATSoft, the best BBS program for ANY platform, please
either call my BBS, or one of the support BBSs in US.
(I only have Steve's BBS number around right now, it's (909)/989-3381 .. )
+ _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
+ _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
Ricardo Hernandez Muchado
|> In a message of 10 Sep 93 19:21:39, Eyvind Bernhardsen wrote:
|>
|> EB> Well, since the entire point is to see how the Falcon is degraded by
|> EB> its 16-bit memory access, using a cache defeats the purpose of the
|> EB> benchmarks...
|>
|> The entire point is to show the Amiga fanatics that claim the A1200 to be
|> *FASTER* than the Falcon that it's a GAMES MACHINE ..
And if you believe those benchmarks show that, then I have a bridge
to sell you! Are you truly a programmer or what? You are not showing
it by that comment...
|>
|> + _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
|> + _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
|> +-------------- Official RATSoft/ST and Climax SoftWare Support Site +
|> + Synchron Assembly ------------ 2:200/612 - 7:102/102 - 90:1101/112 +
|> + SYNC -------- Opinions expressed are definitely not my own! -------+
|>
--
Klaus Pedersen
>individually. But in reality they always do 32bit prefetches. (On a 32bit
>bus the 030 would even burst in 4 32bit words in a row very quickly).
The '030 in the Falcon do have burst transfers enabled!
Which means that it "even burst in 8 16bit words in a row very quickly".
I think that this is the real reason that the Falcon is so much faster than
an A1200.
-Klaus
Ricardo Hernandez Muchado
|> mle...@specklec.mpifr-bonn.mpg.de (Michael van Elst) writes:
|> >Well, that would be true IF the 020 or 030 would fetch instructions
|> >individually. But in reality they always do 32bit prefetches. (On a 32bit
|> >bus the 030 would even burst in 4 32bit words in a row very quickly).
|>
|> The '030 in the Falcon do have burst transfers enabled!
How? Having a 16-bit datapath to memory defeats this Motorola capability.
Maybe you 'can enable' the '030, but that it works is another matter.
|> Which means that it "even burst in 8 16bit words in a row very quickly".
It is my understanding that this is *NOT SUPPORTED* by the 68030. You need
full 32-bit access for doing the burst.
|> I think that this is the real reason that the Falcon is so much faster than
|> an A1200.
That the Falcon is so much faster than the A1200 hasn't been proved yet.
If you belive in those benchmarks, I'll have a bridge to sell you.
|>
|> -Klaus
Michael van Elst
>The '030 in the Falcon do have burst transfers enabled!
>Which means that it "even burst in 8 16bit words in a row very quickly".
>I think that this is the real reason that the Falcon is so much faster than
>an A1200.
Sorry, it can have burst transfers enabled as much as it wants with no
effect.
From the "Enhanced 32b-Bit Microprocessor User's Manual", Section 7.3.7,
Page 7-60 (in the 3rd edition).
"The MC68030 allows burst filling only from 32-bit ports that terminate bus
cycles with /STERM and respond to /CBREQ by asserting /CBACK..."
Gavan Martin Moran
>Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
>A1200, before we do benchmarks?
No one said you HAD to do that, just that to be fair those things
should be done AS WELL to give a better perspective.
>Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
>than the A1200. Final.
Look at the marks. The F030 *WASN`T* `WAY faster`.
Base Amiga = 300 UKP
Base Falcon = 600 UKP (for the 1 meg model)
= 900 UKP (for the 4/65 RT claims is base)
Amiga =1/2 to 1/3 cost of Falcon
Remember the original `A1200 15pc faster post` Rickard?
You don`t seem to be able to follow the thread very well, nor do
seem to be able to retain information for longer than about the time
it takes you to read it....
gavan
Flip
Gavan Martin Moran <p916...@athmail1.causeway.qub.ac.uk> wrote:
>rickard....@troed.ct.se (Rickard Troedsson) writes ..
>
>>Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
>>A1200, before we do benchmarks?
>
> No one said you HAD to do that, just that to be fair those things
>should be done AS WELL to give a better perspective.
>
I'm a little lost as to why one should cut off the Falcon's caches. I agree
the 1200 should have FastRAM thrown in just to see what this standard option
would do for performance.
>>Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
>>than the A1200. Final.
>
>Look at the marks. The F030 *WASN`T* `WAY faster`.
>
I looked at it.. it certainly was faster than the A1200. The benchmarks
seemed to show that the 16-bit bus can be compensated for in some cases,
at least, by the onboard cache.
Now, of course, if we wanted to punish both machines, we should write a
large loop that exceeds the size of both machines' cache RAM and which
accesses longwords relative to some fixed address but at different offsets.
In fact, an excellent test of the system might be to play around with some
of the addressing modes with indirection and offset.
>Base Amiga = 300 UKP
>
>Base Falcon = 600 UKP (for the 1 meg model)
> = 900 UKP (for the 4/65 RT claims is base)
>
>Amiga =1/2 to 1/3 cost of Falcon
>
Also, Amiga with no HD and 2MB of no FastRAM. :)
The 900 ukp version of the Falcon has double the RAM and an 80MB IDE HD,
a 56001 DSP, SCSI-2 port, MIDI ports (standard), the usual serial and
parallel ports, two 9-pin joystick ports, two 15-pin jaguar compatible
joystick ports, and comes with AtariWorks, MultiTOS, and SpeedoGDOS.
Now, for some people, that's a lot of goodies, and might justify the price
difference. For some, it won't.
Incidentally, I've noticed the only person doing benchmarks was an Atari
Falcon user. Are the 1200 owners chicken? hehehehehee
P.S., has anyone tried benchmarking how fast these machines use their HDs?
Just the IDE ones, that is. I'm curious to see what they can do. Also,
it'd be nice to implement some kind of speed test for both machine's blitter
chips.
Gavan Martin Moran
> The A1200's bus contention is as much a factor in its performance as the
>Falcon's 16 bit memory bus.
NO ITS NOT!!!!!!
I can add FastRAM to my A1200 and eliminate the Bus contention
Can you add a 32 bit CPU<->memory bus to the Falcon??
> By all means run some
>benchmarks on an upgraded A1200 against a Falcon and tell us the results,
>just don't criticise the original poster for using what was available to him.
>I do concede that the Fast RAM will improve the A1200's performance, but
>let's just have a range of results that show how the machines fare given
>various different hardware configurations.
I have no criticism with the original poster. I agree with your
above remark.
gavan
Daniel M. Kruger
My question is:
Does Commodore read any of these posts on here.
The answer:
probably not, but I would like to be proved wrong by
either a response from someone associated w/ the company
or a better attitude towards the US market (if I owned C=
and saw how many U.S. users I was screwing over due to
any desire to obtain recognition for the Amiga, I would
feel pretty damn terrible)
Then again, they probably don't post because they would be subjected
to major flamage from those who are sick of their marketing strategies.
BTW-- Someone told me that C= fired their sales staff and replaced them
with the staff from NewTek. Is this true, or is this just a rumor?
Flip
>
Yes. It's easy. Add the 33mhz 68030 board which has up to 128MB FastRAM
available and away you go.
Gerald G. Washington
>
>Now, of course, if we wanted to punish both machines, we should write a
>large loop that exceeds the size of both machines' cache RAM and which
>accesses longwords relative to some fixed address but at different offsets.
>In fact, an excellent test of the system might be to play around with some
>of the addressing modes with indirection and offset.
A better test would be to run some useful software. That is what the
machines are used for.
-- Gerald
j braham levy
thought i'd killed this thread a few days ago but no someone out there
keeps on going.
Once again i think this thread has had more than a adequate airing here
and has really gone on too long. Surely you can continue this via direct
email if you really wanna argue such things as MIPs (Meaningless
Information Produced by ....). I'm certain other agree with me/ Lets get
back to talking Amiga.
braham
--
j braham levy | Control Systems Centre,
email: bra...@csc.umist.ac.uk | UMIST, PO Box 88,
Tel: +44-61-200-4672 | Manchester, M60 1QD, UK.
Fax: +44-61-200-4647 |
Ricardo Hernandez Muchado
|> rickard....@troed.ct.se (Rickard Troedsson) writes ..
|>
|> >Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
|> >A1200, before we do benchmarks?
|>
|> No one said you HAD to do that, just that to be fair those things
|> should be done AS WELL to give a better perspective.
|>
|> >Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
|> >than the A1200. Final.
Rickard, again: On - real - world- applications- the - caches- are-
shit- compared -to - their- effect- in - those-
benchmarks.
Maybe saying it slower you might be able to understand it.
|>
|> Look at the marks. The F030 *WASN`T* `WAY faster`.
Hell no. I am even starting to doub Rickard is a good programmer
at all. A good programmer will understand that those benchmark
give *tons* of bias since the fit in all the cache.
|>
|> Base Amiga = 300 UKP
|>
|> Base Falcon = 600 UKP (for the 1 meg model)
|> = 900 UKP (for the 4/65 RT claims is base)
|>
|> Amiga =1/2 to 1/3 cost of Falcon
|>
|> Remember the original `A1200 15pc faster post` Rickard?
Ah, not to mention that now the A1200 go a drop in price as well.
$400 US dollars, $640 gets you one with 65 meg hardisk. Just $199
and you have fast ram. Just $600 and you have 4 megs fast ram + 68030 @ 50Mhz
|>
|> You don`t seem to be able to follow the thread very well, nor do
|> seem to be able to retain information for longer than about the time
|> it takes you to read it....
|>
|> gavan
--
Ricardo Hernandez Muchado
|> In article <9309161411.AA01111@ash31>,
|> Gavan Martin Moran <p916...@athmail1.causeway.qub.ac.uk> wrote:
|> >rickard....@troed.ct.se (Rickard Troedsson) writes ..
|> >
|> >>Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
|> >>A1200, before we do benchmarks?
|> >
|> > No one said you HAD to do that, just that to be fair those things
|> >should be done AS WELL to give a better perspective.
|> >
|>
|>
|> I'm a little lost as to why one should cut off the Falcon's caches. I agree
|> the 1200 should have FastRAM thrown in just to see what this standard option
|> would do for performance.
Because it shows how fast the Falcon access the memory. Flip, I agree
that chaches are a benefit to a CPU, but when you have those 'benchmarks'
that FIT ENTIRELY IN BOTH CACHES (almost), DO YOU THINK THIS IS THE
REAL LIFE SITUATION?
Ask me, I have a '030. How much I benefit from the caches? An
average of 12% In the test where the guy cutted off the cache, the
Falcon was 75% slower. Hey! If my machine with the '030 benefited
with a 75% improvement on real-applications, I would never like upgrading
to a '040! (which is not true).
|> >>Benchmarks has been run on the BASE configurations, the Falcon was WAY faster
|> >>than the A1200. Final.
|> >
|> >Look at the marks. The F030 *WASN`T* `WAY faster`.
|> >
|>
|>
|> I looked at it.. it certainly was faster than the A1200. The benchmarks
|> seemed to show that the 16-bit bus can be compensated for in some cases,
|> at least, by the onboard cache.
The benchmark DIDN'T SHOW A DAMN THING! It all fits in both CACHES!
THIS IS NOT A REAL LIFE SITUATION.
AGAIN, I HAVE A '030 AND THE CACHES DO NOT GIVE 75% PERFORMANCE BOOST!
|>
|> Now, of course, if we wanted to punish both machines, we should write a
|> large loop that exceeds the size of both machines' cache RAM and which
|> accesses longwords relative to some fixed address but at different offsets.
|> In fact, an excellent test of the system might be to play around with some
|> of the addressing modes with indirection and offset.
Good. Another thing you can do is do a code that is Greater than
256 bytes, jump to another area after the main part has been executed
to flush the icache (instruction cache) and see what happens. This is
a more real-life situation: some instructions get cached others not.
|>
|>
|> >Base Amiga = 300 UKP
|> >
|> >Base Falcon = 600 UKP (for the 1 meg model)
|> > = 900 UKP (for the 4/65 RT claims is base)
|> >
|> >Amiga =1/2 to 1/3 cost of Falcon
|> >
|>
|> Also, Amiga with no HD and 2MB of no FastRAM. :)
It's not that much to add fast ram or hardisk. Here in the US
I can add for $600 a 68030 @ 50Mhz with 4 megs fast ram. That will
blow the Falcon out of the water performance wise, except where DSP
applications are concerned. And it's still way under the Falcon price.
Add the hardisk and is still cheaper than the Falcon.
|> The 900 ukp version of the Falcon has double the RAM and an 80MB IDE HD,
|> a 56001 DSP, SCSI-2 port, MIDI ports (standard), the usual serial and
|> parallel ports, two 9-pin joystick ports, two 15-pin jaguar compatible
|> joystick ports, and comes with AtariWorks, MultiTOS, and SpeedoGDOS.
|>
Read above.
|>
|> Now, for some people, that's a lot of goodies, and might justify the price
|> difference. For some, it won't.
|>
|>
|>
|> Incidentally, I've noticed the only person doing benchmarks was an Atari
|> Falcon user. Are the 1200 owners chicken? hehehehehee
No. I am not. But as you see, I can't get hold of a Falcon. I'm
in the US where the Falcon is virtually non-existant.
|>
|>
|> P.S., has anyone tried benchmarking how fast these machines use their HDs?
|> Just the IDE ones, that is. I'm curious to see what they can do. Also,
|> it'd be nice to implement some kind of speed test for both machine's blitter
|> chips.
Well, if we ever test blitters, let me remind of that doing some
graphic objects with the A1200 is easy with the HARDWARE sprites and
DUAL-PLAYFIELDS.
Eyvind Bernhardsen
Yeah, but you could do THAT for the (16-bit) A500. I'm not impressed.
Flip
Ricardo Hernandez Muchado <ric...@rchland.vnet.ibm.com> wrote:
>In article <279t0e$r...@cville-srv.wam.umd.edu>, cme...@wam.umd.edu ('Flip') writes:
>|> In article <9309161411.AA01111@ash31>,
>|> Gavan Martin Moran <p916...@athmail1.causeway.qub.ac.uk> wrote:
>|> >rickard....@troed.ct.se (Rickard Troedsson) writes ..
>|> >
>|> >>Tell me WHY we should turn off the Falcon's caches, and add FASTRAM to the
>|> >>A1200, before we do benchmarks?
>|> >
>|> > No one said you HAD to do that, just that to be fair those things
>|> >should be done AS WELL to give a better perspective.
>|> >
>|>
>|>
>|> I'm a little lost as to why one should cut off the Falcon's caches. I agree
>|> the 1200 should have FastRAM thrown in just to see what this standard option
>|> would do for performance.
>
> Because it shows how fast the Falcon access the memory. Flip, I agree
>that chaches are a benefit to a CPU, but when you have those 'benchmarks'
>that FIT ENTIRELY IN BOTH CACHES (almost), DO YOU THINK THIS IS THE
>REAL LIFE SITUATION?
>
Well, with a "real-life" situation we'd be using compiled C code that
would probably call the operating system if moving screen memory on
an Atari (hence, using the Blitter) or *could* use a small loop to
copy the memory over (hence, fit in the cache).
I'm not saying the cache is a real replacement for not giving the
CPU full 32-bit access to RAM, but consider this... most loops that
are that large won't be a series of move instructions, will they?
If you want to move 32,000 bytes, you could do:
move.w #31999,d0
.loop
move.b (a0)+,(a1)+
dbra d0,.loop
This will definitely fit in the cache. It'll also take advantage
of the special dbra 3-inst. loop capability in all 68010 or better
CPUs.
Now, I could break a cache if I do this:
REPT 32000
move.b (a0)+,(a1)+
ENDR
And this would probably be at LEAST as fast as the other set of
instructions on a 68000... in fact it would easily roast the dbra
method because there is no need for loop control. But how often
are we going to see this method implemented?
So let's say many loops are implmented with a hybrid approach, where
perhaps we jump into a "tower" of move instructions relative to the
PC when we determine the number of bytes/words/longs, etc.. to
move. If all of the code fits in the cache, it's going to look great
on a 68030.
Also, let's think about what the code that creates relatively large
uncacheable loops is doing.. is that code doing a lot of move ops?
Will there be a lot of addresses to decode or will it be using the
registers? Most compilers will optimize something that difficult to
utilize the registers, and we're not using an 8086 but a Motorola,
so we've got enough registers, even with compiler overhead, to
generate some decent code.
How about this.. since we all can't agree on the original benchmarks,
why not do a GCC compile on both platforms with 4MB of RAM on an IDE
drive and see which one finishes compiling the same code first?
(this'll test "real world" use...right?)
>
> The benchmark DIDN'T SHOW A DAMN THING! It all fits in both CACHES!
>THIS IS NOT A REAL LIFE SITUATION.
>
Well, let's find a "real life" situation. Geez.. calm down. :)
> AGAIN, I HAVE A '030 AND THE CACHES DO NOT GIVE 75% PERFORMANCE BOOST!
>
For all I know you may just have a bum '030 upgrade. :) Chill. :)
>|>
>|> Now, of course, if we wanted to punish both machines, we should write a
>|> large loop that exceeds the size of both machines' cache RAM and which
>|> accesses longwords relative to some fixed address but at different offsets.
>|> In fact, an excellent test of the system might be to play around with some
>|> of the addressing modes with indirection and offset.
>
> Good. Another thing you can do is do a code that is Greater than
>256 bytes, jump to another area after the main part has been executed
>to flush the icache (instruction cache) and see what happens. This is
>a more real-life situation: some instructions get cached others not.
>
Isn't that what I said? Run a loop of code that exceeds the size of
the cache?
And for all this talk of caching... doesn't the A1200 have a cache
on the 68020? Isn't this cache essentially the same as the '030s?
Even without FastRAM it shouldn't be too much slower than the
Falcon.
>|> Also, Amiga with no HD and 2MB of no FastRAM. :)
>
> It's not that much to add fast ram or hardisk. Here in the US
>I can add for $600 a 68030 @ 50Mhz with 4 megs fast ram. That will
>blow the Falcon out of the water performance wise, except where DSP
>applications are concerned. And it's still way under the Falcon price.
>Add the hardisk and is still cheaper than the Falcon.
>
This I'd like to see. :) The cheapest I've seen A1200s is $430 with
2MB of FastRAM and no hard drive. RAM ain't cheap right now, so
I'm leery of saying you can jack up your RAM cheaper than what
comes standard on a Falcon (i.e., the price on the Falcon hasn't
changed a bit since RAM went up).
Whose 68030 board? I asked about the CSA Shotgun in your .signature
at Buried Treasure in Rockville, MD and you know what they told me?
They said that in their experience, CSA boards aren't exactly the
most reliable and that they stopped carrying them. So what works
for you might not be available or possible for everyone else,
especially if their dealer advises against it.
>|>
>|> Incidentally, I've noticed the only person doing benchmarks was an Atari
>|> Falcon user. Are the 1200 owners chicken? hehehehehee
>
> No. I am not. But as you see, I can't get hold of a Falcon. I'm
>in the US where the Falcon is virtually non-existant.
>
That's funny. I'm in the USA too, and I have no problem seeing Falcons.
>
> Well, if we ever test blitters, let me remind of that doing some
>graphic objects with the A1200 is easy with the HARDWARE sprites and
>DUAL-PLAYFIELDS.
>
Hardware Sprites: in "real life" great for... the mouse cursor and
maybe animated icons?
Dual playfields: useful for... what? large virtual desktops or
something of that ilk. How often do you see that in a C compiler?
I'm not saying it ain't useful, but part of what makes the machine
look good on paper may not be the right solution for someone whose
uses would never utilize it. Remember when a lot of people were
saying "nice DSP in the Falcon but I'd never use it"?
Flip
Eyvind Bernhardsen <eyv...@Lise.Unit.NO> wrote:
>In article <27a4mc$d...@cville-srv.wam.umd.edu>, cme...@wam.umd.edu ('Flip') writes:
> > In article <9309161437.AA01136@ash31>,
> > Gavan Martin Moran <p916...@athmail1.causeway.qub.ac.uk> wrote:
> > >Can you add a 32 bit CPU<->memory bus to the Falcon??
> >
> > Yes. It's easy. Add the 33mhz 68030 board which has up to 128MB FastRAM
> > available and away you go.
>
>Yeah, but you could do THAT for the (16-bit) A500. I'm not impressed.
True. But that A500 wouldn't have 32-bit custom chips, each with 32
bit access to the "chipRAM" would it? It also would lack all of
the associated I/O ports and the DSP. It also would be running into
a 7.16mhz 16-bit bottleneck when it tried to go to "chipRAM" whereas
the Falcon's 33mhz 68030 board would go to a 16mhz 16-bit bottleneck.
Wow. That's real similar. :)
<the A500 would be 2X slower going to chipRAM than the Falcon just
based on clock speed alone!>
In fact, let's say the Falcon IS 15% slower than an A1200. How
much faster is an A1200 w/o FastRAM over an A500? Now, if you
jack up the A1200 to 33mhz 68030 and added some FastRAM I bet you
and all the whalers in your neck of the woods might be impressed. :)
<so chill..and don't be so biased... in fact, i might have an A1200
this Friday (tomorrow).. before i get my Falcon, even... if things
go right for me. :) it's all a matter of getting the right tool
for the right job, mon ami!>
Flip
Gerald G. Washington <ger...@seas.gwu.edu> wrote:
>
>A better test would be to run some useful software. That is what the
>machines are used for.
>
Name some useful software for either platform... :)
<just kidding>
Well, that would be nice, but what would we run that both have?
WordPerfect 4.2? PageStream 2.x? Dr. T's KCS 1.8? What would we
benchmark? How fast they scroll a screen of text? How many
simultaneous MIDI events they can catch at a timing resolution of
368 ppq?
The best comparison (imho) that both could do would be to compile some
C code on both using the "widely available" GNU C. We should even
use the standard, built-in IDE drives so that we get a feel for
how useful both machines are out of the box....
(of course, the Amiga owner will probably need 2 more MB of RAM to
get the A1200 up to 4MB to run the compiler... )
In fact, after the code is compiled... we can further test both
by making the code that IS compiled a benchmark. :) Then we can
see who is making the better port of their compiler. :)
Gregory R Block
: In article <9309161437.AA01136@ash31>,
In other words, yes, as long as you move the CPU off the motherboard, and
make that ram local.
Which isn't at all like adding fast ram to a 1200, and wouldn't do
anything to test the Falcon's architecture, invalidating the point.
Greg
--
(: (: (: (: Have you overdosed on smileys today? Why NOT!?! :) :) :) :)
(: Jurassic Park II :)
(: Crazed scientists at an upstate New York engineering school use :)
(: DNA to recreate a man-eating lesbian separatist from the 1970s... :)
(: -Wayne Bryant :)
(: (: (: (: (: (: (: (: (: (: (: (: :) :) :) :) :) :) :) :) :) Wubba :)
Gregory R Block
: True. But that A500 wouldn't have 32-bit custom chips, each with 32
: bit access to the "chipRAM" would it? It also would lack all of
Which doesn't affect the benchmark, which is the point: Adding a new CPU
with local ram has nothing to do with the architecture of the Falcon
unless it's accessing motherboard ram--that depends on the architecture
of the CPU/RAM card.
If you're going to compare a Falcon to an A1200, then you're stuck with
the Falcon's processor, and the a1200's processor. ANYONE can toss in an
accelerator card into either system, and have local ram, and get a
performance increase, but then you're benchmarking the card, and not the
system.
Get it?
: Wow. That's real similar. :)
Very similar, despite the narrow-minded attempt at brushing it off. The
parallels exist, architecturally, and that was the point of the statement.
John Henders
>A better test would be to run some useful software. That is what the
>machines are used for.
As has been suggested before. I agree. I think a relatively good
test would be to compile zoo on both machines with GNU C, then time
compressing and uncompressing the same large file on both machines.
--
John Henders GO/MU/E d* -p+ c+++ l++ t- m--- s/++ g+ w+++ -x+
Segments are for Worms
Flip
Ricardo Hernandez Muchado <ric...@rchland.vnet.ibm.com> wrote:
>|> I'm not saying the cache is a real replacement for not giving the
>|> CPU full 32-bit access to RAM, but consider this... most loops that
>|> are that large won't be a series of move instructions, will they?
>
>they are over a huge area (when moving memory). Not like those stupid
>benchmarks so that the data could fit in the cache.
>
Ok, my point is this:
1) if we're moving a large chunk of memory, especially graphic data, both
machines will use their Blitters, which have 32-bit access to RAM. No
crippling for the Falcon in that case.
2) if the loop being used to move a chunk of memory is a simple dbra loop
that fits in the cache, the Falcon will do fine.
Now if both of those possibilities don't exist in the code, the Falcon may
be punished. But then it becomes a matter of whether the compiler generates
code for #2 as opposed to unrolling the loops whenever possible. If it
doesn't unroll the loops, most of these loops will fit in the cache and
the Falcon would burn the A1200 in those cases.
<my real expectations: on a decent mix of code, i'd expect them to run
roughly equal...>
>|>
>|> So let's say many loops are implmented with a hybrid approach, where
>|> perhaps we jump into a "tower" of move instructions relative to the
>|> PC when we determine the number of bytes/words/longs, etc.. to
>|> move. If all of the code fits in the cache, it's going to look great
>|> on a 68030.
>
> True, wich is why the benchmark is misleading.
>
Well, please check the argument i have above.. basically it is determined
by the compiler's method for loops, and whether or not it unrolls it....
In fact, one interesting thing about GNU C will be that if we compile a
benchmark C program on both, and do an -funroll_all_loops (i think that
is it) it should generate code that works better on the A1200 provided
the 32-bit vs. 16-bit buss problem is as extreme as believed.
But on normal loops (which would fit in the CPU cache) the Falcon should
be a bit faster.
> No, but again, you are not doing loops all the times. *EVEN* when
>you do loops, you have to break from it if the loop is long. Remember
>the Vertical blanks interrupts? And if you are Multi-OSing then you have
>to do context switches, etc. THOSE BENCHMARKS ARE NOT A REAL LIFE SITUATION.
>
That's true, especially about the multitasking OS. However it's a fact
that even now, some people would run a Falcon single-tasking to eek out
performance for some applications that are memory or CPU hungry. After
all, MultiTOS is loadable.
>|> How about this.. since we all can't agree on the original benchmarks,
>|> why not do a GCC compile on both platforms with 4MB of RAM on an IDE
>|> drive and see which one finishes compiling the same code first?
>|>
>|> (this'll test "real world" use...right?)
>
> That would be a good test mixed with I/O. I would say this would
>be a very good test but not a definitive one (as it check IDE performance,
>which is true for some applications and not true for others). I AM SAYING
>THIS NOW EVEN IF THE A1200 turns out to be faster, ok? Your proposed test
>sounds like a good one where applications need to look for hardisk access.
>
Ok. I think it's agreeable that this be it. How about we all look for
a nice, large, gigantic, monolithic C program to compile?
In fact, one of those Obfuscated C code contest winners would probably
make the pre-processor do all kinds of contortions to figure out what
is going on. :)
<if we're really pressed, we could just bring down the source to a decent
sized unix app and go from there>
>|> Well, let's find a "real life" situation. Geez.. calm down. :)
>|>
>
> Ok, I'll calm down :-) But tell 'Rickard' to stop saying non-sense...
>
Ok... RICKARD! STOP SAYING NON-SENSE! :)
>The 12 Gauge is not their first design on the Amiga either. I CAN'T
>BELIEVE IS A BAD DESIGN.
>
>
Ok, well i am just repeating what i heard from a C= dealer who may or may
not have bias as to which accelerator is better.
>
> The Board I told you up the was the Microbotics, wich can be had
>for $600 with 4 megs fast ram and a 50Mhz '030. Actually checking out
>the last AmiWorld: $349 + $139 = $488. Hey, it's even $112 less than
>I said! You want to call them? Memory World: 1-800-CSA-XLR8.
>
Actually, i'll check them out to see if i can help my friend (and possibly
me, too) pick up a decent Ami setup.
<tomorrow i might wind up with a 1.7 Gb HD to throw on the ST... so...
this is all up in the air>
>|>
>|> Hardware Sprites: in "real life" great for... the mouse cursor and
>|> maybe animated icons?
>
> And games...
True.... but... GNU C (as a benchmark) wouldn't be a game. :)
>
>|>
>|> Dual playfields: useful for... what? large virtual desktops or
>|> something of that ilk. How often do you see that in a C compiler?
>
> For games, dude, for games.
But... Ricardo... I *have* a SNES and a Sega Genesis! :)
>
Flip
Gregory R Block <gbl...@csd4.csd.uwm.edu> wrote:
>In article <27aebi$2...@cville-srv.wam.umd.edu>, 'Flip' (cme...@wam.umd.edu) wrote:
>: True. But that A500 wouldn't have 32-bit custom chips, each with 32
>: bit access to the "chipRAM" would it? It also would lack all of
>
>Which doesn't affect the benchmark, which is the point: Adding a new CPU
>with local ram has nothing to do with the architecture of the Falcon
>unless it's accessing motherboard ram--that depends on the architecture
>of the CPU/RAM card.
>
Which benchmark are we talking about? The A1200 vs. Falcon one or just
general usage?
Surely having a 32-bit path from custom chips to RAM improves their speed.
The point is, the A500 with an 030 accelerator has 16-bit data path
from the custom chips to RAM, and a 16-bit path from the 030 to the
chipRAM (or any 16-bit fastRAM) and a 32-bit access to its local fastRAM.
The Falcon would have all custom chips operating 32-bits to/from chipRAM.
On a 16mhz buss, as opposed to a 7.16mhz buss. Clock speed is more than
doubled and buss width is doubled.
The CPU would have one similarity...the 68030 would have 16-bit access to
chipRAM but 32-bit access to the local fastRAM.
Now, there is that one similarity... but remembr that the 68030 is likewise
accessing that RAM off a 16mhz board. That means it's running at LEAST
2X faster than the '030 expansion on the A500, right?
(i.e., same bus width, > 2X increase in bus speed)
Factor in the fact that the Falcon's custom chips are running 32-bit to
RAM and are running more than 2X faster than the A500s chips and you'll
see the throughput is definitely way beyond an expanded A500.
>If you're going to compare a Falcon to an A1200, then you're stuck with
>the Falcon's processor, and the a1200's processor. ANYONE can toss in an
>accelerator card into either system, and have local ram, and get a
>performance increase, but then you're benchmarking the card, and not the
>system.
>
So if I compile something with a 33mhz 68030 in a Falcon in 3 seconds,
I shouldn't be happy?
Maybe you should talk to Ricardo and ask him about how he can't benchmark
his A1200 with the CSA 68030@50mhz, huh?
I say, if he's got it, and it works, it's admissable. He uses it, and
it works for him. If a Falcon owner has a 33mhz 68030, let him bench it.
(for now, if we compare base systems, which no one has done yet, both should
be interesting!)
Ricardo Hernandez Muchado
|> In article <1993Sep16.1...@rchland.ibm.com>,
|> Ricardo Hernandez Muchado <ric...@rchland.vnet.ibm.com> wrote:
|> >In article <279t0e$r...@cville-srv.wam.umd.edu>, cme...@wam.umd.edu ('Flip') writes:
|> >|> In article <9309161411.AA01111@ash31>,
|> >|> Gavan Martin Moran <p916...@athmail1.causeway.qub.ac.uk> wrote:
|> >|> >rickard....@troed.ct.se (Rickard Troedsson) writes ..
|> >|> >
[stuff deleted]
|> > Because it shows how fast the Falcon access the memory. Flip, I agree
|> >that chaches are a benefit to a CPU, but when you have those 'benchmarks'
|> >that FIT ENTIRELY IN BOTH CACHES (almost), DO YOU THINK THIS IS THE
|> >REAL LIFE SITUATION?
|> >
|>
|>
|> Well, with a "real-life" situation we'd be using compiled C code that
|> would probably call the operating system if moving screen memory on
|> an Atari (hence, using the Blitter) or *could* use a small loop to
|> copy the memory over (hence, fit in the cache).
Yep.
|>
|> I'm not saying the cache is a real replacement for not giving the
|> CPU full 32-bit access to RAM, but consider this... most loops that
|> are that large won't be a series of move instructions, will they?
Ah, but most things you do are not necesarily loops and when they are
they are over a huge area (when moving memory). Not like those stupid
benchmarks so that the data could fit in the cache.
|> If you want to move 32,000 bytes, you could do:
|>
|> move.w #31999,d0
|> ..loop
|> move.b (a0)+,(a1)+
|> dbra d0,.loop
|>
|>
|> This will definitely fit in the cache. It'll also take advantage
|> of the special dbra 3-inst. loop capability in all 68010 or better
|> CPUs.
|>
|> Now, I could break a cache if I do this:
|>
|> REPT 32000
|> move.b (a0)+,(a1)+
|> ENDR
|>
|> And this would probably be at LEAST as fast as the other set of
|> instructions on a 68000... in fact it would easily roast the dbra
|> method because there is no need for loop control. But how often
|> are we going to see this method implemented?
Read above.
|>
|>
|> So let's say many loops are implmented with a hybrid approach, where
|> perhaps we jump into a "tower" of move instructions relative to the
|> PC when we determine the number of bytes/words/longs, etc.. to
|> move. If all of the code fits in the cache, it's going to look great
|> on a 68030.
True, wich is why the benchmark is misleading.
|> Also, let's think about what the code that creates relatively large
|> uncacheable loops is doing.. is that code doing a lot of move ops?
No, but again, you are not doing loops all the times. *EVEN* when
you do loops, you have to break from it if the loop is long. Remember
the Vertical blanks interrupts? And if you are Multi-OSing then you have
to do context switches, etc. THOSE BENCHMARKS ARE NOT A REAL LIFE SITUATION.
|> Will there be a lot of addresses to decode or will it be using the
|> registers? Most compilers will optimize something that difficult to
|> utilize the registers, and we're not using an 8086 but a Motorola,
|> so we've got enough registers, even with compiler overhead, to
|> generate some decent code.
Read above again Flip.
|>
|> How about this.. since we all can't agree on the original benchmarks,
|> why not do a GCC compile on both platforms with 4MB of RAM on an IDE
|> drive and see which one finishes compiling the same code first?
|>
|> (this'll test "real world" use...right?)
That would be a good test mixed with I/O. I would say this would
be a very good test but not a definitive one (as it check IDE performance,
which is true for some applications and not true for others). I AM SAYING
THIS NOW EVEN IF THE A1200 turns out to be faster, ok? Your proposed test
sounds like a good one where applications need to look for hardisk access.
|> > The benchmark DIDN'T SHOW A DAMN THING! It all fits in both CACHES!
|> >THIS IS NOT A REAL LIFE SITUATION.
|> >
|> Well, let's find a "real life" situation. Geez.. calm down. :)
|>
Ok, I'll calm down :-) But tell 'Rickard' to stop saying non-sense...
|>
|> > AGAIN, I HAVE A '030 AND THE CACHES DO NOT GIVE 75% PERFORMANCE BOOST!
|> >
|>
|>
|> For all I know you may just have a bum '030 upgrade. :) Chill. :)
Flip: THE CSA accelerator is the FASTEST and one of the very best designed
accelerators available for the A1200. It was designed by CSA wich is
a Motorola consulting company and has been in business for more than 10 years.
The 12 Gauge is not their first design on the Amiga either. I CAN'T
BELIEVE IS A BAD DESIGN.
[stuff deleted]
|> Isn't that what I said? Run a loop of code that exceeds the size of
|> the cache?
More or less :-)
|>
|> And for all this talk of caching... doesn't the A1200 have a cache
|> on the 68020? Isn't this cache essentially the same as the '030s?
|> Even without FastRAM it shouldn't be too much slower than the
|> Falcon.
It has an instruction cache. It doesn't have a data cache.
And your fellow Atarian Heiko didn't mention whether he was running
with the '020 cache on or off, wich is another reason why I am so
skeptical.
But BTW, it still proves nothing. Hey, if the A1200 had a 68030
at the same speed of the Falcon, both machines should do almost
exactly the same result. Would this be fair even if this theoretical
A1200 with a '030 had 32-bit access to memory and the Falcon still
the 16-bit access on a real-life situation ? NO!
|> >|> Also, Amiga with no HD and 2MB of no FastRAM. :)
|> >
|> > It's not that much to add fast ram or hardisk. Here in the US
|> >I can add for $600 a 68030 @ 50Mhz with 4 megs fast ram. That will
|> >blow the Falcon out of the water performance wise, except where DSP
|> >applications are concerned. And it's still way under the Falcon price.
|> >Add the hardisk and is still cheaper than the Falcon.
|> >
|>
|>
|> This I'd like to see. :)
Well, see it. Which company do you want me to tell the phone #?
|> The cheapest I've seen A1200s is $430 with
|> 2MB of FastRAM and no hard drive.
It's now $399. (US)
|> RAM ain't cheap right now, so
|> I'm leery of saying you can jack up your RAM cheaper than what
|> comes standard on a Falcon (i.e., the price on the Falcon hasn't
|> changed a bit since RAM went up).
Call Memory World and see for yourself.
|> Whose 68030 board? I asked about the CSA Shotgun in your .signature
|> at Buried Treasure in Rockville, MD and you know what they told me?
|> They said that in their experience, CSA boards aren't exactly the
|> most reliable and that they stopped carrying them.
Baloney. Mine works just fine. The only problem I have seen is
the temperature, which all requires is that you have either a fan
or the machine in an air conditioning environment.
The Board I told you up the was the Microbotics, wich can be had
for $600 with 4 megs fast ram and a 50Mhz '030. Actually checking out
the last AmiWorld: $349 + $139 = $488. Hey, it's even $112 less than
I said! You want to call them? Memory World: 1-800-CSA-XLR8.
|> So what works
|> for you might not be available or possible for everyone else,
|> especially if their dealer advises against it.
No. This board works fine. Same goes for any expansion of the Falcon
too anyway (those that actually exist).
How much is the US Falcon? With what?
|> >|> Incidentally, I've noticed the only person doing benchmarks was an Atari
|> >|> Falcon user. Are the 1200 owners chicken? hehehehehee
|> >
|> > No. I am not. But as you see, I can't get hold of a Falcon. I'm
|> >in the US where the Falcon is virtually non-existant.
|> >
|>
|>
|> That's funny. I'm in the USA too, and I have no problem seeing Falcons.
Well, if you are talking about the real bird.... I mean, the one that
actually exists :-)
|> > Well, if we ever test blitters, let me remind of that doing some
|> >graphic objects with the A1200 is easy with the HARDWARE sprites and
|> >DUAL-PLAYFIELDS.
|> >
|>
|>
|> Hardware Sprites: in "real life" great for... the mouse cursor and
|> maybe animated icons?
And games...
|>
|> Dual playfields: useful for... what? large virtual desktops or
|> something of that ilk. How often do you see that in a C compiler?
For games, dude, for games.
|>
|> I'm not saying it ain't useful, but part of what makes the machine
|> look good on paper may not be the right solution for someone whose
|> uses would never utilize it. Remember when a lot of people were
|> saying "nice DSP in the Falcon but I'd never use it"?
True, but in my case I was one of those first to admit that the
Falcon's sound is awesome, and that the DSP is a very nice feature
indeed.
And, ok, I'll chill out :-)
Mike Farren
>It has come to my understanding that C= has an internet connection.
Of a sort, yes. You can't do ftp to cbmvax, however.
>My question is:
> Does Commodore read any of these posts on here.
Do you mean: Commodore engineering staff? Definitely yes. Do you mean:
Commodore upper management? Probably not. Not unusual - there are very
few companies whose upper management reads Usenet.
>Then again, they probably don't post because they would be subjected
>to major flamage from those who are sick of their marketing strategies.
Why do you think they're not? Remember where "post" comes from - as
in Office.
>BTW-- Someone told me that C= fired their sales staff and replaced them
>with the staff from NewTek. Is this true, or is this just a rumor?
Sure, right, NewTek would just let their marketing staff go.
Of *course* that's only a rumor.
--
Michael J. Farren far...@netcom.com
Unconnected with Commodore for almost two years, now!
Mike Farren
>The Falcon would have all custom chips operating 32-bits to/from chipRAM.
>On a 16mhz buss, as opposed to a 7.16mhz buss. Clock speed is more than
>doubled and buss width is doubled.
Are you saying that the Falcon's memory bus is 32 bits wide? If so,
what possible excuse could they have for limiting the CPU access
to memory to 16 bits, especially when the chosen CPU was designed
with a 32 bit bus from the beginning?
If your statement is true, my opinion of Atari Engineering goes from
feeling that they're not very good to feeling that they're completely
incompetent.
Rickard Troedsson
RH> That the Falcon is so much faster than the A1200 hasn't been proved yet.
RH> If you belive in those benchmarks, I'll have a bridge to sell you.
As long as no other benchmarks appear (The amigoids doesn't seem to WANT to do
the benchmarks .. ) these are the ones to judge by.
+ _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
+ _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
+-------------- Official RATSoft/ST and Climax SoftWare Support Site +
+ Synchron Assembly ------------ 2:200/612 - 7:102/102 - 90:1101/112 +
+ SYNC -------- Opinions expressed are definitely not my own! -------+
PS: Is that bridge red?
Rickard Troedsson
GM> I can add FastRAM to my A1200 and eliminate the Bus contention
GM>
GM> Can you add a 32 bit CPU<->memory bus to the Falcon??
Ofcoz, we can also add FastRAM!
Rickard Troedsson
RH> Rickard, again: On - real - world- applications- the - caches- are-
RH> shit- compared -to - their- effect- in - those-
RH> benchmarks.
RH>
RH> Maybe saying it slower you might be able to understand it.
Not, since it's bullshit. Why the H*LL do you think Motorola started using
chaches? Coz they speed up the processing power, in real world applications
ALSO!
RH> Hell no. I am even starting to doub Rickard is a good programmer
RH> at all. A good programmer will understand that those benchmark
RH> give *tons* of bias since the fit in all the cache.
I'm writing my own (assembler) programs to fit in the cache, so do all the
other ASM programmers .. The benchmarks are valid ..
(You wouldn't believe the speed of my newly developed 030-line routine in true
colour .. ahem .. )
RH> Ah, not to mention that now the A1200 go a drop in price as well.
RH> $400 US dollars, $640 gets you one with 65 meg hardisk. Just $199
RH> and you have fast ram. Just $600 and you have 4 megs fast ram + 68030 @
RH> 50Mhz
Where's the SCSI II, LAN, MIDI, 16 bit SOUND .. (just to name a few ...)
Rickard Troedsson
'> Yes. It's easy. Add the 33mhz 68030 board which has up to 128MB FastRAM
'> available and away you
Saw in AEO15 that Wizztronics was developing a ONE GIGABYTE FASTRAM board for
the Falcon ...
One Gig? Oops ..
Rickard Troedsson
JB> Information Produced by ....). I'm certain other agree with me/ Lets get
JB> back to talking Amiga.
then move to an Amiga newsgroup
Rickard Troedsson
RH> Well, if we ever test blitters, let me remind of that doing some
RH> graphic objects with the A1200 is easy with the HARDWARE sprites and
RH> DUAL-PLAYFIELDS.
Oh. but then we must compare sound-quality, and by all means, we must rotate
some true colour pictures ..
BTW; What do you think I get if I split the True Colour mode into two
8-bitplane playfields?
Dual Playfield in 256 colours.
Michael van Elst
>Not, since it's bullshit. Why the H*LL do you think Motorola started using
>chaches? Coz they speed up the processing power, in real world applications
>ALSO!
No, they just make it possible to reduce the slow down caused by slow
memory systems.
Regards,
--
Michael van Elst
UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p55...@mpirbn.mpifr-bonn.mpg.de
"A potential Snark may lurk in every tree."
Heiko Hartmann
Well, let's see if you can write a becnhmark which considers every
eventuality...
By the way: I didn't mention that this is a perfect benchmark. How could i?
> Problems that still make your benchmark not reliable:
>
> 1. Benchmark is short. Fits entirely inside the instruction cache
> of the '030, and some data inside the data cache. In this benchmark
> the effects of the cache are just too generous.
Yes this is a problem. In normal programms there is a cache hit rate of
70-80%. Maybe you can write a benchmark with these hit rates?
> 2. No mention if the '020 cache of the A1200 was turned on or off
The caches in both machines were turned on. I don't know anyone turning
his caches off when he wants to run time-intensive programs.
> 3. You didn't try the benchmark with words on a lower resolution, less
> colors mode on the A1200 and F30.
Sorry! I didn't have the time (after 3 hours you want to make other things
than benchmarks). You can calculate the times if you want.
> 3. You ran *ALL* the benchmarks in at 60Hz, which the bus contention
> on the A1200 starts to make a stronger mark. If you had Fast RAm
> the results would be damn different.
Sure. What's your point?
Both machines were in 60Hz-mode. Where is the problem?
> I did, check my comments. The information you present is not reliable. Did
>you see what happened when you turned the Falcon caches off? The machine
>ran 75% slower in the first test. If you are telling me that on a real-world
>application (Word processor, DTP, Database, etc.) you gain 75% more speed
>on a '030, I have a bridge to sell for you.
Most programs gain 50% or more (see my earlier posting).
Without caches, the test has needed 43.1 s, with caches 21.3 s. This is an
improvement of 50.5800464...% but never 75%.
It is very hard to write a program which does not fit in the caches :)
Ciao, Heiko.
(zcam...@rpool9.rus.uni-stuttgart.de)
Heiko Hartmann
'Flip' <cme...@wam.umd.edu> wrote:
>The 900 ukp version of the Falcon has double the RAM and an 80MB IDE HD,
>a 56001 DSP, SCSI-2 port, MIDI ports (standard), the usual serial and
>parallel ports, two 9-pin joystick ports, two 15-pin jaguar compatible
>joystick ports, and comes with AtariWorks, MultiTOS, and SpeedoGDOS.
Don't forget that the A1200 only has a DD floppy drive :-)
I soon will present my 4. benchmark:
It is a 257 MByte loop which surely will exceed the internal caches. I will
post it soon...
>Incidentally, I've noticed the only person doing benchmarks was an Atari
>Falcon user. Are the 1200 owners chicken? hehehehehee
Ouh, hard...
Aehem... i am still waiting for the A1200 with FastRAM figures.
>P.S., has anyone tried benchmarking how fast these machines use their HDs?
>Just the IDE ones, that is. I'm curious to see what they can do. Also,
>it'd be nice to implement some kind of speed test for both machine's blitter
>chips.
Make it so Number one...
Ciao, Heiko.
(zcam...@rpool9.rus.uni-stuttgart.de)
Heiko Hartmann
>average of 12% In the test where the guy cutted off the cache, the
>Falcon was 75% slower. Hey! If my machine with the '030 benefited
>with a 75% improvement on real-applications, I would never like upgrading
>to a '040! (which is not true).
Here is the reply form the "guy":
The test without caches neede 43.1 s and the test with caches needed 21.3 s.
That means: the F30 is 100% slower without caches or 50% faster with caches.
The improvement is 50%. I don't know how to get 75% with these figures...
Nearly all programs that i have tested get a 50% improvement caused by
the caches. These tests are not as easy as it seems because you only have to
check the calculation time (many programs spend a lot of time with I/O).
Ciao, Heiko.
(zcam...@rpool9.rus.uni-stuttgart.de)
Borge Noest
>As long as no other benchmarks appear (The amigoids doesn't seem to WANT to do
>the benchmarks .. ) these are the ones to judge by.
*Sigh*
Ok, as I intended to do it anyway I can just as well promise it now:
I'll write a set of benchmarks that will test just about every part of the
architecture that I can think of. Some of it will be F030 positive, some
will be 030 positive, some will perhaps be 1200 positive. What do I know, I
only have a 68000 on my Amiga right now. (But rest assured, I'll upgrade
very soon.)
Then you people can go back and test the programs, ok?
(I guess it might be as many as 64-128 different benchmarks, but with a few
macros it shouldn't be too hard to squeeze into an article.)
>+ _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
--
|/// bor...@stud.cs.uit.no (Boerge Noest) | Amiga B2000 \\\|
|// Box 218, 9001 Tromsoe, Norway | Remember to :-) when needed \\|
|/ The worlds northernmost university | Life is worth living. \|
#Disclaimer: This university does not speak for me.
Michael van Elst
>Yes this is a problem. In normal programms there is a cache hit rate of
>70-80%. Maybe you can write a benchmark with these hit rates?
In normal programs you have a hit rate of about 50%.
>It is very hard to write a program which does not fit in the caches :)
Well. That says something about the size of programs you write.
Michael van Elst
>I soon will present my 4. benchmark:
>It is a 257 MByte loop which surely will exceed the internal caches. I will
>post it soon...
It's probably a 257 _Byte_ loop. This does exceed the cache but as the
020 and 030 instruction cache is direct mapped it will just have to reload
a single longword in each pass through the loop. You need a loop size of
>= 512 Bytes to make any caching effects invisible.. but then you could
simply turn the caches off.
If the 257 Byte loop doesn't use any 030 pecularities, doesn't use data
memory and keeps the first loop instruction longword aligned you should
see exactly the time needed to prefetch a longword. This is one 32bit
access for the A1200 and two 16bit accesses for the F30.
Michael van Elst
>Here is the reply form the "guy":
>The test without caches neede 43.1 s and the test with caches needed 21.3 s.
>That means: the F30 is 100% slower without caches or 50% faster with caches.
>The improvement is 50%.
Well, halving the time needed is surely an improvment by 100%. Anyway, the
caches become more valuable (for small programs) the slower the memory is.
For large programs the memory speed becomes more important.
Ricardo Hernandez Muchado
|> In article <1993Sep16....@rchland.ibm.com>,
|> Ricardo Hernandez Muchado <ric...@rchland.vnet.ibm.com> wrote:
|> >|> I'm not saying the cache is a real replacement for not giving the
|> >|> CPU full 32-bit access to RAM, but consider this... most loops that
|> >|> are that large won't be a series of move instructions, will they?
|> >
|> > Ah, but most things you do are not necesarily loops and when they are
|> >they are over a huge area (when moving memory). Not like those stupid
|> >benchmarks so that the data could fit in the cache.
|> >
|>
|>
|> Ok, my point is this:
|>
|> 1) if we're moving a large chunk of memory, especially graphic data, both
|> machines will use their Blitters, which have 32-bit access to RAM. No
|> crippling for the Falcon in that case.
Don't assume that much. If you are making an animation you'll have
to use the CPU to move memory regardless of how wonderfull the blitter is.
And second, you have to take into consideration that the Falcon's blitter
has to do (for bobs) I think it was twice or three operations per one
Amiga blitter operation.
|> 2) if the loop being used to move a chunk of memory is a simple dbra loop
|> that fits in the cache, the Falcon will do fine.
For the instruction cache yes, but not for the data cache, wich is
what happens in those 'benchmarks'. And again, this is not the
real-world situation, as programs do not consist of this.
|> Now if both of those possibilities don't exist in the code, the Falcon may
|> be punished.
AND IT IS BEING PUNISHED. Why? Because in a real-life situation
this is not the case.
And you know what? NO MATTER HOW MUCH ATARI PEOPLE ARGUE ABOUT THIS
BENCHMARKS, THEY SHOW NOTHING. AGAIN, I GOT A '030 COMPUTER AND
THE CACHES DO NOT GIVE IT 75% IMPROVEMENT THAT IN THE FIRST BENCHMARK
THE CACHES GAVE TO THE FALCON. THIS CLEARLY SHOWS THAT THE BENCHMARKS
DO NOT SHOW ACTUAL WORLD PERFORMANCE WITH REAL APPLICATIONS.
Sorry Flip, but I can't see nothing more *OBVIOUS* that what I am saying
with the above.
|> But then it becomes a matter of whether the compiler generates
|> code for #2 as opposed to unrolling the loops whenever possible. If it
|> doesn't unroll the loops, most of these loops will fit in the cache and
|> the Falcon would burn the A1200 in those cases.
God, read above!
|>
|> <my real expectations: on a decent mix of code, i'd expect them to run
|> roughly equal...>
I doubt it.. Maybe equal if the A1200 has no fast ram, if the A1200
has fast ram , I really doubt it.
|> >|> So let's say many loops are implmented with a hybrid approach, where
|> >|> perhaps we jump into a "tower" of move instructions relative to the
|> >|> PC when we determine the number of bytes/words/longs, etc.. to
|> >|> move. If all of the code fits in the cache, it's going to look great
|> >|> on a 68030.
|> >
|> > True, wich is why the benchmark is misleading.
|> >
|>
|> Well, please check the argument i have above.. basically it is determined
|> by the compiler's method for loops, and whether or not it unrolls it....
Flip, A REAL WORLD APPLICATION DOES NOT CONSIST OF A STUPID LOOP.
And again, no matter how people here want to justify those benchmarks,
I have SHOWN THEY ARE NOT VALID! NO MATTER HOW MUCH SPECULATION!
MY COMPUTER DOESN'T GET 75% IMPROVEMENT!
|> In fact, one interesting thing about GNU C will be that if we compile a
|> benchmark C program on both, and do an -funroll_all_loops (i think that
|> is it) it should generate code that works better on the A1200 provided
|> the 32-bit vs. 16-bit buss problem is as extreme as believed.
|>
|> But on normal loops (which would fit in the CPU cache) the Falcon should
|> be a bit faster.
|>
|>
|> > No, but again, you are not doing loops all the times. *EVEN* when
|> >you do loops, you have to break from it if the loop is long. Remember
|> >the Vertical blanks interrupts? And if you are Multi-OSing then you have
|> >to do context switches, etc. THOSE BENCHMARKS ARE NOT A REAL LIFE SITUATION.
|> >
|>
|>
|> That's true, especially about the multitasking OS. However it's a fact
|> that even now, some people would run a Falcon single-tasking to eek out
|> performance for some applications that are memory or CPU hungry. After
|> all, MultiTOS is loadable.
Flip, you still have to deal with interrupts and if I am correct,
the Falcon as all computers as a VBLANK interrupt. That's 1/60 of a second
it get's interrupted + any other possible interrupts.
|>
|>
|> >|> How about this.. since we all can't agree on the original benchmarks,
|> >|> why not do a GCC compile on both platforms with 4MB of RAM on an IDE
|> >|> drive and see which one finishes compiling the same code first?
|> >|>
|> >|> (this'll test "real world" use...right?)
|> >
|> > That would be a good test mixed with I/O. I would say this would
|> >be a very good test but not a definitive one (as it check IDE performance,
|> >which is true for some applications and not true for others). I AM SAYING
|> >THIS NOW EVEN IF THE A1200 turns out to be faster, ok? Your proposed test
|> >sounds like a good one where applications need to look for hardisk access.
|> >
|>
|>
|> Ok. I think it's agreeable that this be it. How about we all look for
|> a nice, large, gigantic, monolithic C program to compile?
That depends on what you say by 'that this be it.' I said it would
be a good test of a situation where programs use hardisk I/O. IT ISN'T
A GOOD BENCHMARK FOR SAY, A WORDPROCESSOR OR A DESKTOP PUBLISHER, OR
A SPREADSHEET BECAUSE THOSE DON'T USE I/O A LOT.
Sorry for 'shouting' but I just wanted to make clear that I agree
depending on what you mean by the 'that this be it.' I don't think
that this test alone will prove everything, but a particular set
of applications. I say do this test and others.
For example, say that you use a SCSI hardisk on the Falcon, I would
expect the Falcon to blow away the A1200 IDE. But that still doesn't mean
that the A1200 (this is all theoretical, just to show you my point)
would be slower using a wordprocessor, ray tracing or something like that
because the I/O is not involved in these other applications.
You proved that the Falcon is faster compiling when using a SCSI
hardisk.
Do you understand what I am saying? (no flames, no irony intended)
|> In fact, one of those Obfuscated C code contest winners would probably
|> make the pre-processor do all kinds of contortions to figure out what
|> is going on. :)
He he...
[stuff deleted]
|> >
|> > Ok, I'll calm down :-) But tell 'Rickard' to stop saying non-sense...
|> >
|>
|>
|>
|> Ok... RICKARD! STOP SAYING NON-SENSE! :)
Ah, thanks, I needed you to tell him that :-) I feel better now :-)
|>
|>
|> >The 12 Gauge is not their first design on the Amiga either. I CAN'T
|> >BELIEVE IS A BAD DESIGN.
|> >
|> Ok, well i am just repeating what i heard from a C= dealer who may or may
|> not have bias as to which accelerator is better.
And I am just telling you my experience with it and the company that
manufactures it :-)
|> > The Board I told you up the was the Microbotics, wich can be had
|> >for $600 with 4 megs fast ram and a 50Mhz '030. Actually checking out
|> >the last AmiWorld: $349 + $139 = $488. Hey, it's even $112 less than
|> >I said! You want to call them? Memory World: 1-800-CSA-XLR8.
|> >
|>
|> Actually, i'll check them out to see if i can help my friend (and possibly
|> me, too) pick up a decent Ami setup.
|>
|> <tomorrow i might wind up with a 1.7 Gb HD to throw on the ST... so...
|> this is all up in the air>
|>
|>
|> >|>
|> >|> Hardware Sprites: in "real life" great for... the mouse cursor and
|> >|> maybe animated icons?
|> >
|> > And games...
|>
|>
|> True.... but... GNU C (as a benchmark) wouldn't be a game. :)
:-) True.
|>
|>
|> >
|> >|>
|> >|> Dual playfields: useful for... what? large virtual desktops or
|> >|> something of that ilk. How often do you see that in a C compiler?
|> >
|> > For games, dude, for games.
|>
|>
|> But... Ricardo... I *have* a SNES and a Sega Genesis! :)
Well, I have an SNES too, so what? :-) AGA can make awesome
games, and they are just finally starting to come out :-)
|>
|>
|> >
--
Ricardo Hernandez Muchado
|> In a message of 16 Sep 93 11:19:34, Ricardo Hernandez Muchado wrote:
|>
|> RH> That the Falcon is so much faster than the A1200 hasn't been proved yet.
|> RH> If you belive in those benchmarks, I'll have a bridge to sell you.
|>
|> As long as no other benchmarks appear (The amigoids doesn't seem to WANT to do
|> the benchmarks .. ) these are the ones to judge by.
Why? BECAUSE THE BENCHMARKS PROVE NOTHING!
DON'T YOU JUST GET IT? I have a '030 setup and enabling the caches
on my applications DO NOT GIVE ME A 75% PERFORMANCE BOOST THAT THE
FIRST BENCHMARK DID TO THE FALCON. THEY GIVE ME LIKE 12% ON AVERAGE.
NO MATTER HOW MUCH YOU SAY: "DUH, Amigoids don't WANT to do
the benchmarks", ETC. IS BECAUSE IT PROVES NOTHING!
ARE YOU A REAL PROGRAMMER OR WHAT? ISN'T MY EXPLANATION ABOVE
SO HARD TO UNDERSTAND?
|>
|> + _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
|> + _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
|> +-------------- Official RATSoft/ST and Climax SoftWare Support Site +
|> + Synchron Assembly ------------ 2:200/612 - 7:102/102 - 90:1101/112 +
|> + SYNC -------- Opinions expressed are definitely not my own! -------+
|>
|> PS: Is that bridge red?
Any color you want, I just want to get your money by selling it to you.
It seems I'll be able to very easily...
Ricardo Hernandez Muchado
|>
|> RH> Rickard, again: On - real - world- applications- the - caches- are-
|> RH> shit- compared -to - their- effect- in - those-
|> RH> benchmarks.
|> RH>
|> RH> Maybe saying it slower you might be able to understand it.
|>
|> Not, since it's bullshit. Why the H*LL do you think Motorola started using
|> chaches? Coz they speed up the processing power, in real world applications
|> ALSO!
Read my other postings... They speed up performance but not by 75%!!!
This is how much it sped it up for the Falcon in the first 'benchmark.'
|>
|> RH> Hell no. I am even starting to doub Rickard is a good programmer
|> RH> at all. A good programmer will understand that those benchmark
|> RH> give *tons* of bias since the fit in all the cache.
|>
|> I'm writing my own (assembler) programs to fit in the cache, so do all the
|> other ASM programmers .. The benchmarks are valid ..
A word processor? A Spreadsheet? A ray tracer? An Image processing
program? No way you can fit those in a 256-byte cache. Are you using
MultiTos? Kiss the caches good bye on a lot of occasions.
Have you ever heard of Vertical Blank interrupts?
|> (You wouldn't believe the speed of my newly developed 030-line routine in true
|> colour .. ahem .. )
Ah, a demo? Good show of a real-world application.
And I guees your routine gets called from elsewhere, which again flushes
the cache at some point. THis is not to say that the '030 doesn't benefit,
but that it's not the way you put it.
|>
|> RH> Ah, not to mention that now the A1200 go a drop in price as well.
|> RH> $400 US dollars, $640 gets you one with 65 meg hardisk. Just $199
|> RH> and you have fast ram. Just $600 and you have 4 megs fast ram + 68030 @
|> RH> 50Mhz
|>
|> Where's the SCSI II, LAN, MIDI, 16 bit SOUND .. (just to name a few ...)
LAN-> get the CSA card then. Add about $200 and you'll get arcnet.
Leaps and bound faster than your Lan. Midi? Add $50.
I'm missing the SCSI II and 16-bit sound but then,
You have to add sprites and dual-playfields to your system anyway
and a 24-bit color card or something better than the stupid
64k colors 'true color'
|>
|> + _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
|> + _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
|> +-------------- Official RATSoft/ST and Climax SoftWare Support Site +
|> + Synchron Assembly ------------ 2:200/612 - 7:102/102 - 90:1101/112 +
|> + SYNC -------- Opinions expressed are definitely not my own! -------+
|>
--
Ricardo Hernandez Muchado
|>
|> RH> Well, if we ever test blitters, let me remind of that doing some
|> RH> graphic objects with the A1200 is easy with the HARDWARE sprites and
|> RH> DUAL-PLAYFIELDS.
|>
|> Oh. but then we must compare sound-quality, and by all means, we must rotate
|> some true colour pictures ..
True. Every machine has its strengths.
|>
|> BTW; What do you think I get if I split the True Colour mode into two
|> 8-bitplane playfields?
|>
|> Dual Playfield in 256 colours.
BZZZZZZZZZT! Thanks for playing.
Good luck doing that. YOu know, dual-playfields is not just
separating 'bit planes'. It's like having a whole screen on top
of another which is like a huge sprite in top of the other.
THERE's NO WAY THE FALCON CAN DO THE SAME.
|>
|> + _______/ --------SiG(tm)------------ rickard....@troed.ct.se +
|> + _/roed ---- SysOp on Sarcastic Existence! - 16.8DS - +46-451-91002 +
|> +-------------- Official RATSoft/ST and Climax SoftWare Support Site +
|> + Synchron Assembly ------------ 2:200/612 - 7:102/102 - 90:1101/112 +
|> + SYNC -------- Opinions expressed are definitely not my own! -------+
|>
--
Klaus Pedersen
>Sorry, it can have burst transfers enabled as much as it wants with no
>effect.
Yes, you are right, unless the Falcon is real strange - 4 latches should
do, but then why not a 32 bit bus in the first case.
Because there wasn't any gain in throughput to speak of?
I concluded that the Falcon used burst fill because it's cacr read 0x3111,
which means write-allocate, data-cache, instruction-cache, data-burst,
instruction-burst.
It is probaly a leftover from the TT...
-Klaus
Flip
Ricardo Hernandez Muchado <ric...@rchland.vnet.ibm.com> wrote:
>In article <27b7e4$8...@cville-srv.wam.umd.edu>, cme...@wam.umd.edu ('Flip') writes:
>|> In article <1993Sep16....@rchland.ibm.com>,
>|> Ricardo Hernandez Muchado <ric...@rchland.vnet.ibm.com> wrote:
>|> >|> I'm not saying the cache is a real replacement for not giving the
>|> >|> CPU full 32-bit access to RAM, but consider this... most loops that
>|> >|> are that large won't be a series of move instructions, will they?
>|> >
>|> > Ah, but most things you do are not necesarily loops and when they are
>|> >they are over a huge area (when moving memory). Not like those stupid
>|> >benchmarks so that the data could fit in the cache.
>|> >
>|>
>|>
>|> Ok, my point is this:
>|>
>|> 1) if we're moving a large chunk of memory, especially graphic data, both
>|> machines will use their Blitters, which have 32-bit access to RAM. No
>|> crippling for the Falcon in that case.
>
> Don't assume that much. If you are making an animation you'll have
>to use the CPU to move memory regardless of how wonderfull the blitter is.
>And second, you have to take into consideration that the Falcon's blitter
>has to do (for bobs) I think it was twice or three operations per one
>Amiga blitter operation.
>
Can you be more specific about these instances?
What I'm talking about is just the simple blit from a single-source to a
single destination. That's the most common operation on most machines,
right?
>|> 2) if the loop being used to move a chunk of memory is a simple dbra loop
>|> that fits in the cache, the Falcon will do fine.
>
> For the instruction cache yes, but not for the data cache, wich is
>what happens in those 'benchmarks'. And again, this is not the
>real-world situation, as programs do not consist of this.
>
Well, geez, WHAT THE HECK DO PROGRAMS DO IF THEY DON'T USE A DBRA LOOP?
Either a program HAS a loop or it unrolls the loop. Period. What else can
it do?
If the loop is unrolled, it may not fit in the cache... the Falcon's (and
A1200's) instruction cache takes a hit.
It it is NOT unrolled, then it might just fit in the cache.
That's it.
Try this and see what happens with a decent disassembler:
#include <stdio.h>
main()
{
int i=0;
for(;i<1000;i++)
printf("%ld\n",i);
}
Go ahead.
>|> Now if both of those possibilities don't exist in the code, the Falcon may
>|> be punished.
>
> AND IT IS BEING PUNISHED. Why? Because in a real-life situation
>this is not the case.
>
Ricardo, GET THEE TO A DISASSEMBLER and tell me what new method we have
for looping that either:
a) doesn't unroll the loop and create towers (which break caches)
or:
b) keeps it the same, as a loop, which may indeed fit inside the cache for
many operations.
Do you realize how many times your CPU is asked to do string compares, copies,
etc. in the course of a typical execution?
Now, if you have a fairly sophisticated algorithm, it probably won't fit into
a 256 byte instruction cache. That's a given. But if it is indeed composed
of smaller parts that DO (like string compares... etc...) you will find that
those sub-parts are speed up tremendously!
> And you know what? NO MATTER HOW MUCH ATARI PEOPLE ARGUE ABOUT THIS
>BENCHMARKS, THEY SHOW NOTHING. AGAIN, I GOT A '030 COMPUTER AND
>THE CACHES DO NOT GIVE IT 75% IMPROVEMENT THAT IN THE FIRST BENCHMARK
>THE CACHES GAVE TO THE FALCON. THIS CLEARLY SHOWS THAT THE BENCHMARKS
>DO NOT SHOW ACTUAL WORLD PERFORMANCE WITH REAL APPLICATIONS.
>
I never said the original benchmarks were accurate for real world apps....
only that in optimal circumstances a stock Falcon does perform much better
than expected (and actually beats the A1200 handily with no FastRAM.
Flip
Ricardo Hernandez Muchado <ric...@rchland.vnet.ibm.com> wrote:
>
>
>separating 'bit planes'. It's like having a whole screen on top
>of another which is like a huge sprite in top of the other.
>
> THERE's NO WAY THE FALCON CAN DO THE SAME.
Go buy a Jaguar if you wanna play games. :)
Jason W. Nyberg
/Here is the reply form the "guy":
/The test without caches neede 43.1 s and the test with caches needed 21.3 s.
/That means: the F30 is 100% slower without caches or 50% faster with caches.
Using your data for time: F30 is 50% slower without cache than with, and
100% faster with cache than without.
/The improvement is 50%. I don't know how to get 75% with these figures...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I can see why...
The improvement in speed due to cache is 100%.
/Nearly all programs that i have tested get a 50% improvement caused by
/the caches. These tests are not as easy as it seems because you only have to
/check the calculation time (many programs spend a lot of time with I/O).
Speaking of checking your calculations...
--
These are the thoughts and words of Jason Nyberg (nyb...@ctron.com)
\ /
____\___/O\___/____ In aerodynamics we trust!
\_\\_//_/
Robert C. Merritt <rcmerrit>
Here is a question for you.
Why did the IBM (or Intel if you wish) PC become so dominate?
Its already taken over in the US and I've heard that clones are threating
the europe market to.
My computer history includes from a Commadore Vic-20,Colleco Adam, Atari 400
(used), Commadore 128 (used), Tandy 1000ex, 386 sx, 486 dx
In highschool, I needed a more powerful computer, so my dad went out looking.
The choices were a Clone, and a Mac. This was 1986 and you couldn't find
a store that sold an Amiga nor a Atari st. So, we got a clone. And even
back then, it seemed that 80% of the new software was IBM. (there were
more Amiga and St games out. And they just HAD to show those pictures instead
of the sucky IBM versions on the back of the box. Every game purchase was
an adventure)
Then came 1990. I was in college, had a good paying job, I wanted a better
computer. So this time I went out to look. I couldn't find an atari
dealer, in fact I could find an atari st owner period. Besides, everyone said
atari would be dead in a year. So I looked at amigas. I wanted to get one
with some memory and a hard drive. The only amiga that had thoses was close to
$3000. (I didn't know the 500 could be upgraded to a hard drive and neither did
the dealers that I talked too) and most of the games weren't even hard drive
installable. But the worst part was that most amiga deallers were working
in dirty stores and really didn't seem to care if you bought one or not.
Then Wing Commander came out for the clones. I was sold to a PC without even
really looking at one. (well, I did shop for awhile) And when I got it home,
I began the experience thew nightware that was dos 4.01 but this isn't the
place for that discussion..
fall 92. I once again decided upgrade to a 486. However, I did find a
few deallers that seemed professional. Anyways I waited for the
Falcon and the Amiga 1200 to give them a fair shot. And I waited, and waited..
Eventually the Amiga guy told be to buy the 486 but remember the amiga when
I want to upgrade again in a few years and talk to him. He is doing well
the last time I talked with him. I might by a used Amiga 500 off of him soon
for a toy. Anyways, I called the Atari dealer and he was highly upset to be
not getting my business, and he said aoon he'd become a clone dealer
soon if this continued. I looked at macs but wasn't impressed.
Anyways, my point is, I never really had a prefance towards the pc, however, it
seemed all the factors FORCED me into a PC clone.
(BTW, when I say PC, I mean those based on the Intel format)
So is it simple the lack of availablity the reason the other formats aren't
doing well?
And now both companies apear to be activly becoming videogame companies. So
is it true that in 95 or so, that the pc will be the ONLY choice?
Rob Merritt
email:rcme...@cbda9.apgea.army.mil**Disclaimer: My opinions are mine alone.
Sysop of Moon Base Tycho BBS. **not of my employer, not of my friends,
(410)391-6291, Running Renegade **and family, and not of a co-worker.
"Nostalgia isn't what it used to be" -unknown
Stephenson Daniel A
>
>Here is a question for you.
>
>Why did the IBM (or Intel if you wish) PC become so dominate?
Three reasons, as I see it:
1)Head Start
2)Lotus 1-2-3
3)WordPerfect
>Its already taken over in the US and I've heard that clones are threating
>the europe market to.
maybe so
>Anyways, my point is, I never really had a prefance towards the pc, however, it
>seemed all the factors FORCED me into a PC clone.
>(BTW, when I say PC, I mean those based on the Intel format)
>So is it simple the lack of availablity the reason the other formats aren't
>doing well?
I'd say it was the numbers in *business* that gave them the edge. The rest
(VLB, supra vieo, GUS,etc) followe with the market.
>Rob Merritt
>email:rcme...@cbda9.apgea.army.mil**Disclaimer: My opinions are mine alone.
--
Dan Stephenson
das...@usl.edu
Mechanical Engineering Dept.
University of Southwestern Louisiana
Paul Cardwell
I doubt the PC will be the *only* PC choice in 1995...Businesses
use all types of computers...an IBM clone isn't the only choice and
doesn't serve all business needs.
Remember the PowerPC is coming, which is once again a new era in
computing -- it is going to shake computing and win over IBM cloners. Given a
choice of running all popular software off one computer is "cool" and by itself
warrants the move to PowerPC. True OS/2 2.1 is currently doing this, an OS
that provides 32bit processing power and can run not only applications of its
own, but Windows 3.1 and DOS. It will be interesting to see how the PowerPC is
accepted.
Technology constantly changes and evolves into new concepts and
standards...we are human, we are never satisfied, we always want to improve
what we create.
Paul
.---------------------------------------------------------------------------.
| Arc Wave, real life: Paul Cardwell | INet Address: a...@judy.indstate.edu |
|___________________________/\/\/\/\/\/\/\/\/\/\____________________________|
`---------------------------A4000/040,Linux,OS/2----------------------------'
Rickard Troedsson
THEN DO SOME *YOU* LIKE!
RH> DON'T YOU JUST GET IT? I have a '030 setup and enabling the caches
RH> on my applications DO NOT GIVE ME A 75% PERFORMANCE BOOST THAT THE
RH> FIRST BENCHMARK DID TO THE FALCON. THEY GIVE ME LIKE 12% ON AVERAGE.
I have a 16Mhz 68000 acc. on my 8Mhz 68000 STE .. it boost 80-90% average, and
100% on math. There's no reason for me to believe you when you claim that a 030
acc. only gives you a 12% boost!
Maybe the A1200 has a VERY poor architecture .. I seem to recall your 030 acc.
to be 50Mhz too? If that's the case, the Falcon030 at 16Mhz seems to be faster
than an A1200 with a 50Mhz 030 acc!
RH> ARE YOU A REAL PROGRAMMER OR WHAT? ISN'T MY EXPLANATION ABOVE
RH> SO HARD TO UNDERSTAND?
Yup. If you don't like these benchmarks - do your own. Or maybe you're afraid
to see the results?
RH> |> PS: Is that bridge red?
RH>
RH> Any color you want, I just want to get your money by selling it to you.
RH> It seems I'll be able to very easily...
Sure, I need one. It's taken Sweden and Denmark too long to build the bridge
between Malmoe and Copenhagen, I think I'll do it for them.
<this is drifting away .. I can FEEL it .. >
Rickard Troedsson
'> > Ok, I'll calm down :-) But tell 'Rickard' to stop saying non-sense...
'>
'> Ok... RICKARD! STOP SAYING NON-SENSE! :)
Oh, but then this newsgroup would die ... ;)
Rickard Troedsson
RH> DON'T YOU JUST GET IT? I have a '030 setup and enabling the caches
RH> on my applications DO NOT GIVE ME A 75% PERFORMANCE BOOST THAT THE
RH> FIRST BENCHMARK DID TO THE FALCON. THEY GIVE ME LIKE 12% ON AVERAGE.
Aha ... don't care flaming me for my letter about your slow accelerator ... I
read "enabling the acc" instead of "enabling the caches" .. sorry 'bout that
one .. ;)
12% average increase with caches .. hmm .. I'll check that immideately ... get
back to you later with the result ..
(How do you measure something as exact as 12% in real world applications ..
using a clock?)