[Python-Dev] Alignment assumptions

[David Abrahams]

----- Original Message -----
From: "Tim Peters" <tim.one@comcast.net>

> [David Abrahams, on
>     Include/objimpl.h:275: double dummy;  /* force worst-case alignment */
> ]
> > As I read the code, it affects all types (doesn't this header begin
every
> > object, regardless of its GC flags?)
>
> Nope, only objects that go through _PyObject_GC_Malloc().  It could be a
> nightmare if, e.g., every string and int object consumed another (at
least)
> 12 bytes.

Oh! I guess I should explicitly avoid _PyObject_GC_Malloc() unless I'm
supporting GC, then. As you can see, there's a lot of basic stuff I still
don't understand.

> > and I think that's a very unhappy circumstance for your numeric
> > community. Remember, the type that raised the alarm here was just a
> > long double.
>
> The *Python* numeric community is far more likely to embed a float than a
> long double, and in any case seems unlikely to build a container type
> mixing long double with PyObject* members (i.e., one that ought to
> participate in cyclic gc).

OK, I get it. I'm still not clear on what happens by default, but I was
under the mistaken impression that some types get GC support "automatically"
and thus that people would be subject to undesired alignment problems
without explicitly choosing them.

> I expect we have a blind spot towards long double in general since Python
> doesn't expose or use such a thing, all the developers run on platforms
> where (as far as they know <wink>) it's the same as a double, and "long
> double" was introduced after K&R (so some old-timers likely aren't even
> aware C89 introduced it).
>
> But I'll change the code here to use long double instead -- it's harmless,
> as it doesn't make a lick of difference on any platform that matters <0.7
> wink>.

Just for the record, I didn't twist your arm about this (only the ends of
your moustache).

> Well, nobody has complained yet, but the core never needs alignment
stricter
> than double, and-- as above --an extension type that both did and needed
to
> participate in GC is unlikey.

Makes sense. And I guess because this is 'C', hacking in the appropriate
alignment if such a type ever arose wouldn't be that hard.

> > and my clients were depending on it anyway, it was good enough for
> > my code (not!).
>
> One of the secrets to Python's success is that we tell unreasonable users
to
> go away and bother the C++ committee instead.

That explains everything, thank you (especially the oving relationship we
have with our lusers)!

> [128-byte alignment needed for KSR's _subpage type]
> > I was aware that this was a theoretical possibility, but not that it
> > was a practical one. What's KSR?
>
> Kendall Square Research, my (and Tani's, Tamah's and Steve Breit's)
employer
> before Dragon.  The address space was carved into 128-byte "subpages", and
> the hardware supported Python-style (non-owned non-reentrant) locks
directly
> on a per-subpage basis (Python's lock.acquire() and lock.release() were
one
> machine instruction each!).  Subpages were also the unit for cache
coherency
> across processors.  So use of _subpage in our system code, and in
> speed-obsessed app code, was ubiquitous.  I guess the main thing KSR
proved
> was that you can't stay in business designing custom hardware to execute
> Python's semantics directly <wink>.

/Please/ tell me you weren't trying to build a parallel Python machine
<5.99wink>.