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 what does this do to the battery life? For me, that's more important than the performance of a video game.
... 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's not 1997 anymore.
<sig> </sig>
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...
Read....The....Fucking.....Article.....you....lazy....twat
and look up the definition of the word "summary".
But Dalvik is not as fast as modern JVM
Yes, then it will have memory leaks and crash more frequently instead :-).
But your point is something I've often agreed with; interpretive run-time environments with big foot prints don't make a great deal of sense on small low power devices.
My approach would have been to have app stores to store programs compiled to an intermediate code which would then be translated to machine code for a particular platform when it was downloaded.
100% faster means the original speed plus 100% of the original speed, which is to say, it's twice as fast.
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)).
And my Mustang isn't as fast as a Ferrari. It's still rather decent.
<sig> </sig>
You are wrong %Increase in velocity=100x(New velocity-Old velocity)/Old velocity So if new code is 60 fps and old is 30 fps that is a 100% faster. Same with other definitions of velocity.
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.
God I'd give anything for something to force Google to drop the horrible java crap from Android. They might get half decent developers if it were java-centric. All they've achieved so far is to recreate all the ugliness of previous mobile platforms on top of a linux kernel. Yuk.
Java's affect on RAM is horrible. If you set its limit too low, you risk crashing your programs with out of memory errors. If you set it too high, you waste RAM because it's going to grow to use everything you throw at it, and for the love of all that is holy, don't let it use virtual memory; the garbage collector will happily make sure the entire address space is always being accessed and bring your computer to a crawl with constant paging.
If it were *less* java-centric, even.
And my Mustang isn't as fast as a Ferrari. It's still rather decent.
Does your Mustang manage frame drops on home screen on dual core 1GHz SoC? >100ms audio lag? >100ms input lag? Android does.
Who logs in to gdm? Not I, said the duck.
No, I suppose not. But... greater than 100ms? Really?
<sig> </sig>
So... they're demonstrating these gains, running a graphical benchmark, which they state is largely CPU bound, and their build has no improvements to the GPU code. Why choose that benchmark? The results are about as clear as mud for me. Why choose a graphical benchmark to test the CPU? Is it running the graphics on the CPU instead of the GPU? Android 4 is designed to offload all UI elements to the GPU, so it's not shocking to me that the code is not optimized for a graphical benchmark. I didn't look at the whole video because it was honestly a little painful, and I'm not a software developer, but the video and TFA mention code fixes relating to an compile flag related to aliasing. Which just makes it sound more and more like they're optimizing graphics operations for the part of the device which is not intended to do those operations in normal use.
Apparently there's some benefit, as the CyanogenMod team is supposedly implementing some of the changes. That's a good sign. Maybe they're actually fixing/optimizing how the systems interact? But there's still no information about what is actually faster and if it matters.
I vote based on politicians' actions, unless contrary to my preconceptions. Often wrong, never uncertain. #iamthe99%
So they've tweaked Android so that it will run at speeds slower than or equal to stanard Android. how exactly is this better?
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.
You can have memory leaks already. Why are misrepresenting the current state?
Change is certain; progress is not obligatory.
No, Java's even bigger and uglier than it was back in 1997..
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.
400%...
Whereas Dalvik is not as fast as modern Java, but both are still indecent.
I think the GP is getting at the quality of the applications. It's generally improved over the years so the common applications I use no longer force close. Not all applications have though, and to me a force close is an indication that the application isn't written well or by a developer that knows what they are doing well enough. By removing some of the nice fluffy sand boxed security that the VM provides then application developers mistakes and naivety will become more obvious. It is already documented that even good common applications are misusing resources and using more power than they need, for example holding open network connections after transmission of data. Saying that, the idea the GP has is good one especially if they keep some of the fluff like using a native garbage collector with some kind of hook into the runtime.
How do you keep it from using virtual memory? It drives me fucking nuts on my HTPC.
Well, besides uninstalling, which I am about to do.
My sister opened a computer store in Hawaii. She sells C shells by the seashore.
Specs vary from device to device, but 100ms won't get you certified on any modern Android device. Modern Android devices meet or beat what Apple is providing and has done so for at least one generation.
You can safely chock up his post as troll at worst or ignorant at best.
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 !
This just in: hardware tailored OS faster than generic OS.
On second thought, let's not go to Camelot. It is a silly place.
The summary is a summary you lazy fuckerlord, just read the damn article instead of being a demanding asshat.
If you can't legitimately complain about a summary please keep to yourself. All you're doing is adding noise to posts that have legitimate complaints. It's a summary it's not supposed to give you the breakdown.
300% faster = 100%+300% = 4x the speed
Otherwise 50% faster would mean half the speed.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
I'm sure everyone agrees that there are more details in the articles than in the summaries. The OP claims that there could be some information in the summaries. I'm sure we all agree there as well.
This one is beyond pathetic.
Write boring code, not shiny code!
300% is correct because he's specifying "faster" than, which means that first 100% is not part of the result since that is not 'faster', it is in fact the base value.
That's the second claim of that level of lag I've seen, and I wonder what hardware you're seeing that on. My phone is a cheap two-year-old model, yet seems to be pretty smooth for anything I use it for. I'd definitely notice 100ms input lag, and probably notice 100ms audio lag. Android makes a lot of UI mistakes, but I've not seen the kind of lag you describe. The only time I've seen something even close to that was when I played with a Galaxy Tab in a shop, and then some of the full-screen animations looked like they were done entirely in software, but that wasn't input lag, it was 'just' dropping frames in animations.
I am TheRaven on Soylent News
I just read the linked article. It doesn't have the information that you quoted? Where did you get it?
No, I disagree. There was plenty of details for a summary. I want the summary to give me enough information to see if I'm interested in the article.
.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.
Specs vary from device to device, but 100ms won't get you certified on any modern Android device. Modern Android devices meet or beat what Apple is providing and has done so for at least one generation.
You can safely chock up his post as troll at worst or ignorant at best.
Certified? lol
Clearly this is why we have all those music trackers on Android ... oh wait, we dont because they are impossible to implement with those input/sound API delays. Android Audioserver, audioslinger has ~200ms lag out of the box, on EVERY SINGLE DEVICE ON THE MARKET.
http://www.youtube.com/watch?v=szOje7dcRlo
http://www.youtube.com/watch?v=bc_RAsoVIFk
http://www.youtube.com/watch?v=iPfK_EkBCjs
http://www.youtube.com/watch?v=mzXRyFQM3Ts
Apparently Samsung, HTC and others just bootleg Android. Wait, why am I talking to an anonymous Fanboi?
Who logs in to gdm? Not I, said the duck.
Whoooosh
http://www.youtube.com/watch?v=szOje7dcRlo
http://www.youtube.com/watch?v=bc_RAsoVIFk
http://www.youtube.com/watch?v=iPfK_EkBCjs
http://www.youtube.com/watch?v=mzXRyFQM3Ts
You wont notice it because
-human brain adapts, people dont notice how shitty Console gaming is, >50ms input lag, >50ms Video lag introduced by TV postprocessing. People even tolerate OnLive lag.
-its so bad certain types of apps are just not being made for Android (anything that makes lag obvious, like audio trackers)
Who logs in to gdm? Not I, said the duck.
.Net is not my programming platform of choice, but I've actually implemented a SIP softphone for Windows Mobile in .Net (We're talking something like 7 years ago). I had no performance problems at all. I was careful with memory (memory pools, etc), but in terms of writing embedded code, I did nothing out of the ordinary. At the time .Net was not well supported on Windows Mobile (and maybe never got supported, for all I know -- after the project I've never used it again). I had problems with Visual Studio and Windows Mobile itself (a crappier embedded OS, I have never seen before...), but .Net was never a problem for me. I even made a mono port for Linux so that I could work using that platform (my preferred development platform).
People are too religious when it comes to development platforms. Unless you've worked extensively with it, it's actually pretty difficult to tell how good or bad it's going to be. Your experience running Hello, World in a desktop environment is really not related to working on an embedded device. Java suffers from the same misconceptions. Everything depends on the run time code.
If someone were to pay me, I would happily work with .Net again. I've worked with far more difficult systems.
> 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".
Java's garbage collection is actually pretty good, and has been for the past 5-7 years (ever since 1.4 or 1.5). Recent versions of Java will let you get away with astonishingly promiscuous levels of short-lived object creation and destruction. If you try that with Android, your application will hang and freeze every 20-30 seconds.
Dalvik, in contrast, does not handle promiscuous creation of short-lived objects well AT ALL. I don't know whether it's because of compromises Google had to make to program around Sun's patents, or just because they never bothered to optimize garbage collection the way Sun did sometime around 2005, but Dalvik's garbage collection just plain sucks, and feels like Java's did way back around 2000. When the Android SDK tells you to re-use objects whenever possible and avoid needless creation and destruction of objects, it *really* means it.
Funny that, while using Caustic on my TF101 the latency is about 90ms. Which, while not ideal, is acceptable for what it is. (having said that though, I wish Google would work more on the latency, Linux + JACK can achieve sub-10ms latency on commodity hardware)
All governors add lag to frequency selection since they monitor CPU load on their own timescale and make decisions independently of anything else. CPUFreq is nicely organised and the separation makes it much simpler, but while it retains the same design it will never be able to increase CPU frequency without adding lag to those decisions.
That said, the main difference with the Interactive Governor is that it starts a 30ms timer when a CPU becomes busy. If the CPU is still busy when the 30ms has completed, then the move to max speed happens immediately. In all other situations, it works just like ondemand does. OnDemand works on a slower timescale and requires more compute load to move to top speed since the periodic monitoring is slower. Some SoCs also take quite a long time to stabilise the voltage when you go from lowest operating point to max operating point which will be the largest voltage swing.
If more SoCs had great idle support (both software and hardware - it's not always possible to go lower than WFI in a reasonable amount of time and sometimes drivers are not complete) then the performance governor would not have as much impact on battery life. Things are getting better, but the very poor idle support on the initial Android devices was IMO the reason why Wakelocks and Suspend was so necessary.
Also, scheduler-lead frequency changes can remove almost all of the latency but they cannot be implemented without patching the scheduler and coupling the two subsystems more closely. After all, the scheduler has a pretty good idea how many tasks are ready to run and can also track their historic load profiles. There's a lot of talk at the moment about power-aware scheduling, and better integration of idle, load balancing and frequency selection will be part of the solution.
And the guys over at Xamarin proved that, it ran much MUCH faster.. http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
"Trackers" are step-sequencers. You could have latency in the tens of seconds and they'd still work OK.
The latency on Android is definitely a problem for music applications, but should only be a show-stopper when dealing with real-time effects or soft-synths triggered by real-time input. It's completely possible to do multi-track recording in a high-latency environment. I was able to manage four tracks on a 486SX25 with a SoundBlaster AWE 32 - you can't tell me that setup had sub 10ms latency.
You used to need a kernel with a realtime patch to get that, not ure if you still do. Even so, I believe the audio lag is caused by there not being any real time audio APIs available in Android. Something like JACK (which is itself just a layer over ALSA, I believe) may not port particularly well to android, I haven't really looked into it. Also, using a JIT and GC add additional unpredictable delays to execution, which make it harder to get right, too.
I had a sig once. It was lost in the great storm of '09.
Free Image Upload
http://picupload.pl
Anyone tried linux-ck on a android?
I know tobacco is bad for you, so I smoke weed with crack.