[fedora-arm] Fedora 20 for Raspberry Pi????

[Gordan Bobic]

On 01/01/2014 09:09 PM, Richard W.M. Jones wrote:
> On Wed, Jan 01, 2014 at 12:21:30PM -0800, Sean Omalley wrote:
>> They are a problem. It is a performance issue at the very least on
>> =ALL= platforms. There is a cost even on Intel's platform for
>> alignment errors, they just fix them up in hardware so it isn't as
>> big of a performance hit. It might be 5 cycles instead of 20.
>
> On Intel Sandybridge and up there is no penalty:
>
> http://www.agner.org/optimize/blog/read.php?i=142&v=t
>
> On earlier Intel processors it's not significant:
>
> http://lemire.me/blog/archives/2012/05/31/data-alignment-for-speed-myth-or-reality/

On ARM without hardware fixup it's huge. Using the test in the second 
link on Kirkwood (which is much more advanced and faster than standard 
armv5tel, thanks to Intel's improvements before they sold the division 
to Marvell), the results are:

# ./test

  processing word of size 4
offset = 0
  average time for offset 0 is 207.45
offset = 1
  average time for offset 1 is 7511.55
offset = 2
  average time for offset 2 is 7511.35
offset = 3
  average time for offset 3 is 7511.55

  processing word of size 8
offset = 0
  average time for offset 0 is 414.8
offset = 1
  average time for offset 1 is 12340.2
offset = 2
  average time for offset 2 is 12338.5
offset = 3
  average time for offset 3 is 12343.8
offset = 4
  average time for offset 4 is 414.2
offset = 5
  average time for offset 5 is 12337.5
offset = 6
  average time for offset 6 is 12339.9
offset = 7
  average time for offset 7 is 12337.4

That's a 36x and 29x slowdown with:
echo 2 > /proc/cpu/alignment

If you use 3 (fixup+warn) it gets an order of magnitude worse because 
syslog eats all the CPU logging the warnings.

I suspect the numbers on the Pi would be similarly bad, but I don't have 
one so can't test that. I'll get some numbers for an ARMv7 machine later.

> Anyway, you are optimizing far too early.

It is better to optimize too early than it is to pre-emptively code in 
blissful ignorance of what goes on underneath.

> If there's a performance
> problem, run 'perf', find out that it's caused by X where X might be
> the big misalignment penalty on ARM or many other things, then fix
> that.
>
> There's no need to go on a huge crusade to fix every last mis-
> alignment, because that will involve vast hours of programmer effort
> for no measurable gain.

Maybe so, but that doesn't mean that past errors should be considered as 
a precedent and all code henceforth should also be written without any 
alignment consideration, especially considering it has the potential to 
be dangerous (e.g. on hardware without alignment auto-fix up with 
kernels that don't default to auto-fixing alignment).

Gordan