Amiga OS4 & CeBit 2003

[ghauber]

That would Not be good. A quick look at TAO's website...

TAO intent "intent is a binary portable platform, independent of programming language, operating system and processor, so the content, which can be written in C, C++,"...

Developers with vast experience in C/C++, but little knowledge of intent, would be wise to first prototype your application in C/C++, then later if needed optimise it for VP asm.

Not bad at all, I think.  My impression of the statements above that Tao have made is such that people don't fear that they have to program in VP in order to program in intent - they can get along quite happily in C or C++ if they so desire.

Myself, I program in intent in a mixture of VP assembly and Java.  I have no desire to use C or C++ on the platform.  VP is quite a nice assembly language, especially with all the standard and very handy macros.

Anything written in VP can easily be accessed by programs written in C/C++ anyway, so there's no issue there, either.

[Juzz]

On personal note; The following benchmarks would be nice.  1. Quake I and II (SW render) 2. 68K AmigaMark 2003. 3. MPEG2 to MPEG4 conversion.

Well one of the others with an XE tested Sin against an AMD Duron 850. The timedemo yielded 10 FPS on the AMD and 19 FPS for the G4.
Timerefresh yielded 13 FPS on the Duron and 26 FPS on the G4.

Quake x86 has an assembler texture mapper, whereas the PPC is using a 'C' texture mapper.

[Juzz]

AltiVec support for OGR has always been in the PPC Linux client AFAIK

Yes, for the CPU's that the client recognizes (ie. the ones that has been added to the source of the client).
And it has to be compiled via an Altivec enabled compiler AFAIK.

Well one of the others with an XE tested Sin against an AMD Duron 850. The timedemo yielded 10 FPS on the AMD and 19 FPS for the G4.

For this benchmark to mean anything, more information about the test must be known: The smaller L2 cache could be a big problem for the Duron, the PPC version might be better optimized(likely since most PC games assume 3D hardware), the memory size and speed could influence the scores as different operating systems etc.

I'd rather trust SPEC.

Vidar

[Seehund]

Juzz wrote:

AltiVec support for OGR has always been in the PPC Linux client AFAIK

Yes, for the CPU's that the client recognizes (ie. the ones that has been added to the source of the client).
And it has to be compiled via an Altivec enabled compiler AFAIK.

But you do use a supported CPU (this is the Teron PX with an 800 MHz 7451, right?), and you do get the same result as other AltiVec enabled clients on the same CPU in the dnet client speed database.
BTW, the client supports AltiVec without being recompiled  (dnet only distributes binaries anyway, don't they?).

The remarkable thing about your "benchmark" (yeah, dnetc runs are largely meaningless to measure anything else than "how fast can this CPU crunch RC5 keys and OGR nodes?" ) is that the 2.4 GHz P4 sucks so abysmally on OGR!
On the ~1.75 GHz Athlon box here I get about 13 Mnodes/s. Per processor...

[Hammer]

Well one of the others with an XE tested Sin against an AMD Duron 850. The timedemo yielded 10 FPS on the AMD and 19 FPS for the G4.

That claims looks a bit skewed when one compares cut-down CPU against a full-featured CPU.  

Why the AMD Duron? It's 2nd Level Cache is heavily crippled.

Those cut-down X86 chips don’t perform very well with games i.e. run Quake II (in SW mode) Athlon VS Duron.  

Why not the full featured AMD Athlon XP chip? There should be an AMD Athlon XP chip around the PPC G4 800Mhz’s price bracket.

Just be careful with the X86 based comparisons.

I’m curious why they use SIN has the game benchmark, while Quake I/II was the engine for multitude of game titles.

Did they use an Intel complier for SIN source code?
 

Quake x86 has an assembler texture mapper, whereas the PPC is using a 'C' texture mapper.

Why not recompile the same source code(i.e. C language source) for both platforms?

Could you disclose the actual benchmark setup for SIN?

X86 SIN based benchmarks was use in the late 90s (during reign of Pentium II/III 440BX era).

[tonyw]

@Juzz:
"Well, you and Tony can start looking forward to playing with the A1XE - it is running very nicely
Actually it is this board that I am using to post right now - using SuSE PPC 7.3 and Opera 6.11 "

Hey, Juzz, I've been following your exploits on the ML. I can't wait to get my own.

tony

[Juzz]

But you do use a supported CPU (this is the Teron PX with an 800 MHz 7451, right?), and you do get the same result as other AltiVec enabled clients on the same CPU in the dnet client speed database.

Hmm... Well I tried the short version...
But, no the dnetc client does not see the Altivec unit in the G4 yet!
I am not sure why, but it simply refuses to run the PPC-Vector core - which is the one using the Altivec. I have even tried manually selecting the altivec-enabled core, but no go....
So I am in the process of compiling gcc-3.2.2 right now, so that I can compile the source code that I have altered (in cooperation with some of the other developers - they point, I try to insert the right things at the right place).
And, yes, distributed.net does give out their source code - however they are the only ones allowed to distribute the binary - so if anyone improves the source code to include more platforms/cpu's whatever - then you have to submit the code to them - and then they will release the fresh binary.
 :-)

[Hammer]

I’ll test it in Athlon XP 1800+/ASUS nForce 2-Deluxe later…    

Athlon XP 1800+, ASUS nForce 2, WinXP-SP1
==========================================
[Feb 19 01:15:35 UTC] Automatic processor type detection found
                      an AMD K7-6 (Athlon XP/MP/-4) processor.
[Feb 19 01:15:35 UTC] OGR: using core #0 (GARSP 5.13-A).
[Feb 19 01:15:55 UTC] OGR: Benchmark for core #0 (GARSP 5.13-A)
                      0.00:00:16.71 [12,000,449 nodes/sec]
...
==========================================
Running 24 processes in the background.