Portal Player Battery runtime vs compiler

[scharkalvin]

I recently noticed some benchmarks comparing several different arm compilers used for embedded developement.  I was shocked to see that GCC was pretty bad compared to some of the commerical tools, in fact it produced code that ran as much as an order of magnitude slower in some benchmarks.  Could this be part of the reason for poor runtime on the portal player targets?  Has anybody tried building rockbox using one of the better commerical compilers?   (probably would take a lot of editing to fix syntax differences between compilers)

The only flaw in this is the Gigabeat (also an arm cpu) that doesn't suffer as badly in runtime compared to the OF.

[AlexP]

In fact the gigabeat battery life under rockbox is at least as good as the OF if not longer.

[scharkalvin]

Well Toshiba might have compiled their firmware using GCC (level playing field).

[GodEater]

Has anybody tried building rockbox using one of the better commerical compilers?   (probably would take a lot of editing to fix syntax differences between compilers)

I don't believe so.

We're pretty convinced it's not the code from gcc which is the issue.

[linuxstb]

Whilst we all agree that gcc can be pretty bad at generating ARM code, it's probably worse at generating code for Coldfire, and Rockbox manages longer runtimes than the original firmware on all targets.

In addition, a lot of the performance-critical code has been optimised in ARM assembler, making gcc irrelevant.

Also, Rockbox is an open source project - we simply don't want to use closed-source (and expensive) commercial compilers, for both practical and philosophical reasons.

Buthaving said that, if someone wanted to get Rockbox to build with such a compiler, I'm sure we would all be curious to know the results.

[LambdaCalculus]

It's been mentioned in the past that lack of understanding of certain PP registers is the issue. We can't shut off certain parts of the PP chipset that aren't used. (Correct me if I'm wrong.)

Where's a PortalPlayer datasheet when you really need it?

[saratoga]

 I was shocked to see that GCC was pretty bad

You must be easily surprised.

[scharkalvin]

I'm using GCC for the AVR processor at work and the performance is
quite good.  Maybe we could do better with a professional tool set,
but it hasn't been an issue.  In the PC (x86) area GCC probably DOES benchmark
quite good.  Then again, that's where it's used the most and has seen the most testing.

The issues with the Portal Player cpu make sense to me, it sounds like a special purpose chip designed for use in media players while Gigabeat is using a GP arm cpu with well know other parts.  Oh, well so much for low hanging fruit.

[Llorean]

Another point is that on one PortalPlayer CPU (the PP5002 at least) we now perform better than the Apple firmware. It's just our knowledge of the PP502x series that's restraining us.

Considering we're beating the Apple firmware on the early generation iPods, I'd suggest wholeheartedly it's not GCC that's the problem.

[LambdaCalculus]

Another point is that on one PortalPlayer CPU (the PP5002 at least) we now perform better than the Apple firmware. It's just our knowledge of the PP502x series that's restraining us.

Yes, that's true. I read that now even the 2nd gen iPod surpassed the OF battery life.

If we just had that information for the PP502x series in our hands... datasheets, register values, anything! It seems that the H10 (PP5020) and Sansa e200 (PP5024) are the worst offenders for battery life; solving this issue should help them out immensely.

[saratoga]

Another point is that on one PortalPlayer CPU (the PP5002 at least) we now perform better than the Apple firmware. It's just our knowledge of the PP502x series that's restraining us.

Yes, that's true. I read that now even the 2nd gen iPod surpassed the OF battery life.

If we just had that information for the PP502x series in our hands... datasheets, register values, anything! It seems that the H10 (PP5020) and Sansa e200 (PP5024) are the worst offenders for battery life; solving this issue should help them out immensely.

The e200 is actually one of the best PP targets for battery life.  I think until the P5002 improvements it was the best.  It seems to use less power then the other PP targets, perhaps because the lack of IDE hardware means theres less stuff for us to have improperly initialized.  

[tychver]

Possibly a stupid question but have any improvements been seen when newer GCC versions were used? The wiki still recommends 4.0.3 for ARM. Didn't 4.2.2 just come out? I noticed the daily builds are still done with it.

[Lear]

I just made a quick test using 4.2.2. No big differences that I could see. Build size was about the same (comparing slightly different versions though), and the speed difference (for the codecs I tested) was small. 1-2 percent or so, sometimes faster, sometimes slower. So there's no particular gain by updating the compiler.

[tychver]

Just out of interest, which codecs were faster and which were slower? How well does rockbox parallelize across both cores? Last time I was messing around with it I think it had got to the stage of running UI and WPS and kernel on one core and the codec thread on the other.

Is this going to make a big difference to the ammount of work done in parallelizing? It sounds like it: http://gcc.gnu.org/wiki/AutomaticParallelization

Sorry if it's a stupid question; the most complex things I did were hacking up the scroll acceleration patches.

[saratoga]

How well does rockbox parallelize across both cores? Last time I was messing around with it I think it had got to the stage of running UI and WPS and kernel on one core and the codec thread on the other.

Rockbox does not parallelize across cores yet, except for mpegplayer and the SPC codec (assuming that got committed).

Is this going to make a big difference to the ammount of work done in parallelizing? It sounds like it: http://gcc.gnu.org/wiki/AutomaticParallelization

No thats not useful to us, and probably not very useful in general.  Autoparallelization is pretty ineffective.