@Hammer

Quote:

AmiCube F5000

According to google, the only mention of such a thing is you here on AWN.
In other words… now you’re just making up stuff as you go.

AmiCube seems busy evaluating Spartan 7 dev boards after he ran his MiST clone F1200 project into the ground over something as silly as refusing to give credit to the MiST project.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

I was thinking of writing a little blog follow up on the new 68K+ Market!

I just want to know if anyone has benchmarks comparing all the devices,

A500mini, A600GS, Pistorm, Vampire V4/Apollo and Pi systems

This is what I have found in just Dhrystones numbers from different SysInfo test over the net

Raspberry Pi5 ------ 2423340
Raspberry Pi400 --- 450889
A500 Mini ------------- 257619
A600 GS --------------- 246794
Vampire V4 ----------- 183577
Pi4 Pistorm32 ------- 161899
Pi3A Pistorm32 ----- 109961
68060 at 100Mhz ---- 75282

But many systems are running different OS and Emulation Configuration setting. So its a bit hard to definitely say which system is fastest, like the A600GS should I feel be higher than the A500mini, I think that benchmark, the A500mini was running a very basic Os environment.

But also I thought a Pi4 Pistorm would be faster than a Vampire v4, maybe Im wrong, can anyone confirm?

So just wonder if anyone knows if there one config that could be run on all platform and anyone willing to do the test for each system. (Amikit XE would be pretty good as it works on all system i think, a mod for A500mini & A600GS may have to be made.)

But basically, should we say to official be a 68k+ platform, your system needs to be 150000+ Dhrystones.

Last edited by amigang on 26-Jul-2024 at 01:13 PM.
Last edited by amigang on 26-Jul-2024 at 01:11 PM.
Last edited by amigang on 26-Jul-2024 at 01:10 PM.

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

The A600GS will be much faster in many areas compared to pure emulation such as TheA500Mini. This is due to native ARM libraries running in AmiBench. We are slowly moving libraries over to native ARM which will make performance increase in areas such as graphics and raw number crunching.

Of course TheA500Mini is not able to have a Workbench distributed with it due to the legal constraints of the 2009 Settlement Agreement. Retro Games Limited are not Amiga developers so will not want to natively progress their own Workbench envirnonment- it would be far too much cost and breadth of work. They are interested in moving on commercialising other retro platforms once they have extracted as much money from our community as possible.

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

@amigakit

Quote:

amigakit wrote: Of course TheA500Mini is not able to have a Workbench distributed with it due to the legal constraints of the 2009 Settlement Agreement.

What? This has not been a problem for Minimig, MiST and other systems that typically have been bundled with OS license from Cloanto.

Quote:

Retro Games Limited are not Amiga developers so will not want to natively progress their own Workbench envirnonment- it would be far too much cost and breadth of work. They are interested in moving on commercialising other retro platforms once they have extracted as much money from our community as possible.

What? They aren't even targeting "our" community, never have... it is simply much too small to be of any commercial interest.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@amigang

Quote:

But also I thought a Pi4 Pistorm would be faster than a Vampire v4, maybe Im wrong, can anyone confirm?

Don't know where you got your numbers?

https://blog.stef.be/pistorm32lite

Pi3A Pistorm32 - 2235226

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Yes the more I look into it, the more the numbers are all over the place for these systems!

https://x.com/Claude1079/status/1608840974977073155

Pi4 Pistorm32 clocked at 2.2Ghz @ 2236667
Pi4 Pistorm32 clocked at 2.4Ghz @ 2423859


Then there this video
https://www.youtube.com/watch?v=NDuVh-zOwdc&t=274s&ab_channel=HoldandModify

Pi4 Pistorm32 (unknow clock) @ 1562408

then this vid show
https://www.youtube.com/watch?v=yCvq6aqt96w&ab_channel=8BitRetroReFix

Pi4 Pistorm32 @ 777438

and finally
Micro Miga Pistrom @ 855418

I know it likely different software and config but I am surprised by the big differences.
Think I will go and ask on English Amiga board if they can post SysInfo of these systems

Last edited by amigang on 26-Jul-2024 at 04:09 PM.
Last edited by amigang on 26-Jul-2024 at 04:08 PM.
Last edited by amigang on 26-Jul-2024 at 04:04 PM.

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang
started a Thread, because I be interested in the numbers.

https://eab.abime.net/showthread.php?t=118176
So I know it likely different software and config, but I am surprised by the big differences.

So asking for a bit of help from the community, if you own one of the above system, post your Dhrystones on this forum or on the Google sheet
https://docs.google.com/spreadsheets/d/1txQd3JUOKG6-q78-SG0PvuErf69PSILCx_WG4HnxIXk/edit?gid=0#gid=0


Thanks

Last edited by amigang on 26-Jul-2024 at 04:39 PM.

_________________
AmigaNG, YouTube, LeaveReality Studio

amigang Quote:

Yes the more I look into it, the more the numbers are all over the place for these systems! ... I know it likely different software and config but I am surprised by the big differences. Think I will go and ask on English Amiga board if they can post SysInfo of these systems

Welcome to the world of emulation. JIT emulators may even remove meaningless code like the SysInfo bad benchmarks. SysInfo calls the benchmark "Dhrystones" but it doesn't use compiled Dhrystone code. It is a synthetic benchmark using meaningless random instructions. The 68060 is superscalar and needs instruction scheduling for maximum performance which the code is not. The instruction scheduling usually does not affect the 68000-68040 while it may improve results for the 68040 too. The actual Dhrystone 2.1 Dhrystones allows to divide by 1757 to obtain the Dhrystone MIPS.

SysInfo 68060@100MHz: 75,282 Dhrystones / 1757 = 42.85 DMIPS and 0.43 DMIPS/MHz

Real 68060@100MHz: 316,260 Dhrystones / 1757 = 180 DMIPS and 1.8 DMIPS/MHz

DMIPS results are from the following Microprocessor Report (results scale linearly with the clock speed because the Dhystone benchmark fits in a tiny cache).

Motorola Introduces Heir to 68000 Line
https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/080502.pdf

Real Dhrystone 2.1 results will vary depending on the compiler of which most compilers have minimal support for the 68060 and no 68060 specific instruction scheduler. The Diab Data compiler Motorola was using had an instruction scheduler for the 68060.

SysInfo's benchmarks are crap. Benchmarking JIT emulators is crap. Optimizing for inconsistent performance is crap. Building crap on crap produces a big pile of crap.

Last edited by matthey on 26-Jul-2024 at 07:12 PM.

@matthey

Well, I don’t use computers to show off benchmarks… do you?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@matthey

SysInfo is useless for A600GS, as does not test the ARM libraries, for example how fast is Sqrt on the system, how does ARM effect data types or rendering speed. Compression / decompression, I also like to point out, games or programs that kicks out OS, will not get boost from the ARM library’s, it only benefits well coded games and programs. Assumption knows anything about system out of one metric, is pure silly.

Last edited by NutsAboutAmiga on 27-Jul-2024 at 12:11 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@amigang

Weird numbers.

Pi4 (cm4) runs Heretic2 at 25 fps in 640x480,
Pi3 at 10 fps, Vampire V4 at 8 fps in 320x240.

Pi runs circles around Vampire.

kolla Quote:

Well, I don’t use computers to show off benchmarks… do you?

No, but benchmarks based on realistic code can be useful for comparing systems if limitations and flaws are known. Sysinfo Dhrystones benchmark code is not realistic but synthetic and useless. Benchmarking JIT emulators with useless code is worthless as code which gives unused results may be optimized away.

NutsAboutAmiga Quote:

SysInfo is useless for A600GS, as does not test the ARM libraries, for example how fast is Sqrt on the system, how does ARM effect data types or rendering speed. Compression / decompression, I also like to point out, games or programs that kicks out OS, will not get boost from the ARM library’s, it only benefits well coded games and programs. Assumption knows anything about system out of one metric, is pure silly.

The ARM libraries have narrow use for sure even though they can provide a large boost in performance by executing native code. Avoiding emulation overhead, including load-to-use stalls that drop performance in half, is the key.

MagicSN Quote:

Weird numbers. Pi4 (cm4) runs Heretic2 at 25 fps in 640x480, Pi3 at 10 fps, Vampire V4 at 8 fps in 320x240. Pi runs circles around Vampire.

FPS games provide a much better benchmark than SysInfo. I previously showed that roughly half the performance of the Cortex-A53 is lost to load-to-use stalls of unscheduled 68k to AArch64 instructions. The Pi4 and Pi5 OoO execution at least partially remove the load-to-use stalls but the CPU cores are huge and generate a lot of heat doing it even with expensive chip fab improvements. The heat is outpacing the die shrinks making the RPi4 and especially RPi5 less practical for embedded use "building blocks" like is used for the PiStorm and limits how much of a GPU upgrade is possible for these already large and hot SoC chips.

---- MC68060 500nm in-order 8-stage
RPi3 Cortex-A53 40nm in-order 8-stage
RPi4 Cortex-A72 28nm OoO 14-stage
RPi5 Cortex-A76 16nm OoO 13-stage

The Coretex-A53 remains popular, including for Amiga use, because it is the smallest and cheapest AArch64 capable ARM CPU core but the 3 cycle load-to-use penalty is very poor and a performance killer. The successor Coretex-A55 reduced the load-to-use penalty to 2 cycles which is still poor. There are some designs like 68k cores, AC68080 cores, x86 cores and SiFive U74 cores which have no load-to-use penalty. This makes instruction scheduling much easier as load results can be used immediately instead of trying to find instructions to place between the load and the instruction using it. Also, 68k code is written assuming that there is no load-to-use penalty so a simple translation to most RISC cores introduces stalls without OoO.

The 68060 and AC68080 performance/MHz blow away the emulated 68k performance/MHz on ARM but are simply not clocked up. The AC68080 core takes a huge performance hit from being simulated in a FPGA and not just from the lack of clock speed. The core needs to be pipelined more like a high clocked CPU core for an ASIC to even reach the roughly 100MHz that it does. The 68060 has an 8-stage integer pipeline which is no doubt significantly longer for the AC68080. One of the most noticeable places of the deeper pipelining is the FPU which requires more pipelining than an integer CPU or SIMD unit. The FPU was reduced from extended to double precision to improve the FPGA performance. Even the 1984 68881 FPU has a single cycle 67-bit barrel shifter which is used on many instructions for normalizing but this can be a problem for a FPGA FPU. The AC68080 adds pipeline stages to the FPU like a high clocked ASIC FPU but this increases the latency of the instructions. Even though the FPU is pipelined and a new FPU instruction can start execution every cycle, the results are not available for the latency of the instruction and this gives a stall if a result is accessed before available kind of like the load-to-use stalls. The solution is the same which is scheduling non-dependent instructions between and recompiling/writing code for a FPU with longer latencies. The 68k FPU only has 8 FPU registers for instruction results that aren't available yet and this is a problem with the increased latency of the deeper FPU pipeline. I proposed a FPU ISA enhancement that would increase the FPU registers to 16 without increasing the code size but this was not enough for Gunnar who wanted more registers for his FPGA ISA.

https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=45221&forum=25&start=120&127#870467 Quote:

Yes the old FPU code could work OK with 8 regs. But we all know that the old 68K FPU is not pipelined. A pipelined FPU needs unrolled code to make full use of it. To unroll code you need several times the number of registers. This is very simple logic. Most today pipelined FPU (power/intel/etc) have often a latency of 6 clocks. This means you want to unroll your work loops generally 4-6 times to be able to eat the latency. For doing this you need 4 to 6 times the number of register. We all know that IBM did increase the FPU register to 64 since a few years for POWER? Why did IBM do this - because its very useful for increasing performance. And yes IBM also has register renaming in addition to this! Having 32 FPU register plus being CISC gives the 68080 FPU a huge advantage over the "old 8 Register".

We see here 4-6 cycle FPU latencies for common instructions which is what deeply (super)pipelined high clocked CPUs had/have but instruction scheduling becomes more difficult even with 32 or 64 RISC FPU registers and the increased FPU latencies decrease performance. The trend in CPU design is less pipelined designs that reduce stalls as can be seen by the reduced pipelining from the Cortex-A72 to the Cortex-A76 which is true for more than the integer pipeline.



The AC68080 FPU pipelining is similar to, or perhaps longer than, the Cortex-A57 in the pic and it needs many GP FPU registers, a very good compiler and the code will be bloated from unrolling the code and the increased register encoding bits in the instructions in the case of the AC68080 FPGA ISA. With a pipelined FPU with latencies like the Cortex-A76 in the pic, even 8 GP FPU registers would gain some performance advantage, including existing 68k FPU code, while 16 FPU registers would gain most of the advantage. The AC68080 pipelined FPU does not make up for the long FPU latencies with existing 68k FPU code and compiling for an AC68080 target, including an instruction scheduler, is required to maximize FPU performance. The 68060 FPU latencies are more like the Cortex-A75 in the pic even though the FPU is not fully pipelined to save area/transistors. The AC68080 FPU maximum performance is much higher than the 68060 FPU but the short lantencies and good parallel execution with integer code should keep the performance closer than expected like the Pentium piplelined FPU that also required new optimized code to take advantage and had a poor ISA that was difficult for compilers.

Before Hammer creates another wall of text, I expect the 68060 FPU has stages (and separate FADD, FMUL and FDIV/FSQR units) even though it is not fully pipelined. See figure 2 in the following Microprocesor Report for a picture of multiple FPU stages even though it still doesn't show the individual unit pipelines.

Motorola Details Plan to Extend 68K Line
https://websrv.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/061505.pdf

There is a significant amount of state information that has to be retained for each FPU instruction executing for speculative execution rollback and interrupt purposes. FPU resources must be tracked and FPU instructions have to complete in program code order. For maximum FPU parallelization, some OoO complexity is required. Even relatively simple scoreboarding requires tracking many resources.

https://en.wikipedia.org/wiki/Scoreboarding

SRAM instruction and resource queues and speculative pipeline rollback data are what makes OoO cores many times the size of in-order cores. Pipelined FPUs are common today even for embedded FPUs but then a Cortex-A53 core is several times larger than a 68060 core. Even the 68060 is old and ARM has come a long way in transistor counts.

Year | CPU | transistors
1975 6502 3,500
1979 68000 68,000
1984 68020 190,000
1985 ARM1 25,000
1985 80386 275,000
1986 ARM2 30,000
1987 68030 273,000
1990 68040 1,170,000
1993 Pentium 3,100,000 superscalar in-order 2-way
1994 68060 2,530,000 superscalar in-order 2-way
1994 ARM7 250,000
1995 PentiumPro 5,500,000 OoO uop
2002 ARM11 7,500,000
2008 Nehalem 731,000,000 (1st gen Core i7 with 4 cores) 64 bit OoO uop
2011 Cortex-A7 10,000,000 superscalar in-order 2-way
2012 Cortex-A53 12,500,000 64-bit superscalar in-order 2-way
2012 Cortex-A57 75,000,000 64-bit OoO 3-way big.LITTLE companion of Cortex-A53

Rough ARM transistor counts come from the following link.
https://www.sciencedirect.com/topics/computer-science/stage-pipeline

The newer OoO ARM cores like the Cortex-A72 and Cortex-A76 are even larger. Most of the transistors are for SRAM caches and SRAM OoO buffers/queues. Moore's Law has ended and SRAM is no longer scaling with newer chip fab processes yet AArch64 and x86-64 code density is barely better than average. Maybe ISA will be important again.

Last edited by matthey on 27-Jul-2024 at 11:00 PM.

Quote:

amigang wrote: Dhrystones numbers from different SysInfo test Raspberry Pi5 ------ 2423340 Raspberry Pi400 --- 450889 A500 Mini ------------- 257619 A600 GS --------------- 246794 Vampire V4 ----------- 183577 Pi4 Pistorm32 ------- 161899 Pi3A Pistorm32 ----- 109961 68060 at 100Mhz ---- 75282

@amigang

Thanks for the data, what Emulation was used on the Raspberries?



@amigakit

Quote:

amigakit wrote: The A600GS will be much faster in many areas compared to pure emulation such as TheA500Mini. ...

Dhrystones are only reporting CPU Speed on integer calculations.

There are other tests that may give a good overview about GFX or disk performance, feel free posting them if they are made using know test tools like Sysspeed or AIBB.

You can add additional information about screen resolution, helping customers judging the results.

Last edited by OneTimer1 on 27-Jul-2024 at 11:42 PM.

What a great time to be an Amiga user !

_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

@amigang

Apparently you have not read what I answered you on EAB so let me paste it here:

Results vary because SysInfo is very bad benchmark. The Dhrystone test has nothing to do with real dhrystone benchmakr - it is just the MIPS value multiplied by a fixed factor.

The benchmark varies slightly from version to version. Moreover, versions up to 4.3 (including this one) clip result to xxx.xx Format, so instead of eg 1800.99 mips it will display 800.99. Starting with version 4.4 the rounding was changed and CHIP speed measurement changed too. For this reason, never ever compare values from different SysInfo versions as you did here (some results on the video were from version 4.0, those from Claude were from version 4.4).

For your database you have not even specified the version of software to be used, there you must be very precise. Even better - follow suggestion from Karlos and prepare set of well defined tasks which people should do and measure, e.g. render a very specified light wave scene, encode some specified aiff file to mp3 (with well defined parameters), unpack (and time) given archive to ram, do some rc5/72 calculations or something similar.

Never trust a single benchmark, benchmarks are really worth nothing... I mean it even considering the fact that Emu68 manages to get about 1.1 MIPS per 1 MHz of the ARM cpu core, yielding over 2000 SysInfo MIPS when running on 1.8 GHz CM4.

@matthey

Quote:

Benchmarking JIT emulators with useless code is worthless as code which gives unused results may be optimized away.

Emu68 does not optimize code producing unused results. Even a single NOP is not optimized away…

@OneTimer1

Quote:

Thanks for the data, what Emulation was used on the Raspberries?

Pi5 and Pi400 results most likely from some UAE variant. Pistorm results totally broken since acquired with ancient version of sysinfo. This table compares apples with oranges…

@michalsc

If one wants sysinfo benchmark here is a rough estimate: Pi3- about 0.6 sysinfo MIPS/MHz (ca 860 MIPS @ 1.4 GHz). Pi4 and CM4 give ca 1.1 sysinfo MIPS/MHz (ca. 2000 MIPS @ 1.8 GHz)

Final note: it does not make sense to compare sysinfo dhrystones - these are just scaled MIPS numbers…

Last edited by michalsc on 29-Jul-2024 at 04:55 PM.

@michalsc

Quote:

michalsc wrote: @matthey Quote: Benchmarking JIT emulators with useless code is worthless as code which gives unused results may be optimized away. Emu68 does not optimize code producing unused results. Even a single NOP is not optimized away…

Is there a specific reason for this? Compatibility?

_________________
Doing stupid things for fun...

@Karlos

Quote:

Is there a specific reason for this? Compatibility?

My own will to not do any sort of JIT cheating and the beauty of keeping Emu68 as simple as possible. For the same reason all hardware drivers are pure m68k code - the only hardware Emu68 is touching is GPIO - used for communication with FPGA/CPLD on PiStorm.