Atari Coldfire vs 68000, 040 and 060 benchmark results

[nicholas]

Veeeeeeeeery nice!!



http://kronos.lutece.net/

[Kesa]

What are the data values on the y-axis? Sorry don't know much about benchmarking

[nicholas]

What are the data values on the y-axis? Sorry don't know much about benchmarking

Take the 8MHz 68000 in the STF as a baseline of 1 and each CPU's benchmark result is that many times faster than the 68k.

[bloodline]

Hmmm, need to know the Y-Axis or this could just be showing heat output

[WolfToTheMoon]

Good(expected) result for the Coldfire CPUs.

Damn shame that freescale doesn't want to sell V5 and V5e cores :madashell:

[Hattig]

Take the 8MHz 68000 in the STF as a baseline of 1 and each CPU's benchmark result is that many times faster than the 68k.

An '040 isn't 200 times faster than a 68000, even if it's running at 40MHz and the 68000 8MHz.

Haven't got a clue what this is actually testing, and the screenshots are just confusing, it's like 1985 ST GEM meets 1995 Mac OS. The graphs all have '0' for the 'Your computer' entry too. Very confusing.

[Kesa]

Sure it sounds impressive being (x) times faster than the original 68000 but isn't the Amiga about multitasking and not about how many rpm's the cpu will do? Amiga and the PC have very different philosophies to what is measurable performance so maybe this kind of benchmark would be more appropriate for PC's?

Again sorry but i don't know much about benchmarking

[nicholas]

An '040 isn't 200 times faster than a 68000, even if it's running at 40MHz and the 68000 8MHz.

Haven't got a clue what this is actually testing, and the screenshots are just confusing, it's like 1985 ST GEM meets 1995 Mac OS. The graphs all have '0' for the 'Your computer' entry too. Very confusing.

It seems to be just an overall "points score" for each machine rather than a straight how many MIPS is this CPU.

I could be wrong.

[alexh]

Look at an inverse of the graph and you'll have compatibility on the Y axis

[bloodline]

It seems to be just an overall "points score" for each machine rather than a straight how many MIPS is this CPU.

I could be wrong.

The problem we have here is that the "Points score" could just be checking a simple decrementing loop, in which case all we are looking at here is the speed of the cache (vs memory access in the 68000).

I have looked over the site but can't find much explanation.

[Mr_Vanos]

Admittedly I don't know much about the differences between the CF and 68k architectures. I know they are similar but that there is some reduction in the instruction set going from 68k->CF, so I wonder how compatible they are. If the processor has support for virtualization of instructions (unimplemented instruction exception vector like in some processors) I guess you could potentially address that in software.

Always thought a Coldfire CPU accelerator might be a good idea on the Amiga. Clock speeds are much higher and there are some nifty peripherals on the CF chips (USB, etc).

[bloodline]

Admittedly I don't know much about the differences between the CF and 68k architectures. I know they are similar but that there is some reduction in the instruction set going from 68k->CF, so I wonder how compatible they are. If the processor has support for virtualization of instructions (unimplemented instruction exception vector like in some processors) I guess you could potentially address that in software.

Always thought a Coldfire CPU accelerator might be a good idea on the Amiga. Clock speeds are much higher and there are some nifty peripherals on the CF chips (USB, etc).

Compatibility is bad for object code, as the mul instruction doesn't have the correct 68k behaviour, plus the supervisor mode is totally different... The missing addressing modes could be trapped but at a penalty :-(

[Piru]

Veeeeeeeeery nice!!

Not that impressive considering the coldfire is running native benchmark code.

ARM, x86 & PowerPC run circles around any coldfire anyway, and if you're not going to bother with binary compatibility why mess around with coldfire?

[commodorejohn]

Sure it sounds impressive being (x) times faster than the original 68000 but isn't the Amiga about multitasking and not about how many rpm's the cpu will do? Amiga and the PC have very different philosophies to what is measurable performance so maybe this kind of benchmark would be more appropriate for PC's?

CPU horsepower is CPU horsepower, though. Neither the x86 nor the 68k are truly multi-tasking by nature, so any multitasking OS is really just dividing up CPU time among the different tasks. More CPU horsepower = more cycles to go around in a given period of time. Of course, most Amiga applications probably aren't going to be demanding full power, but having more cycles to go around means that the tasks that are high-performance will be taking less of a bite out of the low-performance tasks, so everything benefits.

If the processor has support for virtualization of instructions (unimplemented instruction exception vector like in some processors) I guess you could potentially address that in software.

The 68k has had an illegal-instruction exception since the get-go. The bigger issue would be instructions that might be legal but operate differently (i.e. if they set some of the flags slightly differently than on the 68k.) Those would be legal and thus not get trapped, but still cause unexpected results in old software.

[Mr_Vanos]

Compatibility is bad for object code, as the mul instruction doesn't have the correct 68k behaviour, plus the supervisor mode is totally different... The missing addressing modes could be trapped but at a penalty :-(

That's a shame. The instructions that are opcode compatible but not behaviorally compatible would be a big issue. Why bother then?

I guess it'd be nice if all our old favorite software was available in source form and could be recompiled on any target CPU. Maybe AROS and the like are better solutions.