Linaro Tweaks Speed Up Android, By Up To 100 Percent

← Back to Stories (view on slashdot.org)

Linaro Tweaks Speed Up Android, By Up To 100 Percent

Posted by timothy on Sunday June 10, 2012 @03:17AM from the mowing-the-other-guy's-lawn dept.

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."

97 comments

Min score:

Reason:

Sort:

So... by Anonymous Coward · 2012-06-10 03:20 · Score: 3, Funny

that's where the guys with long hair are!
DBZ reference by Linsaran · 2012-06-10 03:23 · Score: 3, Funny

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
Meaning stats by Qwavel · 2012-06-10 03:26 · Score: -1, Flamebait

That summary should win a prize for meaningless stats.
Telling us that "many tasks" are "between 30 and 100 percent faster" tells us nothing at all. And that is the meat of the summary!
1. Re:Meaning stats by negRo_slim · 2012-06-10 03:51 · Score: 5, Insightful
  
  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.
  
  --
  On the Oregon Cost born and raised, On the beach is where I spent most of my days
2. Re:Meaning stats by Sardak · 2012-06-10 03:53 · Score: 2
  
  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.
3. Re:Meaning stats by Anonymous Coward · 2012-06-10 04:10 · Score: 0
  
  Read....The....Fucking.....Article.....you....lazy....twat
  and look up the definition of the word "summary".
4. Re:Meaning stats by Anonymous Coward · 2012-06-10 06:02 · Score: 0
  
  The summary is a summary you lazy fuckerlord, just read the damn article instead of being a demanding asshat.
5. Re:Meaning stats by Anonymous Coward · 2012-06-10 06:16 · Score: 0
  
  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.
6. Re:Meaning stats by Pieroxy · 2012-06-10 06:41 · Score: 0
  
  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!
7. Re:Meaning stats by Anonymous Coward · 2012-06-10 08:57 · Score: 0
  
  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.
Better link by OzPeter · 2012-06-10 03:35 · Score: 5, Informative

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?
1. Re:Better link by ya+really · 2012-06-10 04:02 · Score: 5, Interesting
  
  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.
2. Re:Better link by complete+loony · 2012-06-10 04:08 · Score: 1
  
  30fps vs 60fps? The speed difference could actually be very minor. It could be simply that the google version just misses a screen refresh and waits for the next one, where the linaro version doesn't. Obviously there's no doubt that it is faster, but a single fps number doesn't give you all the details.
  
  --
  09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
3. Re:Better link by Flammon · 2012-06-10 04:17 · Score: 1
  
  No it's not. Look at the video. They run a benchmark that the Linaro version completes a few minutes before the stock version.
  
  --
  ayottesoftware.com
4. Re:Better link by Tenebrousedge · 2012-06-10 04:26 · Score: 3, Insightful
  
  The commentators on hacker news seem to be fewer in number and the focus and readership seems to be more about web technologies and startups. I could care less about your new jquery library for styling select boxes (or any reinventing-the-wheel-in-javascript project) and entrepreneurs are mostly failures waiting to happen.
  As far as I'm concerned Hacker News has a higher SNR.
  
  --
  Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
5. Re:Better link by ya+really · 2012-06-10 04:45 · Score: 1
  
  The commentators on hacker news seem to be fewer in number and the focus and readership seems to be more about web technologies and startups.
  
  I would be lying if I said that was not somewhat true. Hacker news is based around the startup community. However, they talk about lots of interesting technologies, some offtopic stuff and of course some startup bs. The comments are very insightful due to the experience of the commenters there. I generally look through the comments before I even open the article (if I actually open it). They also do a better job at keeping the trolls away I think than most sites. Just for example, the founders of Dropbox got their start on hacker news and still post there. There's a lot of creative and cool ideas talked about in general though on there that anyone that considers themselves a geek would like.
  I do get irked by some of the code snobbier that goes on there, but you get that anywhere at any time. I just ignore those kind of discussions like anyone that isn't looking for a battle does. However, no site is perfect and like slashdot, I consider it just one of a few sites worth reading over for tech news. Lots of the articles here tend to be mirrored in discussions there (though not quite so much on political things).
  
  As far as I'm concerned Hacker News has a higher SNR.
  As mentioned, it does have some stuff worth skipping over, but Slashdot tends to suffer from the SNR effect as well with some of the articles and the lack of concrete, insightful content in comments at times as well. I just read both and accept that every site has its faults.
6. Re:Better link by Gaygirlie · 2012-06-10 05:23 · Score: 5, Insightful
  
  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
7. Re:Better link by Stewie241 · 2012-06-10 05:59 · Score: 2
  
  I'm confused - you talk about readership being more about web technologies and startups with a tone that suggests that is a bad thing. You say you could care less about new jquery libraries. I guess I wonder how much less you could care. Then you talk about how entrepreneurs are mostly failures waiting to happen.
  Based on the overall tone of your article I got the sense that you looked upon Hacker News in a negative fashion. Yet, you finished the post by saying it had a higher signal to noise ratio, implying that it was actually better than Slashdot.
  I think some clarification is needed.
8. Re:Better link by Anonymous Coward · 2012-06-10 06:53 · Score: 0
  
  It just wouldn't be the /. comments section without someone whining about how /. used to be so much better x number of years ago.
9. Re:Better link by Anonymous Coward · 2012-06-10 08:52 · Score: 0
  
  "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 ..."
  But also great articles about nice tools like MyCleanPC.
10. Re:Better link by Tenebrousedge · 2012-06-10 08:53 · Score: 1
  
  Thank you for correcting my use of the term.
  
  --
  Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
11. Re:Better link by Anonymous Coward · 2012-06-10 09:08 · Score: 0
  
  I don't think I would hold HN up as the paragon of substance... to me, it seems like 90% of their articles is "hey, get yer eyeballs on my niche startup that'll never go anywhere or my naive blog post on some topic which I claim to be a 22 year-old hipster expert am really just spicing up a contrary opinion with some swear words"
12. Re:Better link by martin-boundary · 2012-06-10 13:12 · Score: 1
  
  Yeah, it all started going downhill when JonKatz left. He was a visionary and a supercoder, and I learned everything I know about computers from his articles.
13. Re:Better link by complete+loony · 2012-06-10 14:41 · Score: 2
  
  If this demo was waiting for a screen repaint before drawing the next frame (and since there's no flickering it's either doing that or triple buffering). Then if the cpu can paint the screen at 65fps, but your monitor can only do 60fps, then the demo will run at 60fps. However if the cpu can only paint at 55fps, then the demo will actually run at 30fps. eg each frame will be displayed by the monitor for 2 screen refreshes and the demo will take twice as long to run.
  That's the point I was trying to make. That if you are waiting for the monitor to paint each frame, a small difference in rendering speed can cause a large difference in fps.
  
  --
  09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
14. Re:Better link by Anonymous Coward · 2012-06-11 03:26 · Score: 0
  
  Yep the blobs that they reference are mainly the gpu drivers and some wifi drivers plus some of the Google proprietary apps.
  The drivers are up to whomever the soc mfg licensed the block from for their soc and most aren't GPLed and the OSS just aren't very good yet.
  Also most device makers release the bare minimum of source, i.e. the GPL bits.
battery life by drwho · 2012-06-10 03:50 · Score: 1

...and what does this do to the battery life? For me, that's more important than the performance of a video game.
1. Re:battery life by gbjbaanb · 2012-06-10 03:54 · Score: 4, Informative
  
  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.
2. Re:battery life by muon-catalyzed · 2012-06-10 03:54 · Score: 1
  
  Battery life will improve, tasks will get done faster, CPU can idle more.
3. Re:battery life by davydagger · 2012-06-10 04:34 · Score: 1
  
  forgot to mention than on most ARM based devices even more so, because when they are not working as hard they scale down their clocks enormously (like 1/3 - 1/4th max) and with it their power. The faster a task is completed, the less time a mobile CPU will spend at top speed, using full power.
4. Re:battery life by Bill+Barth · 2012-06-10 06:13 · Score: 3, Interesting
  
  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.
5. Re:battery life by spyked · 2012-06-10 06:19 · Score: 1
  
  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.
  Not necessarily. If the code you run results in usage of extra hardware, the cost of using that might result in a less efficient behaviour power-wise. What I'm saying is yes, Hurry Up and Get Idle is a good principle in theory, but it doesn't always work in practice because different instructions incur different power/time costs.
  So the problem might be a tad trickier, there's other measures to be taken into account, such as how that affects lock contention, caches and so on. I personally can't make any statements until I see actual power usage results and comparisons.
6. Re:battery life by amorsen · 2012-06-10 07:43 · Score: 5, Informative
  
  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?
next thing to do... by gbjbaanb · 2012-06-10 04:03 · Score: -1, Troll

is get rid of Java, then you'd see another 100% performance improvement, and it might not suck up all my RAM and pause occasionally.
1. Re:next thing to do... by ChrisMP1 · 2012-06-10 04:08 · Score: 0, Flamebait
  
  It's not 1997 anymore.
  
  --
  <sig> </sig>
2. Re:next thing to do... by jgfenix · 2012-06-10 04:19 · Score: 1
  
  But Dalvik is not as fast as modern JVM
3. Re:next thing to do... by Anonymous Coward · 2012-06-10 04:21 · Score: 0
  
  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.
4. Re:next thing to do... by ChrisMP1 · 2012-06-10 04:22 · Score: 0
  
  And my Mustang isn't as fast as a Ferrari. It's still rather decent.
  
  --
  <sig> </sig>
5. Re:next thing to do... by Anonymous Coward · 2012-06-10 04:35 · Score: 0
  
  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.
6. Re:next thing to do... by Anonymous Coward · 2012-06-10 04:38 · Score: 0
  
  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.
7. Re:next thing to do... by Anonymous Coward · 2012-06-10 04:38 · Score: 0
  
  If it were *less* java-centric, even.
8. Re:next thing to do... by citizenr · 2012-06-10 04:47 · Score: 0
  
  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.
9. Re:next thing to do... by ChrisMP1 · 2012-06-10 04:53 · Score: 0
  
  No, I suppose not. But... greater than 100ms? Really?
  
  --
  <sig> </sig>
10. Re:next thing to do... by Ash-Fox · 2012-06-10 05:07 · Score: 1
  
  You can have memory leaks already. Why are misrepresenting the current state?
  
  --
  Change is certain; progress is not obligatory.
11. Re:next thing to do... by Anonymous Coward · 2012-06-10 05:08 · Score: 0
  
  No, Java's even bigger and uglier than it was back in 1997..
12. Re:next thing to do... by Anonymous Coward · 2012-06-10 05:10 · Score: 5, Funny
  
  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.
13. Re:next thing to do... by Anonymous Coward · 2012-06-10 05:21 · Score: 0
  
  Whereas Dalvik is not as fast as modern Java, but both are still indecent.
14. Re:next thing to do... by Anonymous Coward · 2012-06-10 05:28 · Score: 0
  
  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.
15. Re:next thing to do... by MagusSlurpy · 2012-06-10 05:34 · Score: 1
  
  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.
16. Re:next thing to do... by Anonymous Coward · 2012-06-10 05:38 · Score: 1
  
  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.
17. Re:next thing to do... by TheRaven64 · 2012-06-10 07:22 · Score: 1
  
  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
18. Re:next thing to do... by SuricouRaven · 2012-06-10 10:59 · Score: 2
  
  .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.
19. Re:next thing to do... by citizenr · 2012-06-10 12:26 · Score: 0
  
  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.
20. Re:next thing to do... by Anonymous Coward · 2012-06-10 13:26 · Score: 0
  
  Whoooosh
21. Re:next thing to do... by citizenr · 2012-06-10 14:04 · Score: 1
  
  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.
22. Re:next thing to do... by wrook · 2012-06-10 15:30 · Score: 1
  
  .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.
23. Re:next thing to do... by Miamicanes · 2012-06-10 16:05 · Score: 2
  
  > 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".
24. Re:next thing to do... by Miamicanes · 2012-06-10 16:17 · Score: 1
  
  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.
25. Re:next thing to do... by marsu_k · 2012-06-10 18:35 · Score: 1
  
  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)
26. Re:next thing to do... by SuperDre · 2012-06-10 20:10 · Score: 2
  
  And the guys over at Xamarin proved that, it ran much MUCH faster.. http://blog.xamarin.com/2012/05/01/android-in-c-sharp/
27. Re:next thing to do... by Anonymous Coward · 2012-06-11 00:32 · Score: 1
  
  "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.
28. Re:next thing to do... by aaron552 · 2012-06-11 01:16 · Score: 1
  
  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.
29. Re:next thing to do... by badkarmadayaccount · 2012-06-13 03:49 · Score: 1
  
  Anyone tried linux-ck on a android?
  
  --
  I know tobacco is bad for you, so I smoke weed with crack.
100% faster, uhm no by RichMan · 2012-06-10 04:09 · Score: -1, Offtopic

Not even neutrino's are that fast.
100% faster would mean it takes ZERO time to do something.
The new code might be 50% faster than the old code. (Using old code as time reference).
At the same time the old code would be 100% slower than the new code (Using the new code as the time reference).
But there is no way the new code is 100% faster than the old code, as that requires 0 time for the new code.
This is not nitpicking, this is correctly expressing relative numbers. If things are not expressed correctly they meaningless and unusable.
1. Re:100% faster, uhm no by Anonymous Coward · 2012-06-10 04:21 · Score: 1
  
  100% faster means the original speed plus 100% of the original speed, which is to say, it's twice as fast.
2. Re:100% faster, uhm no by Spodi · 2012-06-10 04:22 · Score: 4, Informative
  
  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)).
3. Re:100% faster, uhm no by jgfenix · 2012-06-10 04:27 · Score: 1
  
  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.
4. Re:100% faster, uhm no by Immerman · 2012-06-10 04:31 · Score: 3, Informative
  
  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.
5. Re:100% faster, uhm no by Quartus486 · 2012-06-10 05:16 · Score: 1
  
  400%...
6. Re:100% faster, uhm no by Immerman · 2012-06-10 06:24 · Score: 1
  
  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.
7. Re:100% faster, uhm no by meerling · 2012-06-10 06:51 · Score: 1
  
  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.
Rebuilds for existing devices? by Barbarian · 2012-06-10 04:10 · Score: 3, Insightful

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...
1. Re:Rebuilds for existing devices? by oakgrove · 2012-06-10 04:43 · Score: 4, Informative
  
  As always, the ever resourceful TeamDouche and Cyanogenmod are on it.
  
  --
  The soylentnews experiment has been a dismal failure.
2. Re:Rebuilds for existing devices? by jeti · 2012-06-10 05:13 · Score: 2
  
  They claim to have cleaned up some code that prevented gcc optimizations from being used. If they check it in, builds with the standard toolchain can be improved as well.
3. Re:Rebuilds for existing devices? by Clarious · 2012-06-11 15:08 · Score: 1
  
  It seems that they use -O3 optimization in GCC, which is dangerous as it could lead to code running incorrectly, even gentoo recommend against it. I think it would be better if they optimize dalvik VM instead of changind build flag.
Misleading and/or overblown? by Calos · 2012-06-10 04:58 · Score: 1

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%
1. Re:Misleading and/or overblown? by Calos · 2012-06-10 05:00 · Score: 1
  
  Oh, and forgot to mention - they're comparing to an AOSP source. While it doesn't sound like the vendors are making all of the changes and optimizations these guys are, it still adds a few more unknowns and makes comparisons difficult. Not sure what the board they're demonstrating this on is actually intended for either.
  
  --
  I vote based on politicians' actions, unless contrary to my preconceptions. Often wrong, never uncertain. #iamthe99%
2. Re:Misleading and/or overblown? by Gaygirlie · 2012-06-10 05:31 · Score: 2
  
  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).
3. Re:Misleading and/or overblown? by Gaygirlie · 2012-06-10 05:32 · Score: 1
  
  Not sure what the board they're demonstrating this on is actually intended for either.
  http://pandaboard.org/
4. Re:Misleading and/or overblown? by Anonymous Coward · 2012-06-10 05:46 · Score: 0
  
  The use the same board for both. They use a visual benchmark because its what people actually want to see. Its more interesting to see shit moving on a screen than it is to spuriously see some number appear. People can relate to graphical workloads. They don't related well to some random benchmark which usually has no relation to any real world workload.
  They don't have source to the video driver. Its just a binary blob. As such, they have no means to readily optimize the video drivers. As such, as presented, their demo pretty clearly shows a 2x performance improvement with only some gray area. Given their claim of transparency and the fact their complete source is already available (was available before the demo), its no likely this is a smoke a mirror show.
  They are donating all of their toolchain and source improvements to ASOP which means they can all be verified by third parties. CyanogenMod is said to be all over these improvements.
'mby up to 100 percent.'m by Anonymous Coward · 2012-06-10 05:04 · Score: 0

So they've tweaked Android so that it will run at speeds slower than or equal to stanard Android. how exactly is this better?
1. Re:'mby up to 100 percent.'m by drkstr1 · 2012-06-10 09:48 · Score: 2
  
  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
2. Re:'mby up to 100 percent.'m by Beat+The+Odds · 2012-06-11 06:39 · Score: 1
  
  100% as fast would be 1.0x. They said 100% faster, which is (x + 1.0x)
  or x+x or 2x
  Is there some reason that you wanted to made this more complicated than it needs to be?
3. Re:'mby up to 100 percent.'m by drkstr1 · 2012-06-11 07:37 · Score: 1
  
  100% as fast would be 1.0x. They said 100% faster, which is (x + 1.0x)
  or x+x or 2x
  Is there some reason that you wanted to made this more complicated than it needs to be?
  I checked your math, and 1+1 does in fact equal 2. Clearly, my math skills need some work (or maybe I intentionally left it in that form to better represent the concept). Choose whichever answer floats your boat.
  
  --
  Fanboy Status: Apache Flex, C#, Eclipse, KDE, Pirate Party, Ron Paul, Slackware, Windows 7
Port to Mono by svick · 2012-06-10 05:07 · Score: 2

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.
1. Re:Port to Mono by fa2k · 2012-06-10 05:28 · Score: 1
  
  WTF!!:)
2. Re:Port to Mono by jgfenix · 2012-06-10 11:54 · Score: 1
  
  It would be more useful to replace the Android JIT with the Mono one.
3. Re:Port to Mono by Henk+Poley · 2012-06-10 22:58 · Score: 2
  
  Truth be told, that 7x speedup was only in a part where they rewrote their autogenerated C# code to use some special construct that only exists in C# but not in Dalvik/Java. On a micro benchmark of that particular part they got a 7x speedup.
  Basically they found a special case where the C# compiler knows a trick that Java doesn't do, then pointed out such a case exists in AOSP and tweaked that source code file.
4. Re:Port to Mono by svick · 2012-06-11 00:55 · Score: 1
  
  Yes, I realize that. But considering it was only a research project and not really a serious port, I think those are great results. And it shows there may be very interesting possibilities in something like this.
5. Re:Port to Mono by Anonymous Coward · 2012-06-11 04:00 · Score: 0
  
  special case where the C# compiler knows a trick that Java doesn't do
  While I agree with your sentiment, it's not a compiler trick, structs and generic reification are fundamental design differences in the JVM's and CLR's object/execution models. Their lack in the JVM is why I think the platform sucks. You can't really emulate them with a different compiler targeting java bytecode without running into problems and getting a very sub-optimal result at best.
benchmark on a framerate capped OpenGL test ? by stephanep · 2012-06-10 05:40 · Score: 2, Insightful

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 !
1. Re:benchmark on a framerate capped OpenGL test ? by zzyzyx · 2012-06-10 09:28 · Score: 1
  
  You're right on this, the Android renderer is double buffered and vsync'd so anything can only be displayed at the display framerate (60fps) or a sub-multiple. Maybe the difference was only from 59 to 60fps. However even if this particular figure is dubious, that's not the only thing they changed, and there is real improvement.
NEWS by wzzzzrd · 2012-06-10 05:47 · Score: 0

This just in: hardware tailored OS faster than generic OS.

--
On second thought, let's not go to Camelot. It is a silly place.
1. Re:NEWS by Gaygirlie · 2012-06-10 06:03 · Score: 2
  
  You might wish to practice on your reading-comprehension skills: none of the things Linaro devs did are Pandaboard-specific.
The info you quote isn't in the article. by Anonymous Coward · 2012-06-10 07:30 · Score: 0

I just read the linked article. It doesn't have the information that you quoted? Where did you get it?
Governors are by definition laggy. by Anonymous Coward · 2012-06-10 19:12 · Score: 1

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.
Profesional hosting image by Anonymous Coward · 2012-06-11 02:31 · Score: 0

Free Image Upload
http://picupload.pl
End the Dell Blacklist Against Linux NOW... by PaulGrins · 2012-06-12 07:30 · Score: -1, Flamebait

If you feel passionately about Linux support this petition to get Dell to stop the blockade and blacklisting of Linux and to stop forcing customers to buy Windows 7 and Microsoft Office if they want the latest Dell hardware. Make a difference and tell them to stop now....They have setup a petition website for the posting of new ideas and comments called Ideastorm, lets up-vote the issue and support the breaking of the Microsoft Cartel at Dell...

"Pre-Installed Linux | Ubuntu | Fedora | OpenSUSE | Multi-Boot" Link: http://www.ideastorm.com/idea2ReadIdea?id=0877000000006ixAAA&v=1339437474096 [ideastorm.com]

"Give the user a choice of Ubuntu/Fedora/RHEL or Windows on all desktops..." Link: http://www.ideastorm.com/idea2ReadIdea?Id=087700000008iglAAA&v=1339424370822 [ideastorm.com]

Please support this effort...