On Thu, Aug 04, 2011 at 12:03:00PM -0700, Taras Glek wrote:
Recently we have been looking at how to squeeze more performance out of our toolchain for building Firefox on Android. Mike Hommey integrated GCC 4.6 into the android NDK and has been testing performance (with mixed results http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html).
You should definitely be trying to build using the Linaro 4.5 and 4.6 compiler branches; they are pretty much guaranteed to give you better performance, and if they don't, we're on the hook to fix it quickly! All the patches go upstream, so there is no risk of you being stuck on a fork -- it just makes everything you need available right now.
I'm copying the linaro-toolchain list to make sure that you get the right people's attention (though if they weren't all coming back from Connect in Cambridge this week they would have picked the email up already).
I like how Linaro is doing regular arm benchmarking, ie https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-0...
We do much more than that, but it's not as easy to find right now; for instance http://ex.seabright.co.nz/helpers/benchcompare is Michael's regular release benchmark.
. Would you be interested in adding a Firefox-based benchmark? As a large application it is a good testbed for LTO, FDO and other aggressive optimizations.
Totally. Let's do it. Can you give me an idea of what boards you are testing the build on today? Do you have a test suite that we could run in a reasonable timeframe (hours, not days)?
We are also looking at setting a developer-friendly android ROM with oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be beneficial for us to use newer kernels as we exlore options like kernel-assisted ld.so relocations, etc. That seems to similar to what Linaro provides in the evaluation ROMS. Is there any chance of Linaro providing developer-friendly "evaluation" ROMs for retail phones like the Nexus S?
It's indeed pretty similar (we just call them LEBs), and Zach will be really interested in working with you on this.
As for supporting actual released phones, it lies somewhat outside of our optimal operating model, and we don't have any hardware available. I guess we could do a spin for a specific model if we had enough of them to use by a set of engineers in the different teams. They are so expensive, though. Do you guys have lots of them?
On 08/09/2011 02:47 PM, Christian Robottom Reis wrote:
On Thu, Aug 04, 2011 at 12:03:00PM -0700, Taras Glek wrote:
Recently we have been looking at how to squeeze more performance out of our toolchain for building Firefox on Android. Mike Hommey integrated GCC 4.6 into the android NDK and has been testing performance (with mixed results http://gcc.gnu.org/ml/gcc/2011-08/msg00096.html).
You should definitely be trying to build using the Linaro 4.5 and 4.6 compiler branches; they are pretty much guaranteed to give you better performance, and if they don't, we're on the hook to fix it quickly! All the patches go upstream, so there is no risk of you being stuck on a fork -- it just makes everything you need available right now.
Mike, can you give these a try?
I'm copying the linaro-toolchain list to make sure that you get the right people's attention (though if they weren't all coming back from Connect in Cambridge this week they would have picked the email up already).
I like how Linaro is doing regular arm benchmarking, ie https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-0...
We do much more than that, but it's not as easy to find right now; for instance http://ex.seabright.co.nz/helpers/benchcompare is Michael's regular release benchmark.
Link gives me an error page
. Would you be interested in adding a Firefox-based benchmark? As a large application it is a good testbed for LTO, FDO and other aggressive optimizations.
Totally. Let's do it. Can you give me an idea of what boards you are testing the build on today? Do you have a test suite that we could run in a reasonable timeframe (hours, not days)?
We have various benchmarks, all of which run within 30-60min.
We are also looking at setting a developer-friendly android ROM with oprofile, perf, systemtap, gdb, debug symbols, etc. It might even be beneficial for us to use newer kernels as we exlore options like kernel-assisted ld.so relocations, etc. That seems to similar to what Linaro provides in the evaluation ROMS. Is there any chance of Linaro providing developer-friendly "evaluation" ROMs for retail phones like the Nexus S?
It's indeed pretty similar (we just call them LEBs), and Zach will be really interested in working with you on this.
As for supporting actual released phones, it lies somewhat outside of our optimal operating model, and we don't have any hardware available. I guess we could do a spin for a specific model if we had enough of them to use by a set of engineers in the different teams. They are so expensive, though. Do you guys have lots of them?
How many devices would you need?
We actually have two separate needs. We use developer boards for continuous integration and phones for development. We need a good quality rom for both. Perhaps we can switch our boards over to pandaboards.
Is there someone I can call(and what time) to discuss this further?
Taras
On Tue, Aug 09, 2011 at 03:08:53PM -0700, Taras Glek wrote:
You should definitely be trying to build using the Linaro 4.5 and 4.6 compiler branches; they are pretty much guaranteed to give you better performance, and if they don't, we're on the hook to fix it quickly! All the patches go upstream, so there is no risk of you being stuck on a fork -- it just makes everything you need available right now.
Mike, can you give these a try?
Also, the 4.5 branch is likely to perform better for a while; once 4.6 has caught up 4.5 goes into stable mode.
If you are on a platform with NEON (i.e. not a Tegra2) experimenting with on -O3 and -mfpu=neon might get some interesting results as that enables the NEON auto-vectorizing Ira has been working on; given it's Mozilla, you might also get an ICE though ;-) Tell us how it goes.
I'm copying the linaro-toolchain list to make sure that you get the right people's attention (though if they weren't all coming back from Connect in Cambridge this week they would have picked the email up already).
I like how Linaro is doing regular arm benchmarking, ie https://wiki.linaro.org/Platform/Android/AndroidToolchainBenchmarking/2011-0...
We do much more than that, but it's not as easy to find right now; for instance http://ex.seabright.co.nz/helpers/benchcompare is Michael's regular release benchmark.
Link gives me an error page
It so happens the owner of the page is on vacation this week. I'll make sure he fixes it and points you to a running URL when it's done.
Totally. Let's do it. Can you give me an idea of what boards you are testing the build on today? Do you have a test suite that we could run in a reasonable timeframe (hours, not days)?
We have various benchmarks, all of which run within 30-60min.
Cool. Can you share a subset you'd like to see run as a starting point?
As for supporting actual released phones, it lies somewhat outside of our optimal operating model, and we don't have any hardware available. I guess we could do a spin for a specific model if we had enough of them to use by a set of engineers in the different teams. They are so expensive, though. Do you guys have lots of them?
How many devices would you need?
5 phones would give me confidence that we're not going to be stuck throughout the process of getting a build going. So that's the general order of magnitude.
We actually have two separate needs. We use developer boards for continuous integration and phones for development. We need a good quality rom for both. Perhaps we can switch our boards over to pandaboards.
Is there someone I can call(and what time) to discuss this further?
You can call me at +44 7595 200905 any time this week; now isn't a bad time, but if I do miss your call I'll be sure to ring you back. You can also call Zach on Thursday or Friday; I'll send his number separately.
On Tue, Aug 09, 2011 at 07:32:51PM -0300, Christian Robottom Reis wrote:
On Tue, Aug 09, 2011 at 03:08:53PM -0700, Taras Glek wrote:
You should definitely be trying to build using the Linaro 4.5 and 4.6 compiler branches; they are pretty much guaranteed to give you better performance, and if they don't, we're on the hook to fix it quickly! All the patches go upstream, so there is no risk of you being stuck on a fork -- it just makes everything you need available right now.
Mike, can you give these a try?
Also, the 4.5 branch is likely to perform better for a while; once 4.6 has caught up 4.5 goes into stable mode.
If you are on a platform with NEON (i.e. not a Tegra2) experimenting with on -O3 and -mfpu=neon might get some interesting results as that enables the NEON auto-vectorizing Ira has been working on; given it's Mozilla, you might also get an ICE though ;-) Tell us how it goes.
That's unfortunately not something that can work for us, except if we start distributing a different android build for NEON and non-NEON.
Mike
Mike Hommey wrote:
On Tue, Aug 09, 2011 at 07:32:51PM -0300, Christian Robottom Reis wrote:
On Tue, Aug 09, 2011 at 03:08:53PM -0700, Taras Glek wrote:
You should definitely be trying to build using the Linaro 4.5 and 4.6 compiler branches; they are pretty much guaranteed to give you better performance, and if they don't, we're on the hook to fix it quickly! All the patches go upstream, so there is no risk of you being stuck on a fork -- it just makes everything you need available right now.
Mike, can you give these a try?
Also, the 4.5 branch is likely to perform better for a while; once 4.6 has caught up 4.5 goes into stable mode.
If you are on a platform with NEON (i.e. not a Tegra2) experimenting with on -O3 and -mfpu=neon might get some interesting results as that enables the NEON auto-vectorizing Ira has been working on; given it's Mozilla, you might also get an ICE though ;-) Tell us how it goes.
That's unfortunately not something that can work for us, except if we start distributing a different android build for NEON and non-NEON.
you should consider that. Otherwise you will penalize future devices that will all have neon by forcing Tegra2 "legacy" support onto them.
linaro-toolchain@lists.linaro.org
-
Christian Robottom Reis -
Mike Hommey -
Taras Glek -
Vladimir Pantelic