Slashdot Mirror
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."
that's where the guys with long hair are!
So we're building a faster more powerful android now? I wonder if the end result will be an energy draining old man, or a cocky teenager who's destined to become part of a biological super weapon.
In a bit of shameless internet panhandling, I accept Litecoin Donations at Lbd2oH9QsthD1GfuUXPyka12YxvWJYnBVf
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
I am Slashdot. Are you Slashdot as well?
... 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.
On the Oregon Cost born and raised, On the beach is where I spent most of my days
Well, sure it does. To calculate how much faster it actually is, you take the time it didn't take (infinity - time_it_took) and multiply that by your new factor (1.3 to 2.0), then subtract that from infinity and you have your new rate.
it means the battery lasts longer - if you can twice the work in the same time, that means the same amount of work takes half the time - so you've cut your CPU usage by half.
Of course, this doesn't mean your battery life doubles as most of the battery goes towards running the screen, but you should get a small boost which you''ll see when running CPU-intensive tasks, like games.
The cynic in me says that even if it is a simple patch and recompile for existing android devices, we will never see it from any OEMs--it takes away some of the reason to buy the latest shiny.
Here's hoping for the community android rebuilds...
You're confusing this with something else. 100% faster means twice as fast. As in take the original speed, and add to it 100% of the original speed (e.g. 30 + (30 * 1.0)).
No, you're confusing speed (a calculated value) with time required for completion (the easily-measured value) - they are inversely related to each other. The article claims 100% faster, not 100% less time required. In car terms: a car going 200mph is 100% faster than one going 100mph, and 300% faster than one going 50mph. The relevant equation is
(percentage change) = (measured quantity - reference quantity) / (reference quantity)
or alternately
(percentage change) = (measured quantity) / (reference quantity) - 1
which should make makes it obvious that the possible value range is [-100%, infinity)
--- Most topics have many sides worth arguing, allow me to take one opposite you.
There's also another interesting research project: Porting Android to C# running under mono.
In a benchmark they made (granted, it was focused on generics, where C# has serious performance advantage against Java), the port was about seven times faster.
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.
You clearly didn't read much. They are using a graphical benchmark because they need something to show to the spectators. Showing a console benchmark application or Sunspider wouldn't draw anyone's attention at Linaro Connect. Also, none of the code they did is related to graphics at all, they've e.g. optimized memset and strcpy which very very clearly have nothing to do with graphics or GPU whatsoever. Read the following excerpt from Bero's comment below:
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).
In the last screen of the benchmark/demo, you see 4 different tests that are each one individually exactly at 60FPS +/1 FPS for the Linaro build and 30FPS +/- 1 for the stock build... Better not question the coincidence and make a slashdot article about that 100% speed improvement !
You might wish to practice on your reading-comprehension skills: none of the things Linaro devs did are Pandaboard-specific.
That's not guaranteed at all. The power consumption of a CPU is a function of a huge variety of things. It's possible that while the run time is shorter, the power draw is higher--possibly more than proportionally higher.
Yes...I am a rocket scientist.
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.
Finally! A year of moderation! Ready for 2019?
100% as fast would be 1.0x. They said 100% faster, which is (x + 1.0x)
Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
.net is the only time I've seen 'Hello, World' take thirty meg of of memory to run - not including the shared libraries. It's great if you want to get the programming done fast and in a way that minimises the number of mistakes the programmers will make, but the expense is greatly increased CPU and memory usage. Exactly what you don't want on a portable device.
> Does your Mustang manage frame drops on home screen on dual core 1GHz SoC? >100ms audio lag? >100ms input lag? Android does.
Only if you run with stock CPU governor.
For a quick & dirty experiment to show what your phone is genuinely capable of if you were to root it and reflash with a kernel that supports a governor based on the 'interactive' strategy, try this: root your phone, then install SetCPU. Choose 'performance', which forces the phone to run at max speed. Keep in mind that with most stock kernels, you're still running single-core at this point. Nevertheless, compare your experience to what you normally see. Beware: it's very, VERY hard to letting any CPU governor run once you've gotten spoiled by 'performance' mode. But you'll have to, because performance mode will nuke most batteries in an hour or two.
I have three Android phones: a HTC Hero (CDMA), a Samsung Epic4G (Galaxy S), and a Motorola Photon. The Hero, overclocked and locked to ~711MHz, feels smoother and faster than my allegedly 1-GHz dual-core Photon. Graffiti input is flawless and error-free. On my Photon, I can hardly ever enter 10+ consecutive characters without recognition errors, partly because Motorola's stock kernel (which the bastards won't allow me to modify) thrashes the CPU speed all over the place (but mostly down) and confuses the hell out of Graffiti. It's really sad that a 16Mhz Palm Pilot circa 1997 could achieve nearly 100% accuracy, but a phone that's nominally 62.5 times faster can barely tell the difference between 'C' and "O". Locking the Photon's CPU to 100% (the one thing Moto's kernel grudgingly permits) fixes the problem totally. At least, until the battery dies an hour or two later.
I wish Google would find a way to force anybody who wants to sell a phone with Android Market (oops, I mean "Google Play". God, I hate that name...) to include a CPU governor based on 'interactive'. What differentiates 'interactive' from 'ondemand' (the one, and often the only, governor in most stock kernels)? Interactive kicks the CPU up to 100% speed whenever you do something that indicates that you're interacting with the phone... when you've hit the power button to turn on the screen and wake up the phone, when you're touching the screen or pressing a button, etc. It also increases CPU speed rapidly in response to load, and backs off on speed VERY slowly. The goal of 'interactive' scheduling is that you should never be forced to wait for anything to happen just because the CPU is running at less than full speed. It allows it to slow down when the phone is genuinely inactive, but prioritizes snappiness and lag-free use over a few minutes of battery life.
In contrast, the stock 'ondemand' governor hesitates to increase speed, and slows down the phone at the first hint of an excuse. Ondemand governors are the reason why we have phones with laggy lockscreens and lurching homescreen animations. The truth is, 99% of the lag complaints people have with Android are the fault of the 'ondemand' governor and its derivatives. Governors based on 'interactive' provide a MUCH nicer user experience, with minimal impact on battery life (the phone can still slow down to 100-200MHz when you turn off the display, or when it's just sitting on your homescreen and you haven't touched it in 5 minutes). 'Ondemand' == "evil".
And the guys over at Xamarin proved that, it ran much MUCH faster.. http://blog.xamarin.com/2012/05/01/android-in-c-sharp/