Amiga Vs Intel/others > CPU comparisons ?

[Noob-tech-ninja]

Hi there guys.

I was wondering if there is a basic/approximate way of comparing the Amiga
68000 range of CPUs vs Intel's x86 CPUs (or others like the Acorn Archimedes
ARM processors too)

I've had a good look around the net, and there is not a lot of forthcoming
information. I do realise that it it very difficult to compare differing CPU
architectures and then there is (CISC Vs RISC) etc, etc.

However I was just looking for some approximate comparisons, E.G.

68000 = 286
68020 = 386
68040 = 486
68060 = Pentium (1st gen)

Any thoughs or advice would be appreciated.

[Samurai_Crow]

Originally Posted by Noob-tech-ninja

However I was just looking for some approximate comparisons, E.G.

68000 = 286
68020 = 386
68040 = 486
68060 = Pentium (1st gen)

Any thoughs or advice would be appreciated.

Those are pretty close but the 68000 instruction set was closer to a 386sx despite the speed being comparable to a 286.

[Seiya]

this is my opinion based on performance seen in most games

68000 = 086/8
68020 = 286/12
68030 = 286/25
68040 = 386DX/40 or 486DX33
68060 = Pentium as architecture, but performance like 486DX2/66

[redblade]

if you look at the image which compares the 68000 to 80286 you get a good idea at the difference of the cpus.

I don't know what good bench marks are? Converting numbers to floats and back to ascii's again? Matrix calculations?

The 68000 has a move.x constant(dx.x, ax) register (something like that) which is helpful for matrix/tables manipulation.

Then there is also the endian differences and if that affects the code.

I think catacombs-3d could be a good bench mark because both amiga and EGA display is 16 colour for planar display.

Don't know what the difference in cycles is with the multiply / divide instructions on both cpus.

The experts will answer better.

[desiv]

Page 5 has a decent chart with some MIPS comparisons.
https://inst.eecs.berkeley.edu/~cs26...gs/price89.pdf

(No Amiga unfortunately, but some 680x0 and x86 machines...)

[Photon]

There are just so many factors.

1. CPU Benchmarks are always artificial in some way.
2. Platforms may hamper CPU (and mostly that's a good thing, platform is not made only to run artificial benchmarks well textmode commandline was 'done in the 70s'.) Applies to both OS software and hardware build.
3. If benchmarks are not written in optimized Assembly language, then languages have certainly been known to hamper CPU. If you want faster performance, "just" rewrite your program in Assembly language.
4. Real-word applications (even in the absence of an OS) are up to how well-written they are, and certainly if they are written in not Assembly language, then see 3.

So it's a case of "careful what you want". If you want a benchmark that measures memory speed and cache, then run that. (This is what usually hampers even a pure CPU benchmark.) If you want a software fillrate for a certain resolution benchmark, then get that. Each benchmark is relative to the other of the exact same kind. The exact part is the difficult part.

Then, if you care, you have things like a beautiful CPU. The 68060 is a beautiful CPU, and 68040 is close, with a few warts. ARM1 was a failure, ARM2 was the new home-RISC and beautiful, and after a few years they wrecked their architecture. Intel is nothing and has never been anything but ugly, old, and clunky 8-bit extended to 32-bit. It's a few fathoms below even wishlist CISC.

PowerPC was "all right", Alpha was a means to an end, but also a nod those old bespoke incredibly long instruction word specialties of oold supercomputers. DSPs were hot for a while. RISC, especially the ARM kind, won out deservedly.

And behind all this lies slow RAM. We could have had RAM that could keep up with the CPU, be double-port, be smart and serve search results for SIMD, but no, cheapest possible and a bodge of a serial processor.

If we had, then there would simply be no caches. CPUs would run at their chip speed, and that would be that.

In lieu of that, a benchmark written for representative Assembly language code such as iterations, recursion, low-level math functions (dry or wet), and garbage collection would be closest to a CPU benchmark today. Nobody cares what time it takes to run something in a higher level language (if you're measuring the CPU).

[Locutus]

Originally Posted by Photon

Nobody cares what time it takes to run something in a higher level language (if you're measuring the CPU).

You do/should, and this is why a serious benchmark like SPEC or Linpack is delivered as source code.


Most all software is written in some compiled language after all, so CPU features matching up with what a compiler can generate decent code for is *vital*.



Thus actual performance is a combination of the CPU and also how well a compiler can optimize for that CPU (at the basic level, but also for say new vector math extensions).

[Photon]

@Locutus: No, I'm afraid you're completely wrong there.

If you think about it, CPUs do different things, things that high-level languages are very bad at: Searching memory, shuffling data, computing any calculation you want.

As soon as you pollute the benchmark by measuring high-level language performance, you move away from the CPU (which can run any high-level language, absolutely every single one of them) and end up with a benchmark that measures that specific language, and that specific version of it to boot.

Have you written software directly in Assembler? You would understand this if you had.