Overview Features Instructions Performance Forum Downloads Products OrderV4 Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Performance and Benchmark Results!

POVRay - Come to Fish Togetherpage  1 2 3 4 

Kymon Erec Zonias

Posts 7
29 Jan 2021 13:11


Hi Darren. I know that the MatzeTK060 runs sufficient at 90MHz (atm).
Did you read my Tip regarding the OxyronPatcher 3.14. or in your Case
you can even use the CyberPatcher. This should give you more realistic
numbers.

Regards.

Darren Eveland wrote:

Henryk Richter wrote:

  A good old 68060 is still able to give a good punch.
 
      Total Time:    0 hours 25 minutes  54.0 seconds (1554 seconds)
 
  EXTERNAL LINK 

 
  Interesting this result is more than 2x faster than my 100MHz 060 on my Cyberstorm MK2.  It must be that povray is very memory intensive, because with the same clock speed the only difference is that the Matze TK060 has much faster memory interface than a CS MK2 with the 100MHz hack (memory running @ 50MHz).  Does the TK060 run it's memory @ 100MHz?
 




Darren Eveland

Posts 47
29 Jan 2021 20:29


Yes thanks, I'm going to try with CyberPatcher and OxyPatcher, hopefully to get better numbers.  I have to re-install that system first as I am getting lots of errors/freezes due to SFS.  It's an old hard drive in there and it has been formatted using SFS.  I'm going to re-do the drive with Coffin (hopefully) but it will take some time.  If I can get it to boot stable first I may try a re-test with at least Cyberpatcher as I do have that on the system.


Henryk Richter
(Apollo Team Member)
Posts 128/ 1
30 Jan 2021 10:09


The TK060 is a fully synchronous design: both towards the mainboard and also the installed 6ns SDRAM. That's why it is somewhat limited in terms of clock speed settings (currently either 50 or 100MHz) but also explains why it reaches faster mainboard access and better memory performance than other 060 cards.

There is a 68060 binary of POVRay 3.1 available. That one (which I've used) eliminates the need for the likes of Cyberpatcher/OXYPatcher/MuRedox. Those are useful with Lightwave, though.


Andy Hearn

Posts 365
03 Feb 2021 14:30


aha. an 060 specific version of povray31. ok cool.
  downloaded that from povray.org and ran the povray benchmark...
 
  V1200 G2.13 RC3 build 7717 core x12 @85Mhz:-
  060 version 24mins and 02 seconds
  FPU version 23mins and 53 seconds (the version on coffin)
 
  guessing the FPU version has a more complete FPU instruction set to play with, hence slightly faster on a CPU that can support it?
 
  will get some true 060 numbers with the 060 version in due course.


Darren Eveland

Posts 47
04 Feb 2021 03:54


Where do you download the 68060 version of POVray? I can't find it on Aminet or on the web....must be blind.

Thanks
Darren


Andy Hearn

Posts 365
04 Feb 2021 11:31


no worries :)
main site
EXTERNAL LINK 
old versions - you want 3.1 as that's the last Official Amiga release set of archives
EXTERNAL LINK 
there is a "no-fpu" version there too as well as fpu/040/060 versions, so have ordered an A1200  ramcard that should be arriving today to generate some "stock A1200/020" numbers. should be amusing. i may have to run a "drive click silencer" so the wife doesn't go mad with it running for... i'm guessing *days* to do this :D


Andrew Miller

Posts 262
04 Feb 2021 13:32


Or you could just put a blank disk in.


Darren Eveland

Posts 47
05 Feb 2021 19:30


Thanks found it.  Will test!


Andy Hearn

Posts 365
09 Feb 2021 20:06


A1200 EC020@14Mhz 882@40Mhz, 8Meg fast ram
povray31 fpu version off coffin r58, but booted of a workbench3.1 floppy to maximize ram - compared to a full r58 boot
13hours, 7minutes, 31seconds

am going to try the "nfp" integer version. but given the first time i tried it, didn't do anything for a few days - i don't hold out much hope.


Markus (mfro)

Posts 99
26 Feb 2021 08:31


Renaud Schweingruber wrote:

  Ran with those parameters :
  povray31fpu +A +W720 +H486 +Ipovray31:scenes/advanced/fish13/fish13.pov +Lpovray31:scenes/advanced/fish13 +Oram:test.tga
     
   
  Anyone can run it with other Moto's CPUs ?
 

 
  Sure. Firebee (ColdFire v4e m5474@264MHz, running latest FreeMiNT):
 

  Total Scene Processing Times
    Parse Time:    0 hours  0 minutes  1 seconds (1 seconds)
    Photon Time:  0 hours  0 minutes  0 seconds (0 seconds)
    Render Time:  0 hours 15 minutes 45 seconds (945 seconds)
    Total Time:    0 hours 15 minutes 46 seconds (946 seconds)



Grzegorz Wójcik (pisklak
(Apollo Team Member)
Posts 81
26 Feb 2021 09:05


I think that 68080 might be the fastest available CPU core that can run inside low cost FPGAs. Interesting would be comparasion of other cores (MicroBlaze/PicoBlaze/Leon and some OpenCores CPUS)rendering the same scene in POVray :)

BTW. Nice Firebee score. Prehaps in new generation of FPGAs 080 can reach that high clock. 260 Mhz 080 would rock !


Gunnar von Boehn
(Apollo Team Member)
Posts 5307
26 Feb 2021 09:34


Markus (mfro) wrote:

  Sure. Firebee (ColdFire v4e m5474@264MHz, running latest FreeMiNT):

Running a different binary and on a different OS makes it useless as benchmark.

Where do you know that the OS or the different binary not make this score?



Markus (mfro)

Posts 99
26 Feb 2021 09:42


Grzegorz Wójcik (pisklak wrote:
...  BTW. Nice Firebee score. Prehaps in new generation of FPGAs 080 can reach that high clock. 260 Mhz 080 would rock !

 
Not entirely sure results are 100% comparable as I only have povray 3.6 available (maybe somebody could try this version on a V4?).

Wanted to upload the resulting image for illustration also - how am I supposed to do that on this forum?


Markus (mfro)

Posts 99
26 Feb 2021 09:46


Gunnar von Boehn wrote:

 
  Where do you know that the OS or the different binary not make this score?
 

I do not, certainly (see my other post). But that wasn't requested - it was only requested to provide scores for other m68k - that's what I did.

(and I apologise if the result doesn't really suit you)


Gunnar von Boehn
(Apollo Team Member)
Posts 5307
26 Feb 2021 09:58


Markus (mfro) wrote:

Not entirely sure results are 100% comparable as I only have povray 3.6 available

 
I think we can assume that using a different version of the program will give different scores.
 
And even using the same version, with a different compiler or just different compile flags can result in major differences.
 
Actually we have seen the big effect of the compiler just recently.
Last when working on our OS, compiling our Apollo-OS SDCARD driver with a different GCC version.
 
One GCC version reached a performance of 1.5 MB/sec SDCARD speed - and another version of GCC reached 4.6 MB/sec SDCard speed.
As you see the impact of the compiler was enormous here.
3 times faster or 3 times slower just by using another compiler!
 
I think you need to use the same binary - if you want to see the CPU part.
   
 
If you want to compare different cars then you need to run them on the same race track - running different cars on different tracks make comparing impossible.


Markus (mfro)

Posts 99
26 Feb 2021 10:18


Of course you are right in general, but I wouldn't assume huge effects with different compiler versions or different povray versions with that complex piece of software that povray is (at least I didn't hear about any huge performance gains with latest povray releases, otherwise everybody would use them). If you look at the numbers available, they pretty much scale with CPU frequency.
 
  I agree, there are sometimes huge differences when it comes to tight loops moving data (as I would assume you observed in your SD card example) but unfortunately it appears that later gcc versions are even getting worse regarding possible m68k optimizations. At least that's my personal experience, gcc 2.95 was a lot more willing to generate optimized movem.x sequences or dbra instructions while later versions need to be tricked to do so.
 
  What troubles me a little is that you come up with your arguments only after there is some better score showing up - apparently it didn't bother you before?


Gunnar von Boehn
(Apollo Team Member)
Posts 5307
26 Feb 2021 16:50


Markus (mfro) wrote:

Of course you are right in general, but I wouldn't assume huge effects with different compiler versions

 
Its just a fact that compilers can have huge impact.
Just look at Aminet and download there some different LAME EXEs and
compare their MP3 encoding time. The different compile LAME version have huge performance difference created by different compile flags and different compilers. 
 
Markus lets by clear here.
Such benchmark makes only sense when all use the same executable.

I find it little strange that you question this even.

 
 


Markus (mfro)

Posts 99
26 Feb 2021 17:40


I don't even know which compiler version was used to create the Amiga executable, so this is all just speculation anyway.
 
  We don't really need to argue about a minute better or worse when my Linux machine can do the fish in less than two seconds ;)


Gunnar von Boehn
(Apollo Team Member)
Posts 5307
26 Feb 2021 21:45


Markus (mfro) wrote:

I don't even know which compiler version was used to create the Amiga executable, so this is all just speculation anyway.

Markus the point of the benchmark is that all run the same EXE.
Running a different EXE is only one thing = cheating.
You should know this.
 
   
   
Markus (mfro) wrote:

We don't really need to argue about a minute better or worse when my Linux machine can do the fish in less than two seconds ;)

You sound like someone who was caught cheating and now tries to make all kinds of silly excuses.
- You did not know the exact version
- You did not know the used compiler
- You did know that different compiler make different code.

It would be nice if you can stop this.

posts 79page  1 2 3 4