SAM 460 poor performance, high price

[Louis Dias]

I think what matters the most is what you have available today. With currently available drivers MorphOS 3D runs circles around this sam460.

By time time some sort of 3D support will be available for Sam460 MorphOS might have new 3D drivers released. They already run quake3 150fps on puny Radeon 9200.

I won't even bother splitting hairs about using PCIE<->PCI bridge and all that nonsense which might allow Macs to use some yet unknown future gfxcard.

If a bridge is still limited to PCI speeds.  I'm glad you are basing Mac power on this 'magic bridge'...

[Louis Dias]

@lou_dias

So any comment on as to why this Sam460 with supposedly superior memory bus loses to 6+ year old Mac mini G4? Or did we change the subject already?


So again, what are you basing this claim on? Or did you just assume something here without actually checking?

I know memory allocation on OS4 is slower than MOS, so I really don't dispute the data.
I told you the OS is irrelevant to me.  Regardless, despite OS4's inefficiency, it still beat the G4 on some tests.

In the ones that matter to me where real world benefits can clearly be seen (read gpu speeds) the Mac loses.

If a task takes 50% cpu power on a SAM but only 33% cpu power on a Mac and they complete in virtually the same amount of time, I don't see a difference, but when a game like Quake 3 can run at much higher framerates on the SAM460 because the actual cpu overhead of that game can even be handled by a Sam440, then I see a difference.

Understand?

[Piru]

I know memory allocation on OS4 is slower than MOS, so I really don't dispute the data.
I told you the OS is irrelevant to me. Regardless, despite OS4's inefficiency, it still beat the G4 on some tests.

Oh interesting. Now if you'd just tell me what memory allocation speed has to do with memory access performance? I don't quite follow.

In the ones that matter to me where real world benefits can clearly be seen (read gpu speeds) the Mac loses.

Lets check again once the GPU is actually used for anything. You know... in real world.

[Piru]

Quake 3 loads everything it needs into the gpu at the start of the level.

Actually with quake3 only textures are loaded to the graphics card memory.

Everything else is transferred per frame, and this accounts to typically several hundreds of KB of data up to 1MB.

Also since these transfers are synchronous on current OS4 3D system the CPU is busy performing these transfers. MorphOS 3D system uses asynchronous AGP transfers leaving the CPU free to perform other tasks.

[Louis Dias]

Oh interesting. Now if you'd just tell me what memory allocation speed has to do with memory access performance? I don't quite follow.

Lets check again once the GPU is actually used for anything. You know... in real world.

Look, the SAM beat the Mac in many of the write tests:

L1 WRITE64: 8882 MB/Sec
vs
L1 WRITE64: 3794 MB/Sec

for example.  Mac only beats the read tests by about 20% but in some of the write tests the SAM wins by a wider margin.

So yes, overall I would say I'll take the SAM particularly because it killed the mac on video bus speed.

You tell me what's more important in a cpu: reading or writing data to memory?
I say both.  So to me I don't see the G4 with an advantage here.  Getting info into a cpu is useless without getting it out as well.

My advice: port MOS to SAM460...then compare Apples to SAMs...and increase your potential available hardware at the same time.

[Louis Dias]

Actually with quake3 only textures are loaded to the graphics card memory.

Everything else is transferred per frame, and this accounts to typically several hundreds of KB of data up to 1MB.

Also since these transfers are synchronous on current OS4 3D system the CPU is busy performing these transfers. MorphOS 3D system uses asynchronous AGP transfers leaving the CPU free to perform other tasks.

Texture mapping is the bulk of what the gpu is doing.  They get loaded once into the gpu at the start of the level.  The level is fixed.  Only the players "move".  The level is much bigger than the players.  The rendering is done on the gpu based the camera position passed from the cpu and player positioning.  Please don't twist things.  The cpu is reading player input and keeping track of the two combatants and bullets.  Once the level starts, the bandwidth used to send data to the gpu is low.  It boils down to the gpu being able to render the scene without dropping frames.

On the DV player, data is constantly being streamed over the to the GPU for displaying hence the bigger improvement in framerates via the PCI bus driver upgrade.

Stop making it an OS issue when it's mostly a hardware issue.  SAM440 is underpowered.  We know this.  SAM460 is much better hardware than only the cpu comparison over the '440 shows.

[Piru]

Look, the SAM beat the Mac in many of the write tests:

L1 WRITE64: 8882 MB/Sec
vs
L1 WRITE64: 3794 MB/Sec

Oh, can you tell me what cache speed has to do with system bus speed?

[Piru]

The level is fixed.  Only the players "move".  The level is much bigger than the players.  The rendering is done on the gpu based the camera position passed from the cpu and player positioning.  Please don't twist things.  The cpu is reading player input and keeping track of the two combatants and bullets.  Once the level starts, the bandwidth used to send data to the gpu is low.

This is not how Quake3 works. Quake3 doesn't keep any static data on the GPU other than the textures. The current frame is calculated with the CPU and then this geometry is uploaded to the GPU for rendering. This amounts to considerable traffic. With OS4 this leads into major slowdowns due to CPU being busy uploading the data.

Stop making it an OS issue when it's mostly a hardware issue.  SAM440 is underpowered.

It very much is an OS issue. OS4 3D drivers are very very slow. It has little to do with HW.

This is easily validated by comparing Pegasos 2 with Radeon 9250 first by booting into MorphOS and then AmigaOS4. MorphOS is more than twice as fast as OS4 running quake3. This is common knowledge.

[Louis Dias]

Oh, can you tell me what cache speed has to do with system bus speed?

Plenty.   That's what the cpu's working with until a flush is required.

[Louis Dias]

This is not how Quake3 works. Quake3 doesn't keep any static data on the GPU other than the textures. The current frame is calculated with the CPU and then this geometry is uploaded to the GPU for rendering. This amounts to considerable traffic. With OS4 this leads into major slowdowns due to CPU being busy uploading the data.


It very much is an OS issue. OS4 3D drivers are very very slow. It has little to do with HW.

This is easily validated by comparing Pegasos 2 with Radeon 9250 first by booting into MorphOS and then AmigaOS4. MorphOS is more than twice as fast as OS4. This is common knowledge.

I fail to see how OS boot speed has anything to do with the price of tea in China.

[Piru]

Plenty.   That's what the cpu's working with until a flush is required.

Those benchmarks do not flush to memory at all, they work inside the cache. The L1 cache performance numbers have nothing to do with memory bus performance.

As I've mentioned before, the fastest PPC Mac (G5) used DDR2-533 memory.

So if we're talking about the memory performance clearly we're not interested about the CPU internal cache. Or did we again change the subject?

[Piru]

I fail to see how OS boot speed has anything to do with the price of tea in China.

to run quake3 was missing from my post. Fixed it.

You still argue that it's a HW issue?
Also I still don't understand how memory allocation speed affects the memory access speed.

[Louis Dias]

Those benchmarks do not flush to memory at all, they work inside the cache. The L1 cache performance numbers have nothing to do with memory bus performance.


So if we're talking about the memory performance clearly we're not interested about the CPU internal cache. Or did we again change the subject?

No, but they have everything to do with cpu performance which you cite as poor on the SAM460 though it clearly beats the G4 in a # of aspects.

[Louis Dias]

to run quake3 was missing from my post. Fixed it.

You still argue that it's a HW issue?
Also I still don't understand how memory allocation speed affects the memory access speed.

I suppose if I had an OS4 and MOS box then I could see what you mean.

As for memory allocation speed, when initiating any transfer, is this step not required?  I don't know the size of the transfers in question but let's say they were done in 1k chunks.  The memory must be allocated for the transfer to begin.  If the tests included those requests then they would be skewed towards the OS with the most efficient allocator.

The smaller the chunk, the more exagerated the results of the the transfer.

On a lower level, was the OS4 transfer done in full DDR2 burst mode?  If not you wont' see speeds over DDR1.   There's alot of variables here.

Is the FPGA in the SAM460 the memory interface?  It may not be operating in burst mode yet.

All in all, I think you are prematurely bashing the hardware as an excuse to clandestinely bash the OS it's running on.  So, I repeat: port to SAM460 then tell us how bad it is...

[Piru]

As for memory allocation speed, when initiating any transfer, is this step not required?

Of course it is not. These memory speed benchmarks only allocate the buffer once, and this time spent allocating the memory is not accounted.

I don't know the size of the transfers in question but let's say they were done in 1k chunks.  The memory must be allocated for the transfer to begin.  If the tests included those requests then they would be skewed towards the OS with the most efficient allocator.

The smaller the chunk, the more exagerated the results of the the transfer.

You're seriously confused.

On a lower level, was the OS4 transfer done in full DDR2 burst mode?  If not you wont' see speeds over DDR1.

If that is the case then this SAM460 has a lot more problems the issues listed so far...

[Louis Dias]

Those benchmarks do not flush to memory at all, they work inside the cache. The L1 cache performance numbers have nothing to do with memory bus performance.


So if we're talking about the memory performance clearly we're not interested about the CPU internal cache. Or did we again change the subject?

Aren't you the one changing the subject?

You called the SAM460 a poor performer.
Test show in some aspects it outpeforms a G4 Mac...
A G4 Mac does not even use DDR2 to my knowledge.  The memory test you posted is questional in the sense that I don't know if the memory controller in the '460 is actually running in burst mode because if it did, I would expect the memory tests to have favored it.

You then tried to blame to OS...which we know is your ultimate goal.

I pointed out that it may at some point outperform a G5 Mac on memory transfers since it used at best DDR2-533 and SAM460 *might* support faster memory (ala DDR2-800 or 1033) and also support faster video cards since is has native PCIex16 support.

So, no the SAM460 doesn't have Altivec, but it still has more than enough juice to hold it's own.