----- 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>.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4