|CProf cache profiling system available email@example.com (1994-10-13)|
|Data Structure Reorganizing Optimizations [Was: Re: CProf cache profil firstname.lastname@example.org (1994-10-19)|
|Re: Data Structure Reorganizing Optimizations email@example.com (1994-10-22)|
|Re: Data Structure Reorganizing Optimizations robertb@HING.LCS.MIT.EDU (1994-10-26)|
|Re: Data Structure Reorganizing Optimizations johnm@cory.EECS.Berkeley.EDU (1994-10-22)|
|Re: C struct Ordering Rules (Re: Data Structure Reorganizing Optimizat firstname.lastname@example.org (1994-10-27)|
|Re: Data Structure Reorganizing Optimizations email@example.com (1994-10-27)|
|Re: Data Structure Reorganizing Optimizations firstname.lastname@example.org (1994-10-23)|
|[1 later articles]|
|From:||email@example.com (Andy Glew)|
|Organization:||Intel Corp., Hillsboro, Oregon|
|Date:||Wed, 19 Oct 1994 06:58:22 GMT|
Lebeck and Wood's CPROF paper
Alvin R. Lebeck and David A. Wood, "Cache Profiling and the
SPEC Benchmarks: A Case Study," IEEE Computer, October 1994.
discusses, among other things, optimizations that aren't quite legal
in C: rearranging data structures, such as structure element order,
converting array of structs to structs or arrays, etc.
I'd like to start a discussion of why such data structure
reorganization optimizations should still be illegal.
I am aware of the K&R rule that structure elements be in increasing
order of address. But, since the contiguity requirement has been
dropped, and since different machines have different padding rules,
what value does the address ordering rule have? Even network header
code cannot be written portably using structures to access data
structures placed in memory from DMA devices.
I believe that C's rules about data structure organization are
obsolete. Certainly, they are not in the ken of the usual programmer
using C or C++. Why not permit compilers to do such "illegal" data
structure reorganizations, bringing the performance gains Lebeck and
Wood describes to the standard application?
I suggest that this be considered by future X3J11 ANSI C standards (if
any such revisions are forthcoming).
Andy "Krazy" Glew, firstname.lastname@example.org, Intel,
M/S JF1-19, 5200 NE Elam Young Pkwy, Hillsboro, Oregon 97124-6497.
Place URGENT in email subject line for mail filter prioritization.
Return to the
Search the comp.compilers archives again.