Poster | Thread |
bison
| |
Re: Interesting development on MMU for Classic AmigaOS. Posted on 19-Jul-2020 14:30:52
| | [ #21 ] |
|
|
|
Elite Member |
Joined: 18-Dec-2007 Posts: 2112
From: N-Space | | |
|
| @matthey
Thanks for the links!
_________________ "Unix is supposed to fix that." -- Jay Miner |
|
Status: Offline |
|
|
kolla
| |
Re: Interesting development on MMU for Classic AmigaOS. Posted on 20-Jul-2020 10:23:34
| | [ #22 ] |
|
|
|
Elite Member |
Joined: 20-Aug-2003 Posts: 2859
From: Trondheim, Norway | | |
|
| @matthey
Quote:
How can memory be so fast on the Apollo core in FPGA? |
If I have a 20MB large file in RAM: and copy it to another file in RAM:, the Vampire is slower (~1.5 sec) than my very old CSPPC card with its 72 pin SIMM modules (~1.1 sec) - and just for heck of it, I even used 68k version of Copy and Time, so the CSPPC running OS4 is using emulation as well.
So no, it's not "how can memory be so fast on Apollo Core" - it's more like... "how come duplicating data in RAM on a Vampire card is still comparably slow when certain benchmarks show that they should be very much instant?"
Perhaps C:Copy isn't "68080 optimized", but then again wtf is?
And please - leave "conspiracy theories" out of this, there is no conspiracy to talk of - to conspire requires more than one person. (why has this term become so "popular" among certain Amiga developers anyways?)Last edited by kolla on 20-Jul-2020 at 10:26 AM.
_________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
bhabbott
| |
Re: Interesting development on MMU for Classic AmigaOS. Posted on 20-Jul-2020 14:28:29
| | [ #23 ] |
|
|
|
Regular Member |
Joined: 6-Jun-2018 Posts: 330
From: Aotearoa | | |
|
| @kolla
Quote:
kolla wrote:
If I have a 20MB large file in RAM: and copy it to another file in RAM:, the Vampire is slower (~1.5 sec) than my very old CSPPC card with its 72 pin SIMM modules (~1.1 sec) | How many SIMMs do you have installed?
Quote:
- and just for heck of it, I even used 68k version of Copy and Time, so the CSPPC running OS4 is using emulation as well. | But does that mean the actual memory copy is being done with 68k code? |
|
Status: Offline |
|
|
matthey
| |
Re: Interesting development on MMU for Classic AmigaOS. Posted on 21-Jul-2020 2:24:33
| | [ #24 ] |
|
|
|
Super Member |
Joined: 14-Mar-2007 Posts: 1968
From: Kansas | | |
|
| Quote:
kolla wrote: If I have a 20MB large file in RAM: and copy it to another file in RAM:, the Vampire is slower (~1.5 sec) than my very old CSPPC card with its 72 pin SIMM modules (~1.1 sec) - and just for heck of it, I even used 68k version of Copy and Time, so the CSPPC running OS4 is using emulation as well.
So no, it's not "how can memory be so fast on Apollo Core" - it's more like... "how come duplicating data in RAM on a Vampire card is still comparably slow when certain benchmarks show that they should be very much instant?"
|
The CSPPC/CSMKIII supports dual channel memory (perhaps hinted at by bhabbott). Memory access is likely interleaved supporting parallel accesses which could boost sequential accesses as is common for memory copies. This requires more hardware lines and memory sockets which adds expense. A low end FPGA has modern memory for sourcing reasons but lacks many expensive features. The PPC CPUs in the CSPPC have a 64 bit data bus while the 68060 only has a 32 bit data bus. The 32 bit data bus allowed for cheaper 32 bit memory and fewer lines while performance often wasn't too far behind a 64 bit data bus as code density and efficient caching of the 68060 didn't waste as much memory bandwidth on instruction fetch and cache misses.
Quote:
XC68060 Competitive Advantages: Intel Pentium: Dominates PC-DOS market o Weaknesses: Requires 64-bit bus. 68060: Superior integer performance with low-cost memory system
|
- Motorola High-Performance Internal Product Portfolio Overview (Issue 10 Fourth Quarter, 1995)
There are other differences in the hardware which could make a different. The CSPPC/CSMKIII was higher end hardware while the Vampire hardware is newer but lower end.
Quote:
Perhaps C:Copy isn't "68080 optimized", but then again wtf is?
|
The 68k copy routine could make a difference but the Apollo Core shouldn't be any slower than the 68060. If the AmigaOS exec.library CopyMem() or CopyMemQuick() functions are used, then the default MOVEM loop would likely require at least 2 cycles per 32 bits copied on the Apollo Core where an unrolled MOVE.L loop may be able to move 64 bits per cycle by fusing 2xMOVE.L into a MOVE.Q. While this may give roughly 4 times the performance, it may not give any performance boost if the Apollo Core can already saturate memory. Sorry, lot's of variables on the software side too.
|
|
Status: Offline |
|
|