Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Android Linux

Linaro Tweaks Speed Up Android, By Up To 100 Percent 97

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

Linaro Tweaks Speed Up Android, By Up To 100 Percent More

Linaro Tweaks Speed Up Android, By Up To 100 Percent

Comments Filter:

  • So... (Score:3, Funny)

    by Anonymous Coward on Sunday June 10, 2012 @10:20AM (#40274777)

    that's where the guys with long hair are!

  • DBZ reference (Score:4, Funny)

    by Linsaran ( 728833 ) on Sunday June 10, 2012 @10:23AM (#40274803) Homepage
    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.

  • Better link (Score:5, Informative)

    by OzPeter ( 195038 ) on Sunday June 10, 2012 @10:35AM (#40274881)

    After digging through the TFA I found Linaro Android Puts Stock Android To Shame on TI Pandaboard (OMAP4430) [cnx-software.com]. Which after digging in the comments leads to www.linaro.org/ [linaro.org]
     
    But the meat of the whole report is contained in this comment from Bernhard Rosenkraenzer [cnx-software.com] 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 (Score:5, Interesting)

      by ya really ( 1257084 ) on Sunday June 10, 2012 @11:02AM (#40275055)

      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 [ycombinator.com]

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

      • Re:Better link (Score:4, Insightful)

        by Tenebrousedge ( 1226584 ) <tenebrousedge@gmail. c o m> on Sunday June 10, 2012 @11:26AM (#40275215)

        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.

        • 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

        • 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, impl

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

      • Re: (Score:2)

        by Flammon ( 4726 )

        No it's not. Look at the video. They run a benchmark that the Linaro version completes a few minutes before the stock version.

        • 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. T

      • Comment removed (Score:5, Insightful)

        by account_deleted ( 4530225 ) on Sunday June 10, 2012 @12:23PM (#40275721)
        Comment removed based on user account deletion

  • ...and what does this do to the battery life? For me, that's more important than the performance of a video game.

    • Re:battery life (Score:5, Informative)

      by gbjbaanb ( 229885 ) on Sunday June 10, 2012 @10:54AM (#40275011)

      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.

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

      • Re:battery life (Score:4, Interesting)

        by Bill Barth ( 49178 ) <bbarth.gmail@com> on Sunday June 10, 2012 @01:13PM (#40276185)
        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.

        • Re:battery life (Score:5, Informative)

          by amorsen ( 7485 ) <benny+slashdot@amorsen.dk> on Sunday June 10, 2012 @02:43PM (#40276999)

          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.

      • Re: (Score:1)

        by spyked ( 1878060 )

        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 stat

    • Battery life will improve, tasks will get done faster, CPU can idle more.

  • Rebuilds for existing devices? (Score:4, Insightful)

    by Barbarian ( 9467 ) on Sunday June 10, 2012 @11:10AM (#40275105)

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

  • 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

    • Re: (Score:2)

      by Calos ( 2281322 )

      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.

    • Comment removed based on user account deletion

  • Port to Mono (Score:3)

    by svick ( 1158077 ) on Sunday June 10, 2012 @12:07PM (#40275567)

    There's also another interesting research project: Porting Android to C# running under mono [xamarin.com].

    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.

    • Re: (Score:2)

      by fa2k ( 881632 )
      WTF!!:)
    • It would be more useful to replace the Android JIT with the Mono one.

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

      • Re: (Score:2)

        by svick ( 1158077 )

        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.

  • 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 !

    • Re: (Score:1)

      by zzyzyx ( 1382375 )

      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.

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

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close