Re: Cost of handling misaligned access

On 2/13/2025 1:09 PM, Marcus wrote:

On 2025-02-03, Anton Ertl wrote:

BGB <cr88192@gmail.com> writes:

On 2/2/2025 10:45 AM, EricP wrote:

Digging deeper with performance counters reveals executing each unaligned
load instruction results in ~505 executed instructions. P550 almost
certainly doesn’t have hardware support for unaligned accesses.
Rather, it’s likely raising a fault and letting an operating system
handler emulate it in software."
>

>
An emulation fault, or something similarly nasty...
>
>
At that point, even turning any potentially unaligned load or store into
a runtime call is likely to be a lot cheaper.

>
There are lots of potentially unaligned loads and stores.  There are
very few actually unaligned loads and stores: On Linux-Alpha every
unaligned access is logged by default, and the number of
unaligned-access entries in the logs of our machines was relatively
small (on average a few per day).  So trapping actual unaligned
accesses was faster than replacing potential unaligned accesses with
code sequences that synthesize the unaligned access from aligned
accesses.

 If you compile regular C/C++ code that does not intentionally do any
nasty stuff, you will typically have zero unaligned loads stores.
 My machine still does not support unaligned accesses in hardware (it's
on the todo list), and it can run an awful lot of software without
problems.
 The problem arises when the programmer *deliberately* does unaligned
loads and stores in order to improve performance. Or rather, if the
programmer knows that the hardware supports unaligned loads and stores,
he/she can use that to write faster code in some special cases.
 

Pretty much.
This is partly why I am in favor of potentially adding explicit keywords for some of these cases, or to reiterate:
   __aligned:
     Inform compiler that a pointer is aligned.
     May use a faster version if appropriate.
       If a faster aligned-only variant exists of an instruction.
       On an otherwise unaligned-safe target.
   __unaligned: Inform compiler that an access is unaligned.
     May use a runtime call or similar if necessary,
       on an aligned-only target.
     May do nothing on an unaligned-safe target.
   None: Do whatever is the default.
     Presumably, assume aligned by default,
       unless target is known unaligned-safe.
And/or, an attribute, which seems to be the new style.
   __attribute__((unaligned))  //GCC-ism
   [[unaligned]]  //probably if the C standard people did it...
Most of the pointers will remain unqualified, but most will not do anything unaligned, so this is fine.
For cases where it is needed, a keyword could make sense (probably alongside volatile and the usual mess of per-target ifdefs that usually also needs to exist with this sort of code).
Meanwhile, function wrappers with manual byte-shifts or memcpy is a particularly poor solution (depends too much on compiler magic).
Would be nice if there was a "commonly accepted" or "standard" option, so that one can just use this and not have a mess of ifdefs (or to "just do it with raw bytes" and accept a potentially significant performance penalty).

 

Of course, if the cost of unaligned accesses is that high, you will
avoid them in cases like block copies where cheap unaligned accesses
would otherwise be beneficial.
>
- anton