[Python-Dev] Alignment assumptions (original) (raw)

David Abrahams David Abrahams" <david.abrahams@rcn.com
Thu, 28 Feb 2002 15:44:32 -0500

----- 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 PyObjectGCMalloc(). 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 ) 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 .

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