Microsoft Please Read! Re:XScale optimization

[Bandung]

Thanks for the thread pixelator.

Take a gander at this discussion between the Pocket Divx developer and Pocket TV.

More Insites of E740 Lower Performance It seems that PDivx is not seeing the same variances in performance between machines of the same manufacturer.

I noticed that PTV referred to the same thread as you.

I can share several other threads on the PDivx board that shows users experiencing performance gains on the XScale. However, some do report that there are variations between manufacturiers. (which would point to a manufacturer's problem)

On the other hand, the variance in performance for the same manufacturer's unit, is puzzling. Why with PTV and not PDivx, is a mystery.

The first difference that comes to mind for me is that the PDivx developers code mostly at the assembler level whereas Pocket TV does not.


Digital-Doc
I buy that. Can't get blood from a turnip.

As ugly as encoding in assembler may sound today (it is ugly - I wouldn't want to get blood in this fashion) it is one work-around that works.

[PocketTV Team]

> The first difference that comes to mind for me is that the PDivx developers code mostly at the assembler level whereas Pocket TV does not.

If you look at the PDivx source code, you'll see that most of it is C code, except for a few routines optimized in MIPS assembler (irrelevent to ARM/Xscale). There is virtually no ARM assembly code in PDivx.

But different video applications can behave very differently on various processors because they use different algorithms and optimizations. Some do more memory access or access the memory in different ways (sequencial, non-sequencial), some do more calculations. So different applications can behave very differently on ARM and Xscale.

And if you include the Toshiba e740 in that, you get even more discrepensies depending whether video applications use the ATI hardware acceleration or not.

[Bandung]

Thanks for the correction, I meant to say that their Divx optimizations (although few in terms of percentage to overall code) are mostly done in assembler. The bulk of the player, skins and all are in C. As Gottahavit was saying, their priorities for optimization are Divx, then the player, then OGG.

But of course, you were only kidding when you were visiting their site in July and hammering them for using assembler optimizations whereas you don't. (By the way, that in itself - your lack of compiler optimizations using assember - is pretty impressive)

Project Zayo

[pixelator]

Originally posted by jeff


I am not missing that point, I am choosing to separate a different issue out.

Just kindly stop quoting my words while repeatedly ignoring my stated intent of their meaning. Thank you.

OK, I could say the same thing to you, so I guess we're done.

b

[Bandung]

Originally posted by Digital-Doc
"Work Arounds," are one thing but you can't get blood out of turnip (existing tools).

I really like that quote, Doc.

eVC 4.0 XScale Optimizations Now this is a hoot..

Quote from the Pocket Divx Developer...
-----------------------------------------------------------
"... all in all very dissapointing, I managed to compile PocketDivx using the new ARM compiler from EVC 4.0, using the new xscale otpimization flags and got only the slightest performance improvement on the e740 and a very bad performance hit on the IPAQ 3900(can't explain it).

So these optimizations would not appear to be at the heart of the xscale performance problems as many articles would have you think.

of course I also got a smaller performance decrease using this new compiler with just the straight ARM flags and my IPAQ 3635. So it seems instead of improving performance as we go forward microsoft is actually degrading it. guess EVc4.0 is out for now.

I will move on to try the Intel IPP routines for xscale, though I do not expect much as the SA versions of these were slower than our own code a year ago.
----------------------------------------------------------------

The joys of having turnips for tools.

[SiGen]

Originally posted by jk27
Here's the e310 benchmarks (VOBenchmark):

CPU: Floating Point 8.02
CPU: Integer 15.49
Graphics: Bitmaps - BitBlt 57.45
Graphics: Bitmaps - StretchBlt 0.35
Graphics: Filled - Ellipse | Rectangle | Rounded Rectangle 2.32 | 7.59 | 1.66
Memory: Allocation 8.68
Memory: Fill 0.39
Memory: Move 0.74
Text 3.60

Here's the e330 benchmarks:

CPU: Floating Point: 9.45
CPU: Integer: 20.05
Graphics - Bitmaps - BitBlt: 56.39
Graphics: Stretch: 0.30
Graphics - Filled Ellipse| Rectangle | Rounded Rect: 1.78 |6.46 | 1.03
Memory Allocation: 9.50
Memory Fill: 0.95
Memory Move: 0.36
Text: 3.57

****************

I'm no engineer, but these look pretty close to me, with the e330 besting the e310 in several of these tests (e.g., floating point, integer, memory allocation, memory fill). And the e330 has a 300 MHz Intel? PXA 250 Applications Processor. If the processor is just about as fast, plus uses less energy -- what's the problem?

I would imagine a 400mhz Xscale would perform even better. Am I missing something?

"If the processor is just about as fast, plus uses less energy -- what's the problem?"

... just thinking the same thing...

[PocketTV Team]

Originally posted by Bandung
I really like that quote, Doc.

eVC 4.0 XScale Optimizations Now this is a hoot..

Quote from the Pocket Divx Developer...
-----------------------------------------------------------
"... all in all very dissapointing, I managed to compile PocketDivx using the new ARM compiler from EVC 4.0, using the new xscale otpimization flags and got only the slightest performance improvement on the e740 and a very bad performance hit on the IPAQ 3900(can't explain it).

So these optimizations would not appear to be at the heart of the xscale performance problems as many articles would have you think.

of course I also got a smaller performance decrease using this new compiler with just the straight ARM flags and my IPAQ 3635. So it seems instead of improving performance as we go forward microsoft is actually degrading it. guess EVc4.0 is out for now.

I will move on to try the Intel IPP routines for xscale, though I do not expect much as the SA versions of these were slower than our own code a year ago.
----------------------------------------------------------------

The joys of having turnips for tools.

That's basically correct. The ARM C++ compiler of eVC++ 4.0 has a known bug causing it to:

1) generate StrongARM code that is noticeably slower than the code produced by the eVC++ 3.0 compiler

2) generate even slower code on Xscale when the Xscale code scheduling option /QRxscale is turned "on" (i.e. this option works has the exact opposit effect of what it is supposed to do, namely generate code that runs faster on Xscale)

These are known bugs, and they have been around for a long time, so it does not look that they have a very high priority on MS's todo list. I heard (from someone at Intel) that the ARM compiler was fixed in 4.1 (available in the form of a service pack), but it seems that it is not the case, according to our recent tests.

[JK27]

Originally posted by SiGen



"If the processor is just about as fast, plus uses less energy -- what's the problem?"

... just thinking the same thing...

Can anybody answer this question?

[toshtosh]

Yes, I can...

There's nothing wrong with it.

Truth is the processor doesn't run as fast as though, it's a bit slower (nobody object to that please). At least it runs the current set of apps a bit slower. This will be more so apparent for the 300MHz Xscale devices. You can check the e310/e330 forum for a comparison of Pocket TV numbers.

That being said, most people would not notice the difference, and happily take a 30% battery life increase over that performance loss. This hasn't been confirmed, but it will become clearer how much the gain is once more people get the e330 (since it's in every other aspect identical to the e310).

There also other advantages to the Xscale over the SA since it offers a lot more built-in features to manufacturers.

It is unfortunate that there is no support for 200MHz FSBs for the current XScales, since that would have made these units much faster than the SA206 in ADDITION to the extra battery life.

[toshtosh]

People are just dissapointed because they expected higher performance AND better power consumption. Or something like same performance + 80% lower power consumption. As it is now, it's debatable if this was a step forward in terms of functionality.