Linaro Tweaks Speed Up Android, By Up To 100 Percent 97
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."
So... (Score:3, Funny)
that's where the guys with long hair are!
DBZ reference (Score:4, Funny)
Re:Meaning stats (Score:5, Insightful)
... 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: (Score:1)
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.
Re: (Score:2)
Better link (Score:5, Informative)
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)
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)
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.
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
Thank you for correcting my use of the term.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
No it's not. Look at the video. They run a benchmark that the Linaro version completes a few minutes before the stock version.
Re: (Score:3)
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)
battery life (Score:2)
...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)
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.
Re: (Score:1)
Re:battery life (Score:4, Interesting)
Re:battery life (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.
Re: (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 stat
Re: (Score:2)
Re: (Score:1, Flamebait)
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
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.
Re: (Score:1)
Re: (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.
Re: (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.
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 [youtube.com]
http://www.youtube.com/watch?v=bc_RAsoVIFk [youtube.com]
http://www.youtube.com/watch?v=iPfK_EkBCjs [youtube.com]
http://www.youtube.com/watch?v=mzXRyFQM3Ts [youtube.com]
Apparently Samsung, HTC and others just bootleg Android. W
Re: (Score:2)
Re: (Score:1)
Re: (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.
Re: (Score:2)
Re: (Score:2)
http://www.youtube.com/watch?v=szOje7dcRlo [youtube.com]
http://www.youtube.com/watch?v=bc_RAsoVIFk [youtube.com]
http://www.youtube.com/watch?v=iPfK_EkBCjs [youtube.com]
http://www.youtube.com/watch?v=mzXRyFQM3Ts [youtube.com]
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)
Re: (Score:3)
> 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 s
Governors are by definition laggy. (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, t
Re: (Score:1)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
Re:next thing to do... (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.
Re: (Score:3)
Re: (Score:2)
.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 Studi
Re: (Score:2)
Re: (Score:1)
100% faster means the original speed plus 100% of the original speed, which is to say, it's twice as fast.
Re:100% faster, uhm no (Score:4, Informative)
Re: (Score:1)
Re:100% faster, uhm no (Score:4, 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)
Re: (Score:1)
Re: (Score:2)
300% faster = 100%+300% = 4x the speed
Otherwise 50% faster would mean half the speed.
Re: (Score:2)
Rebuilds for existing devices? (Score:4, 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...
Re:Rebuilds for existing devices? (Score:5, Informative)
Re: (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.
Re: (Score:2)
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? (Score:2)
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)
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.
Re: (Score:2)
Re: (Score:3)
Re: (Score:3)
Re: (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?
Re: (Score:2)
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.
Port to Mono (Score:3)
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)
Re: (Score:1)
Re: (Score:3)
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)
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.
benchmark on a framerate capped OpenGL test ? (Score:2, Insightful)
Re: (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 (Score:1)
Re: (Score:3)