[cairo] Pixman ARM Performance

Jacob Bramley Jacob.Bramley at arm.com
Fri Jul 24 09:15:03 PDT 2009


Hello Chris and Soeren,

> If you actually mean 0.15.2, then I am not aware of anything that
> would cause slowdowns for ARM or other CPUs. In fact, between those
> two releases Jeff added support for a couple of ARM v6 SIMD fast
> paths.

Yep, I mean 0.15.2, as that appeared to be a release shortly before the
refactoring work started and I initially suspected that the refactoring
had caused the slow-down. I have also tried the latest tip, which is
labelled "0.15.19", and I get similar results here, so the refactoring
does not appear to be the problem.

I should also point out that I'm not entirely sure if I'm building it
properly. Adding "--disable-debug" to the configure command sped things
up considerably for some reason, though I couldn't find mention of that
anywhere in "configure --help". There could well be other switches that
I should apply. I'm currently using something like this:

CFLAGS="-mcpu=cortex-a8 -mfloat-abi=softfp" ../trunk/configure
--(dis|en)able-arm-neon --(dis|en)able-arm-simd --disable-debug
--prefix=`pwd`/inst.<build_tag>

Interestingly, building this natively on another board causes configure
to complain that "--disable-debug" isn't recognized, though it certainly
makes a difference when I cross-compile.

As a side note, I found that the existing Neon switch in the
configuration file is incorrect. If Neon is detected, it sets
"-mcpu=cortex-a8 -mfpu=neon". Neon is available on all ARMv7 cores, not
just Cortex-A8, so the first flag doesn't make much sense. In addition,
it is necessary (for some reason) to set "-mfloat-abi=softfp" to get GCC
to understand "-mfpu=neon". I configured and built the project by
specifying this in the CFLAGS environment variable.

> If you mean 0.15.12, then I would not be too surprised if there are a
> couple of performance regressions. Some have been fixed in 0.15.18;
> there are a couple of remaining ones on the map for 0.16.0.
> 
> As Chris said, if you can post the output of cairo-perf-diff for the
> versions in question, that would be helpful. If there are large
> performance regressions compared to 0.12.0, we'll want to look at that
> before 0.16.0.

I cannot trivially run cairo-perf-diff-files. It's possible that I'm
just not using the tool properly. If I run it on my build machine, it
complains because it can't find some Scratchbox* file. If I run it
inside Scratchbox, it can't see libcairo. Running it on-target works
better, but then dumps junk on my terminal until I kill it.

Is there a knack to using these tools that I'm missing? I assumed that
cairo-perf-diff-files would just be a log parsing tool and so shouldn't
have these dependencies, but maybe not.

* In case you or others aren't familiar with it, Scratchbox is a
cross-compilation environment that allows traditional configure-based
projects to be cross-compiled whilst fooling their configuration scripts
into thinking that they're being built natively.

>> I can provide the actual benchmark results if they'll be useful. I 
>> haven't provided them here because there are a lot of numbers!
> 
> Please do post them, or put them up somewhere and post a link.

Output from cairo-perf is attached*. Note that these benchmarks weren't
run very scientifically as I was only using them to investigate the
code, and I didn't keep logs of the exact configuration that I used for
each one. I'm re-running them all to rule out any weirdness, but these
will suffice for the time being.

* Nope, it's not, because it's too big for the list. I'll leave it here
for a week or so:
http://jacob.bramley.me.uk/pixman/20090724T1653.compare.0-12-0.0-15-2.0-15-19.tar.gz

Thanks,
Jacob




More information about the cairo mailing list