Path: utzoo!attcan!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: "packed" objects) Message-ID: <56744@microsoft.UUCP> Date: 20 Aug 90 18:28:09 GMT References: <56268@microsoft.UUCP> <1070@lupine.NCD.COM> <56638@microsoft.UUCP> <1229@lupine.NCD.COM> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 98 In article <1229@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >In article <56638@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >>In article <1070@lupine.NCD.COM> rfg@ncd.com writes: >>>There already exists a defined way within the language to "turn off the >>>standard C++ field ordering restrictions". >>> >>>Section 9.2 (page 173, middle of the page) in E&S says: >>> >>> "The order of allocation of nonstatic data members {which are} >>> separated by an access specifier is implementation dependent (11.1)". >> >>Yes. So given that access specifiers and/or inheritence can bust people's >>expectations on packing order, why maintain restrictions on packing order >>at all? > >Perhaps you missed my point. I was suggesting that the rule quoted above >be REVOKED and DELETED from the final ANSI standard. Gee, you mean we agree? >Are you suggesting that it may be possible to generate more efficient >executable code if arbitrary field re-ordering (by the compiler) is allowed? Yes. >If so, are you prepared to give realistic (not contrived) examples of such >improvements? Yes and no. Clearly, I am not free to talk about MS future plans. Hopefully, even a few obvious examples should demonstrate the plausability of changes in packing order leading to faster code. 1) Fields used frequently together could be moved together, speeding code on machines with bus prefetch. "Fields frequently used together" could be automatically determined via compiler profiling, and might actually be different for different usages of the same class in different programs. 2) Vtable pointers could be moved close to the "this" address, allowing machine codes with short offsets be generate in these important cases. Again, one class used differently in different programs might lead to different lay-out choices. 3) char "booleans" or shorts could be packed-into a base class, leading to smaller total memory usage, less page turns, and thus faster execution in practice. >If (on the other hand) you are only suggesting that a compiler could possibly >pack fields in some better order than I can, let me assure you that you are >wrong. If you would care to organize a test, I'll be glad to pit my brain >against your compiler in a "structure packing" test any day of the week. >As a matter of fact, I surmize that the intelligence necessary to do good >structure packing is not even beyond the reach of your common garden slug. >This fact makes me all the more confused about your insistance that you >want compilers to do this for you. Are you low-rating yourself? :-) Not at all. I don't want to have to act like an assembler for the compiler. Let the compiler do the low stuff, and I'll do the high stuff. In the face of inheritence, only compilers can do packing-in optimizations without violating encapsulation. Joe ought to be able to write an efficient base class, and Sue ought to be able to derive from that base class, and the derivation should make good use of the available space in the base class. Even if you could explicitly state how you want compilers to pack-in fields, then the resultingg code would not be portable, because differing machines are going to have differing alignment constraints, leading to differing "holes" in the original base class. > >Right now, if I have the following C code: > > struct s { > unsigned field1:24; > unsigned field2:8; > }; > >and this is in a program running on a 68000, I can get C compilers from at >least a dozen vendors that will lay this out *exactly* the same way. Thus, >I have vendor independence. That (and portability) are worth money to me. > Agreed. That's why I suggested that one approach might be that "struct" means the same layout as C, as long as you don't derive. Then all your C code continues to work. One can think up reasons why one might want to use inheritence in matching machine registers, but that seems pushing it, to my mind. > >Not if it is not *required* by the standard!!! I wasn't proposing any new requirements on compilers. I was proposing relaxing requirements on compilers that were intended as a weak restriction towards making C++ classes work like C structs. --- Ron continues on, arguing strongly for the advantages on manually clustering over automatic clustering. I disagree. I think performance in other OOPLs and OODBs show that manual clustering doesn't work, because patterns of usage do not remain constant. Thus clustering needs to be done automatically, adapting to changing patterns of usage.