SAM 460 poor performance, high price

[Piru]

"2) How many AmigaOne boards have been sold so far and what is your  opinion on the demand for the current boards and upcoming Micro1A  boards?

Alan: From the publicly available figures it seems  that we have delivered more AmigaOne boards than any other 'open' (ie  not IBM or Apple) PPC-based standard PC form factor board supplier. And  in terms of real sales for real money (which in my view is the ultimate  measure of success"

http://amigaworld.net/modules/features/index.php?op=r&cat_id=3&rev_id=41&sort_by

Let me pick some highlights from that:

• publicly available figures
• seems

If it was such a great success why didn't Eyetech handle warranties (which were supposedly covered by the profit margin, and was given as reason for the high price!) and why did Eyetech fail? Trying to blame it on MAI doesn't explain it. They were told numerous times that the MAI chipsets were defect.

[Piru]

What does any of this have to do with the SAM460EX?

It's a response to a sub-thread in this topic, mainly regarding generic profitability of custom PowerPC HW. It's not unusual to get borderline OT on a.org

And while the SAM460EX is overpriced, in what fashion is it slow?

It is slow for the price. It is roughly performing like a pegasos II G4 in CPU intensive tasks, assuming you ignore altivec.

I would be willing to bet its memory bandwidth is significantly higher than a Pegasos or a Powermac.

The memory performance is better, yes.

At 1.15 Ghz, this is the fastest board Acube has produced.

No question about that. It's just that faster powerpc HW was produced 7 years ago. You can get faster systems for fraction (literally!) of the price.

[Piru]

Not doubting you, but do you care to toss out some numbers on this? I'd just like to know what size gap we're talking about here in performance.

The only CPU benchmark for SAM460 that I've seen has been the distributed.net client results from a 1GHz SAM460. distributed.net is only bound by the CPU, and there are special optimized cores for AltiVec. This makes it possible to compare the CPUs performing highly CPU bound task with specifically optimized code. This test will not account for the memory bus performance differences, and for that more complex benchmarks would need to be run.

There are two types of distributed.net tasks, OGR and RC5-72.

OGR

• Sam 460 1.0GHz: 10,124,948 nodes/sec
• Pegasos 2 G4 1.0GHz: 20,844,783 nodes/sec
• Mac Mini G4 1.5GHz: 31,267,175 nodes/sec

RC5-72

• Sam 460 1.0GHz: 3,286,052 keys/sec
• Pegasos2 G4 1.0GHz: 10,678,428 keys/sec
• Mac Mini G4 1.5GHz: 15,701,333 keys/sec

The final Sam 460 is said to be running "upto 1.15 Ghz", but multiplying the results by 1.15 doesn't give significantly different results. In fairness the results are not as crushing when executing generic PowerPC code, however.

[Piru]

You can get old mac's for a 50, but you still have to shell out the cost of the OS (150 euro still?).

The MorphOS key file is 111 € (includes VAT).

Also you can test MorphOS for free for as long as you like, 30 minutes at a time. After each 30 minute session the system slows down and you can reboot for another 30 minute testing period. There are no other limitations.

[Piru]

The SAM460 already outperforms a G4 1.5Ghz on large memory intensive tasks.

Really? What are you basing this on?

The numbers I've seen are:

SAM460 AMCC460 1.167GHz

Code: [Select]

---> RAM <---
READ32: 311 MB/Sec
READ64: 310 MB/Sec
WRITE32: 521 MB/Sec
WRITE64: 521 MB/Sec
WRITE: 1251 MB/Sec (Tricky)
Mac Mini 7447 1.5GHz

Code: [Select]

---> RAM <---
READ32: 387 MB/Sec
READ64: 403 MB/Sec
WRITE32: 771 MB/Sec
WRITE64: 771 MB/Sec
WRITE: 809 MB/Sec (Tricky)
(source)

[Piru]

By your own listing there, the last write speed listed was 50% higher probably because it involves writing to main ram.  If these tests were performed using local cache then the Mac will win.

All of these tests go to main memory. There are separate tests to L1 and L2 caches. Ask Crisot for details.

Anyone can make a test that is more favorable to one platform or the other.

This test was created by Crisot, OS4 user. The test was run on SAM460 by OS4 beta tester. Sure you could blame me for trying to use my mind control powers to affect these people but you give me way too much credit.

Even your posting was biased...sad.

Pot, kettle.

[Piru]

SAM460 will run 3D intensive games better than any Mac regardless of what OS is on the Mac.

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.

[Piru]

@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?

The SAM460 already outperforms a G4 1.5Ghz on large memory intensive tasks.

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

[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.

[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.

[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.

[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...

[Piru]

Aren't you the one changing the subject?

I think I have been quite consistent.

I would expect the memory tests to have favored it.

I think we're getting to the core of the issue here. You expected something to to be true, made a bogus claim and now are unwilling to back off and admit your mistake.

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

I didn't bring quake3 to this thread. I merely commented your contradictory and clearly bogus claims.