[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
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