🚀 go-pugleaf

In article <1992Nov21.221745.23588@jarvis.csri.toronto.edu> ematias@csri.toronto.edu (Ummm... me!) writes:
>From: ematias@csri.toronto.edu (Ummm... me!)
>Subject: Very puzzling struct problem!
>Date: 22 Nov 92 03:17:45 GMT
>
>   While working on a little arcade-action game in Borland C v2.0, I've
>recently come across something very puzzling; perhaps someone can explain 
>to me exactly what is going on, since I'm not an expert programmer by any  
>stretch of the imagination.  The problem is explained below.
>
>   I have declared a structure which holds all of the various characteristics
>of my sprites, and it looks something like this:
>
>typedef struct {
>	int x, y;
>	int x2,y2;
>	int oldx[2], oldy[2];
>	int dx, dy;
>	int width, height;
>	int dead;
>	int frame;
>	int type;
>	int whatever[1];
>} Sprite;
>
>   The different elements of the structure aren't important -- only the
>fact that there are 16 integer variables defined (i.e., 32 bytes).
>   A configuration like the one above works fine; however, I found that when
>I add or subtract an element from the struct (e.g., removing "int type", or
>changing the bottom one to "int whatever[2]"), two things would happen:
>
>1)  My program's .EXE size would increase by more than 1000 bytes,
>2)  The number of frames per second would slow down drastically!
>	(i.e., the CPU was required to do much more work.)
>
>   Upon fiddling around with the struct elements, I noticed that the two
>problems mentioned above would NOT occur when the number of elements was
>a multiple of 16 -- but only for some multiples.  For example:
>
>- having 16 integer variables in the struct would work.
>- having 32 integer variables in the struct would work.
>- having 48 integer variables in the struct would NOT work.
>- having 64 integer variables in the struct would work.
>- having 80 integer variables in the struct would NOT work.
>- having 96 integer variables in the struct would NOT work.
>- having greater than 96 ints in the struct would NOT work.
>
>   This is totally baffling me, since I can't comprehend why my program
>would be BIGGER and SLOWER just because the number of elements in a struct
>isn't a multiple of 16 -- and furthermore, why it works fine for only
>a select few multiples of 16.  Help!
>
>   Any comments or suggestions would be most helpful, and if I'm naively
>overlooking something then a swift boot to the head would be in order. :-)
>
>Thanks,
>
>     - Mark Rosteck -
>(ematias@csri.toronto.edu)
>(g1marker@cdf.toronto.edu)
>
>
>(By the way, I'm running this on a 33Mhz 386 and using the Compact memory
>model, if this helps to clarify the problem.)

If I assume correctly that you are indexing off a pointer to an array of 
these structs, I imagine that the compiler is optimizing the memory offset 
caculation when the size of an element (the struct) is a power of two.  For 
that special case, it can do a left shift by four to get the memory offset 
for your 16-byte struct but executes a multiply instruction to figure 
the offset if each struct takes up 14 bytes.  The multiply is at least four 
times as slow as the shift, probably more if your index gets very large.

--
Galen Kannarr    kannarr@dseg.ti.com
--
Galen Kannarr
kannarr@mk1501.dseg.ti.com
Texas Instruments Incorporated