Pandora, Some Actual Performance Numbers ..

[Vorporeal]

Totally agree with the above. Each component has been, by itself, extremely impressive. When we combine all of these together, we will end up with the closest possible thing to the "ultimate device". ULTRA-portable, very powerful, with lots of room for connectivity and expansion. What more could you ask for?

Hold on a cotten-picking second here!

How's that saying go? "You're only as strong as your weakest link."

What I mean to say is, there could be a bottle neck somewhere that could really throw a wrench into the works in terms of theoretical peak performance from the sum of all it's parts.


True. From what I've been reading in the various threads about the hardware, the various parts are designed to optimally use the system's bandwidth. The SGX has special features that decrease bandwidth, and I think I remember someone saying that the Cortex does too. I think TI chose parts very specifically for the OMAP so as to reduce(/eliminate?) bottlenecks and squeeze maximum performance out of every individual component.

But yes, we shall see. And very soon, it seems.

 

[MDave]

I know below is an old quote, but I've just discovered something interesting:

I tried this today. I guess I don't have everything on my card needed to run the test all the way through but at 600MHz these are the results I got (and it stops here at any speed):
CODE
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 246.24 : 6.31 : 2.07
STRING SORT : 33.986 : 15.19 : 2.35
BITFIELD : 9.0931e+07 : 15.60 : 3.26
FP EMULATION : 62.046 : 29.77 : 6.87
FOURIER : 270.59 : 0.31 : 0.17

Notaz did a 900MHz test months ago (on a much older kernel, 2.6.22 I think). He knows more about making sure all dependencies are met than I do. I will post his results. I hope he doesn't mind but it fits this topic well:
CODE

TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 363.48 : 9.32 : 3.06
STRING SORT : 49.96 : 22.32 : 3.46
BITFIELD : 1.3284e+08 : 22.79 : 4.76
FP EMULATION : 91.527 : 43.92 : 10.13
FOURIER : 395.63 : 0.45 : 0.25
ASSIGNMENT : 5.8503 : 22.26 : 5.77
IDEA : 982.24 : 15.02 : 4.46
HUFFMAN : 604.53 : 16.76 : 5.35
NEURAL NET : 1.1844 : 1.90 : 0.80
LU DECOMPOSITION : 66.92 : 3.47 : 2.50
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 19.739
FLOATING-POINT INDEX: 1.437
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
MEMORY INDEX : 4.562
INTEGER INDEX : 5.217
FLOATING-POINT INDEX: 0.797




And below is a quote taken from the spanish pandora forums, concerning the results taken from the Xbox's 733mhz processor:
CODE


TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 381.54 : 9.78 : 3.21
STRING SORT : 29.968 : 13.39 : 2.07
BITFIELD : 1.0268e+008 : 17.61 : 3.68
FP EMULATION : 26.875 : 12.90 : 2.98
FOURIER : 8896 : 10.12 : 5.68
ASSIGNMENT : 5.8271 : 22.17 : 5.75
IDEA : 1237.2 : 18.92 : 5.62
HUFFMAN : 630.19 : 17.48 : 5.58
NEURAL NET : 9.3681 : 15.05 : 6.33
LU DECOMPOSITION : 352.41 : 18.26 : 13.18


So is it correct to guess that the Pandora has about the same performance as the xbox's processor when clocked to 900Mhz? Seems that floating point emulation is much higher on the Pandora too.

 

[mali]

The problem is still the low FP result. Memory and integer are top notch, but FP is very low and doesn't make much sense. Maybe it's a compiler fault? Is Neon maybe disabled because of the older Neon bug?

Edit:
Clueless as I am, maybe it would be better to see Neon as an MMX-like equivalent in handheld space as opposed to call it FPU. Following this would lead to the understanding, that Cortex has got no real FPU. FPU is simulated by VFP or Neon extension?
In 3D games with software rendering this would lead to bad performance, but if SGX does the job, it's no problem.

 

[notaz]

Clueless as I am, maybe it would be better to see Neon as an MMX-like equivalent in handheld space as opposed to call it FPU. Following this would lead to the understanding, that Cortex has got no real FPU. FPU is simulated by VFP or Neon extension?

Yeah, this seems to be closer to how it is. VFP is the FPU, and it's rather weak. Older Cortex-a8 documentation called it "VFPLite", newer dropped the "lite" part, probably due to marketing reasons.

VFP and NEON are closely related though, they share the same register bank. The mystical "RunFast" mode is supposed to allow running certain VFP instructions in NEON pipeline.

 

[lardman]

VFP and VFPlite are different hw afaik.

I agree, still strange that the ARM1136 is faster than the Cortex for fp stuff.

Looking at my post (#64) the effect of compiling nbench for vfp is not that large 1251.6 (with) vs 970.92 (without) assuming you always link against a vfp enabled libm. Perhaps the optimisation/-mcpu settings of the glibc compile are what we should be looking at?

 

[mali]

Thanks for the clarification
I'm currently reading through beagle board IRC logs and it seems, that Neon doesn't do anything useful, yet and VFP is somehow crippled compared to OMAP2. Maybe it's a compiler fault? Still reading... unfortunately 99% I don't understand :unsure:

 

[ldesnogu]

Looking at my post (#64) the effect of compiling nbench for vfp is not that large 1251.6 (with) vs 970.92 (without) assuming you always link against a vfp enabled libm. Perhaps the optimisation/-mcpu settings of the glibc compile are what we should be looking at?

Looking at Fourier code shows that it makes heavy use of pow, cos and sin which all are in libm, that explains why having libm compiled with VFP matters
I guess a profiling would show a huge amount of time spent on libm for that particular test.

@notaz: regarding your experiment with using single precision numbers, did you use gcc -fsingle-precision-constant and cosf, sinf, ...?

 

[mali]

What I read so far is, that the reason for ARM1136 VFP being faster(per MHz) is, that it is pipelined vs. none pipelined on Cortex A8.

Edit:
To say it again, I don't understand this stuff. Someone on IRC said, that there is a Neon-patch for 2007q3(I don't know what for). Maybe it would be possible to compile with the newer 2008 version, to test if there are differences?

Edit2:
I've read further and someone said, that NEON is broken in 2008q1 and generates VFP instead of NEON instructions. So if you would compare the results of 2007q3 and 2008q1 and they are the same, that presumably means that NEON is broken in 2007q3, too.

Edit3:
I've reread this thread and obviously I didn't add anything, that wasn't mentioned already. So this leads to the conclusion, that(at least in nbench) ARM11 VFP is superior to Cortex VFP and NEON, no matter what.

 

[notaz]

@notaz: regarding your experiment with using single precision numbers, did you use gcc -fsingle-precision-constant and cosf, sinf, ...?

Yep, I remembered your advice from when I was messing with quake2. I've even checked the generated code.

 

[ldesnogu]

Yep, I remembered your advice from when I was messing with quake2. I've even checked the generated code.

I can't remember that, I am getting really old :lol:

 

[fusion_power]

All these numbers don't say anything to me (as a noob)...so are there some comparisons to other comparable Devices? PSP or NDS or Wii or ARM-powered computers?

 

[Phawx]

It's really hard to tell. I would say that the games would look better than the wii, because we should be able to do physics through DSP. It will kick the snot out of the NDS and handily beat the PSP.

Features > Animation (with physics) > Textures > Polys

I think the Pandora would be able to pull off a dreamcast 1.5 or even a 2.0.

For me most Dreamcast games easily beat PS2 games in terms of image quality. I would expect nothing less than amazing.

 

[sindbad]

I'm not very familiar with the restrictions using NEON apply to your code, but I would expect of the ARM devs to have designed it in such a way that it's easy enough to use it. Things like higher level languages are an obvious example of something that can easily get screwed up by the need to vectorize everything.

 

[maciek_urbanski]

The problem is still the low FP result. Memory and integer are top notch, but FP is very low and doesn't make much sense. Maybe it's a compiler fault? Is Neon maybe disabled because of the older Neon bug?

If I read docs correctly NEON extensions are basically ARM equivalent of x86 SSE extensions.
Both are SIMD instructions with register space shared with FPU. NEON has 3-parameter operands and larger register file ( comparing with x86 in 32-bit mode ) so coding for it should be more efficient...
But in order to use any SIMD extension compiler has to determine, that certain parts of code (mostly loops) can be done in parallel. This means that there must be no dependencies between variables used in run [n] and those used in run [n+1]. When developers know this limitation they can use algorithms that do not have many of those dependencies. But most time they don't. As a result compiler auto-vectorization of general-purpose code is a very hard task.

Basically I'm trying to write that switching on NEON optimizations in compiler will result in executable in which only small parts of code are compiled for NEON.
If we want more - we must tweak/rewrite algorithm removing some variable inter-dependencies.
If we want to be sure - we must use NEON assembly (which is a beauty comparing it to SSE). B)

 

[mali]

Thanks for explaining Maciek
I hope good devs will gain more by optimizing their code to use NEON than they would have gained by using a pipelined VFP like ARM1136 has. I find the decision to implement NEON and rendering the VFP unit basically useless kind of curious, because from reading through some Beagle Board sites it seems the NEON extensions are foremost a way to help decoding media, which is kind of redundant, because it is much better to use the DSP for that stuff. An ordinary FPU would have had the benefit, that "lazy" coders would have had an instant benefit.
Edit:
I just remember the difference between ordinary Quake 2 software rendering vs. the 3Dnow! optimized version. The lighting was a little better, but there was barely a big performance increase.
Edit2:
Thinking about the fact, that Cortex isn't necessarily bundled with a DSP, this makes more sense. If an ARM licensee wants to create a very cost effective design, he might just take the Cortex without additional components like the DSP TI decided to use. In this case NEON would help. But in OMAP3 with its DSP it's more like a hurdle to me.

 

[ldesnogu]

I hope good devs will gain more by optimizing their code to use NEON than they would have gained by using a pipelined VFP like ARM1136 has.

There's no doubt NEON code will run much faster as pipelined VFP code: it can execute two single precision FP computations per cycle.

QUOTE
I find the decision to implement NEON and rendering the VFP unit basically useless kind of curious, because from reading through some Beagle Board sites it seems the NEON extensions are foremost a way to help decoding media, which is kind of redundant, because it is much better to use the DSP for that stuff.

Don't forget something: NEON is an ARM Ltd thingie while the DSP is unique to TI. And that DSP doesn't support FP.

QUOTE
An ordinary FPU would have had the benefit, that "lazy" coders would have had an instant benefit.

So making it slow is a good way to see Darwinian selection in action

QUOTE
Thinking about the fact, that Cortex isn't necessarily bundled with a DSP, this makes more sense. If an ARM licensee wants to create a very cost effective design, he might just take the Cortex without additional components like the DSP TI decided to use. In this case NEON would help. But in OMAP3 with its DSP it's more like a hurdle to me.

Heh, you edited I'd also add that it's easier to program a single CPU than a CPU + DSP combination.

 

[mali]

There's no doubt NEON code will run much faster as pipelined VFP code: it can execute two single precision FP computations per cycle.
I really hope so, as it seems to be relatively hard to use. The compiler itself doesn't do much as we can see in the nbench example. A realworld-benchmark like Quake 2 timedemo would be much better IMO It uses FP intensive code AFAIK.

QUOTE
QUOTE
An ordinary FPU would have had the benefit, that "lazy" coders would have had an instant benefit.

So making it slow is a good way to see Darwinian selection in action There has passed quite some development time between ARM11 and Cortex. I think it should have been possible to tweak the VFP further. For a handheld FPU it was quite good IMO. Quake 2 is nicely playable on N800

Edit:
Has someone tried to use an ARM compiler for nBench, yet?

 

[lardman]

QUOTE
Has someone tried to use an ARM compiler for nBench, yet?


Or had a look at the GCC contributions from ARM? Or do ARM only support their own compiler?

QUOTE
The compiler itself doesn't do much as we can see in the nbench example. A realworld-benchmark like Quake 2 timedemo would be much better IMO It uses FP intensive code AFAIK.


nbench also uses fp intensive code, but it's just that that code doesn't appear to compile down to something that Neon can use. Really someone would have to sit down and re-write those fns in asm or in a form that the compiler can recognise as being Neon-able.

But then why waste time re-writing benchmark code when you could of course spend that time improving Quake 2 similarly, etc.

Anyway, I think the thing to take from all this data is that the Cortex will require more care and testing when writing fp code (or GCC will have to improve! ).

 

[ldesnogu]

I really hope so, as it seems to be relatively hard to use. The compiler itself doesn't do much as we can see in the nbench example. A realworld-benchmark like Quake 2 timedemo would be much better IMO It uses FP intensive code AFAIK.

It's difficult because you have to use assembly language, that's life.
As far as nbench is concerned I explained above why the compiler can't do much: nbench is shitty for benchmarking FP as it relies too much on libm functions.
For Quake2, unless someone uses assembly code, NEON probably won't be used by the compiler; note that for x86, Id wrote *many* assembly routines, why do you think things would be different now with C compilers?

QUOTE
There has passed quite some development time between ARM11 and Cortex. I think it should have been possible to tweak the VFP further. For a handheld FPU it was quite good IMO. Quake 2 is nicely playable on N800

Hasn't Q2 been demonstrated as playable on Pandora/BeagleBoard?

QUOTE
Has someone tried to use an ARM compiler for nBench, yet?

Are you ready to pay several thousand dollars for a compiler?

Or had a look at the GCC contributions from ARM? Or do ARM only support their own compiler?

The only gcc variant with improved ARM support is the one from CodeSourcery.

QUOTE
Anyway, I think the thing to take from all this data is that the Cortex will require more care and testing when writing fp code (or GCC will have to improve! ).

I can't agree more

 

[notaz]

Hasn't Q2 been demonstrated as playable on Pandora/BeagleBoard?

At 320x240 it's quite ok, but if you set it to 640x480 it crawls in software mode. 3D acceleration will save it, I hope.