🚀 go-pugleaf

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.