Linaro Tweaks Speed Up Android, By Up To 100 Percent

Argon writes with an excerpt from Liliputing of interest to Android users: "'The folks behind the Linaro open source software project have put a little time into tweaking Google Android to use the gcc 4.7 toolchain. The result is a version of Android that can perform many tasks between 30 and 100 percent faster than the version of Android Google 4.0 Google currently offers through the AOSP (Android Open Source Project).' Adds Argon: "Note that there are CPU optimizations only since they have only access to binary blobs for GPU code."

Comments

Better link

[OzPeter]

After digging through the TFA I found Linaro Android Puts Stock Android To Shame on TI Pandaboard (OMAP4430). Which after digging in the comments leads to www.linaro.org/
 
But the meat of the whole report is contained in this comment from Bernhard Rosenkraenzer which contains some better stats and also links to the toolchains and source code.
 
After this much manual digging I've realized that I'm getting to jaded for /.

Re:Better link

[ya really]

After this much manual digging I've realized that I'm getting to jaded for /.

I still come back to /. out of long time habit, but I stopped looking at /. for real meat on topics sadly some time ago. It's getting to be a lot of spammy articles with little substance compared to what it was five or more years ago.

If you're interested in seeing more concrete discussion with substance, try reading over hacker news one day. They're also discussing Linaro

and most of the commenters on hacker news tend to be developers of various device platforms.

Re:Better link

[Gaygirlie]

Taken from Bero's comment:

Obviously saying we’ve made it “twice as fast” is a bit of an oversimplification.

This particular benchmark (the 3D benchmark included in 0xbench) runs twice as fast on this particular hardware. Other benchmarks (e.g. Sunspider) are “merely” 30% faster, some others are only slightly faster (e.g. GLMark2 – as it’s mostly GPU bound), and it would be possible to craft a benchmark showing that our build is 10 times faster (write a benchmark that uses strcpy, memset and friends heavily, which I’ve actually done, not to show off but to test if our changes are as beneficial as we’re hoping).

As they say, the benchmark used is CPU-bound and as such what you're referring to is irrelevant. You can go ahead and test the optimizations made if you feel like, it is all there. A 3D benchmark was only chosen so they have something more interesting for the spectators to look at than a console application or Sunspider.

Read more: http://www.cnx-software.com/2012/06/03/linaro-android-puts-stock-android-to-shame-on-ti-pandaboard-omap4430/#ixzz1xPbZP4t0

Re:Meaning stats

[negRo_slim]

I know a busy slashdotter such as yourself can't be bothered to move his greasy fingers the fraction of the inch required to actually open the article and as such here is some information you might find of interest:

... and the results are quite amazing with Android Linaro achieving about 60 fps in all 0xBenchmark tests (OpenGL Cube, OpenGL Blending, OpenGL Fog and Flying Teapot) whereas Android stock achieving 30 fps. They selected a benchmark tool that is mainly CPU bound, as they cannot optimize the GPU code since they can only access binary blobs.

Also as you said yourself, it's a summary if you want the meat and potatoes of the data described just click on the damn thing instead of bitching.

Re:next thing to do...

[Anonymous Coward]

Yes, if only they used a modern language like .net then we could have pro-programmers working on it. Too bad no one has come out with a phone like that. I bet it would sell great if promoted by someone with a large desktop install base.

Re:battery life

[amorsen]

It's possible that while the run time is shorter, the power draw is higher--possibly more than proportionally higher.

Possible, but very unlikely. Current processors are quite bad at running at "half power", i.e. if not all function units are running full speed they still waste power. The scheduling strategy "hurry up and wait" still tends to beat other strategies, because modern CPU's are so very good at saving power when idling. You would have to waste an enormous amount of power during the "hurry up" part of the strategy to not win in the end during the "wait" phase.

In a few years this may change, as systems get better at handling partial load. If you could e.g. only keep the memory chips which are used by the current task awake, that would help quite a bit. Today it is AFAIK either all memory chips awake at once or all of them in power save mode. Software support would be fun, as the OS would have to try to keep the working set on as few memory chips as possible.