[Python-Dev] Alignment assumptions

[Tim Peters]

[David Abrahams]
> A quick grep-find through the Python-2.2 sources reveals the following:
>
> Include/dictobject.h:49: long aligner;

This is in

#ifdef USE_CACHE_ALIGNED
	long	aligner;
#endif

and AFAIK nobody ever defines the symbol.  It's a cache-line optimization
gimmick, but is effectively a nop (except to waste memory) on "almost all"
machines.  IIRC, the author never measured any improvement by using it (not
surprising, since I believe almost all mallocs at least 8-byte align now).
I vote we delete it.

> Include/objimpl.h:275: double dummy;  /* force worst-case alignment */

One branch of a union, forces enough padding in the gc header so that
whatever follows the gc header is "aligned enough".  This is sufficient for
all core gc types, but may not be sufficient for user-defined gc types.  I'm
happy enough to view it as a restriction on what user-defined gc'able types
can contain.

> Modules/addrinfo.h:162: LONG_LONG __ss_align; /* force desired structure
> storage alignment */
> Modules/addrinfo.h:164: double __ss_align; /* force desired structure
> storage alignment */

This isn't our code (it's imported from the WIDE project), and I have no
idea what it thinks it's trying to accomplish (neither the mystery padding,
nor really much of anything else in the WIDE code!).

> At first glance, there appear to be different assumptions at work
> here about what constitutes maximal alignment on any given platform.

Only the objimpl.h trick might benefit from maximal alignment.

> I've been using a little C++ metaprogram to find a type which will
> properly align any other given type. Because of limitations of one
> compiler, I had to disable the computation and instead used the
> objimpl.h assumption that double was maximally aligned, but also
> added a compile-time assertion to check that the alignment is always
> greater than or equal to that of the target type. Well, it failed today
> on Tru64 Unix with the latest compaq CXX 6.5 prerelease compiler; it
> appears that the alignment of long double is greater than that
> of double on that platform.
>
> I thought someone might want to know,

If you ever compile on a KSR machine, you'll discover there's no std C type
that captures maximal alignment.  You'd have to guess it's an extension type
named "_subpage".  I'm not sure that even C++ template metaprogramming could
manage that bit of channeling <wink> (FYI, _subpage required 128-byte
alignment).

Stupid trick:  If you can compute this at run time, do malloc(1) a few
times, count the number of trailing 0 bits in the returned addresses, and
take the minimum.  Since malloc has to return memory "suitably aligned so
that it may be assigned to a pointer to any type of object and then used to
access such an object or an array of such objects", you'd soon discover you
always got at least 7 trailing zero bits back from KSR malloc(), and
presumably at least 4 under Tru64.

there's-the-standard-and-then-there's-real-life<wink>-ly y'rs  - tim