Thank you. Hope it is not too much work. But make sure that the jumper setting also changes the SDRAM burst to 2-1-1-1, not just the clock.FrancoisLanciault wrote:I don't know if my 56mhz board can be operate at 28mhz. Maybe there is a jumper somewhere to chose the frequency. I will check.
Q68 speed vs 680X0
Re: Q68 speed vs 680X0
Re: Q68 speed vs 680X0
Note that I have changed the text slightly but the conclusion still holds, and it is indeed interesting!Peter wrote:Interesting conclusion and amazingly close to the measured figure...Nasta wrote:On the other hand, 040 is kind of like a clock doubled 030. Let's test this by scaling up the 030 results from 56 to 66MHz (33MHz on the 040, x2) We get 65.33secs.
-
- Trump Card
- Posts: 168
- Joined: Mon Aug 08, 2011 11:08 pm
Re: Q68 speed vs 680X0
Don't forget that all these computers, Amiga, QLs and NextStation are multitasking computers. I made sure the benchmark was the only application running, but each system must have some overhead. Especially the NextStation as it is a Unix machine with probably a lot of background task running even right after power up.Nasta wrote:
Of course the 4% and 10% differences may well be initial cache loading, but the figures are close enough to do a valid comparison.
François
Re: Q68 speed vs 680X0
I am a little surprised myself, I did not expect to (almost or actually) beat the 68040 in a maths-centered benchmark, even though the code only uses plain 68k instructions.Nasta wrote:Now the Q68 - The 030 approaches 1 instruction per 2 cycles since the whole benchmark fits inside the cache. If we scale it's result to 80MHz (to match 2x 40MHz of the Q68), to compare with Q68 running from SRAM at near 1 instruction per cycle, we get 49.7 secs, so the Q68 is actually faster by about 4% when running from full speed memory. That is an excellent result.
I'm not in the mood for a 40 MHz SRAM based design myself, because it is more PCB layout work than SDRAM and requires clever sourcing of the otherwise expensive fast SRAM chips. But it is amazing, how well it would perform.
Nasta, if I remember correctly, you were considering an SRAM based design? Time permitting, I' d be willing to create a TQFP144 FPGA-CPU for you for free, with SRAM interface. As long as it is without the Q68 graphics & SDRAM controller (which I'd like to keep confidential for now) other free on-chip peripherals are debatable.
Just an idea, since you seemed to like the performance. I don't know if you have the time...
Peter
-
- Trump Card
- Posts: 168
- Joined: Mon Aug 08, 2011 11:08 pm
Re: Q68 speed vs 680X0
For information, the same benchmark re-written to use the new, more powerful, 68020+ multiplication and division instructions runs in 29.6 secs on the NextStation Turbo.Peter wrote:I am a little surprised myself, I did not expect to (almost or actually) beat the 68040 in a maths-centered benchmark, even though the code only uses plain 68k instructions.Nasta wrote:Now the Q68 - The 030 approaches 1 instruction per 2 cycles since the whole benchmark fits inside the cache. If we scale it's result to 80MHz (to match 2x 40MHz of the Q68), to compare with Q68 running from SRAM at near 1 instruction per cycle, we get 49.7 secs, so the Q68 is actually faster by about 4% when running from full speed memory. That is an excellent result.
I'm not in the mood for a 40 MHz SRAM based design myself, because it is more PCB layout work than SDRAM and requires clever sourcing of the otherwise expensive fast SRAM chips. But it is amazing, how well it would perform.
Nasta, if I remember correctly, you were considering an SRAM based design? Time permitting, I' d be willing to create a TQFP144 FPGA-CPU for you for free, with SRAM interface. As long as it is without the Q68 graphics & SDRAM controller (which I'd like to keep confidential for now) other free on-chip peripherals are debatable.
Just an idea, since you seemed to like the performance. I don't know if you have the time...
Peter
François
-
- Trump Card
- Posts: 168
- Joined: Mon Aug 08, 2011 11:08 pm
Re: Q68 speed vs 680X0
Here it is. It should run on any QL system with at least super toolkit II.Peter wrote:QL ready to run for me, please. I'm very curious how the 80 MHz Q60 performs.
Code: Select all
90 REMark change to ALFM to work from Q68 SRAM
100 addr=ALCHP(210)
110 FOR i=0 TO 104
120 READ d$
130 POKE_W addr+i*2,HEX(d$)
140 END FOR i
190 INPUT "number to test : ";num
195 t=DATE
200 CALL addr,num,0,0,0,0,0,0,addr+206
210 PRINT PEEK_L(addr+206);" primes in ";DATE-t;" secs"
215 GO TO 190
999 REMark Program DATA
1000 DATA "2001","5380","E288","2E00","5387","2C07","E48E","E88F","DE86","2C07"
1010 DATA "E88E","DE86","2C07","E08E","DE86","2C07","7610","E6AE","DE86","2C00"
1020 DATA "5386","9C87","9C87","9C87","CCFC","000B","EA8E","DE86","9087","7405"
1030 DATA "6172","4A47","675C","5380","3802","C8C4","D882","D882","5542","4243"
1040 DATA "2E04","5243","E28F","66FA","5343","7A03","2E05","E7A7","2C04","BE45"
1050 DATA "670A","E28F","BE86","6EF6","9C87","60F2","4A46","671E","5445","B445"
1060 DATA "6D16","BA7C","001F","6DDC","2E04","8EC5","4847","4A47","6708","5445"
1070 DATA "B445","6CF0","5380","D882","D882","5884","B284","6CB2","5442","5442"
1080 DATA "3E02","CEC7","B287","6C94","5280","2080","7000","4E75","7C03","2E02"
1090 DATA "8EC6","4847","4A47","6604","7E00","4E75","5446","3E06","CEC7","B447"
1100 DATA "6CE8","7E01","4E75","0000","0000"
The benchmark was executed in my tests with a value of 2 000 000 (two millions)
The result should be 148933 primes found.
BTW the program can be run with any values but give accurate results for inputs that are equal or lower to 2031585. A design choice to make things run faster. There is just a single byte to change in order to make it work with numbers up to 16 000 000. I leave it to anyone with spare time find which byte and why it was programmed this way
Peter, if you have time, could you run the test for 2000000, 1000000, 500000, 200000 and 100000 on your Q60 so I can fill my benchmark result database with an entry for the Q60 ?
François
- NormanDunbar
- Forum Moderator
- Posts: 2278
- Joined: Tue Dec 14, 2010 9:04 am
- Location: Leeds, West Yorkshire, UK
- Contact:
Re: Q68 speed vs 680X0
Nit picking, I know, but ...
should the value for the end time not be the first exectuted statement after the call? The benchmark would appear to include overhead for the PRINT and PEEK_L commands. It might not be much admittedly, but it looks "wrong" to me.
I'd have line 205 as something like 'e=DATE' and adjust line 210 accordingly.
Just thinking out loud, feel free to ignore me, or shoot me down - metaphorically I hope!
Cheers,
Norm.
should the value for the end time not be the first exectuted statement after the call? The benchmark would appear to include overhead for the PRINT and PEEK_L commands. It might not be much admittedly, but it looks "wrong" to me.
I'd have line 205 as something like 'e=DATE' and adjust line 210 accordingly.
Just thinking out loud, feel free to ignore me, or shoot me down - metaphorically I hope!
Cheers,
Norm.
Why do they put lightning conductors on churches?
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
Author of Arduino Software Internals
Author of Arduino Interrupts
No longer on Twitter, find me on https://mastodon.scot/@NormanDunbar.
-
- Trump Card
- Posts: 168
- Joined: Mon Aug 08, 2011 11:08 pm
Re: Q68 speed vs 680X0
I checked and there is only one jumper on the board. It's purpose is to inform the card about the operating system version. The empty socket is for the real time clock chip.Peter wrote:Thank you. Hope it is not too much work. But make sure that the jumper setting also changes the SDRAM burst to 2-1-1-1, not just the clock.FrancoisLanciault wrote:I don't know if my 56mhz board can be operate at 28mhz. Maybe there is a jumper somewhere to chose the frequency. I will check.
There might be a way to go from 56 to 28 somehow by shorting PCB trace or something but I have no idea and I would not dare to try it.
Sorry.
François
-
- Gold Card
- Posts: 433
- Joined: Tue Mar 11, 2014 8:00 pm
- Location: Oxford, UK.
- Contact:
Re: Q68 speed vs 680X0
On an Atari TT030 (30MHz 68030) it takes 127 seconds.
Unfortunately SMSQ/E doesn't run in fast RAM so I can't test it with the uncontended EDO RAM only the slow RAM shared with the video sub-system.
Unfortunately SMSQ/E doesn't run in fast RAM so I can't test it with the uncontended EDO RAM only the slow RAM shared with the video sub-system.
-
- Font of All Knowledge
- Posts: 3975
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Q68 speed vs 680X0
Hi Stephen,stephen_usher wrote:On an Atari TT030 (30MHz 68030) it takes 127 seconds.
Unfortunately SMSQ/E doesn't run in fast RAM so I can't test it with the uncontended EDO RAM only the slow RAM shared with the video sub-system.
Are you using QVME in the TT030?
Regards,
Derek
Derek