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

[Gordan Bobic]

On 12/30/2013 10:08 AM, Steve Underwood wrote:
> On 12/28/2013 12:27 AM, Gordan Bobic wrote:
>> On 12/27/2013 04:02 PM, Richard W.M. Jones wrote:
>>> On Fri, Dec 27, 2013 at 09:53:54AM +0000, Gordan Bobic wrote:
>>>> How is transparent alignment fixup going to give you back the
>>>> performance you lose from accesses straddling cache lines?
>>>
>>> You can have structs straddling cache lines and causing performance
>>> problems without alignment issues, or structs being packed too close
>>> together causing false sharing again w/o alignment being involved.
>>>
>>> If alignment problems cause performance issues, then we should deal
>>> with those performance problems.  If they don't, we shouldn't worry
>>> about them.
>>>
>>> Rich.
>>>
>>> ObHack: I once worked with an architecture [68k-based VME hardware]
>>> that not only faulted on unaligned access, but also on accesses of the
>>> wrong *size* (eg. using a short-sized read instruction instead of a
>>> word-sized read instruction).  Dealing with that nonsense involved a
>>> lot of compiler-specific massaging of code and some inline assembly ...
>>
>> I'm very glad you mentioned compilers - this is in fact easily fixable
>> at compiler level. Intel's ICC has an option to make all arrays and
>> structs always aligned to a boundary (up to 16 byte, IIRC). If GCC
>> were to implement such a feature the problem could be made to go away
>> without actually addressing the underlying cause of the problem. It
>> might be a bodge, but since complete fix of the underlying problem
>> isn't going to happen anyway, a good bodge would be a lot better than
>> doing nothing.
>>
>> Gordan
>>
> How does this in any way related to the alignment problem? All C
> compilers align arrays and structures in sensible ways by default. They
> have to. Its a requirement of the C language. Problems come from things
> like pointing directly at elements in  communication structures, which
> may not be naturally aligned. They can also come from overriding the
> default alignment of arrays and structures, which most compilers permit
> these days, with a varierty of constructs like "#pragma pack(1)"

It's related because char[] is byte aligned rather than word-aligned. In 
some cases (e.g. e2fsprogs) a buffer is declared as char[4096], which 
means that when it's cast into a struct, struct elements won't be 
suitably aligned. If the compiler were to align all arrays to a 16-byte 
boundary, this wouldn't be an issue.

I accept that in some cases, having arrays and structures unaligned may 
be useful (e.g. wire protocol packet parsing), but in most cases it 
seems to be just lazy or uninformed programming. In those cases the 
compiler aligning everything to a 16-byte boundary would help.

Gordan