Not logged in, Join Here! or Log In Below:  
News Articles Search    

 Home / 3D Theory & Graphics / Coding with cache/data alignment in mind Account Manager
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
Hunter Rognstad

August 18, 1999, 06:55 PM

While reading through some of these great articles at this glorious shrine of knowledge called flipCode, my eyes have scanned over things such as "optimize for the cache", "you might get a cache miss if you do this", as well as a few mentions of data alignment. Although I have somewhat of an idea of how all that stuff works from all this reading I have done, my mind is still a little foggy on it. It seems like everybody else is writing their classes/structs/code with the cache or data alignment in mind, so I was just wondering if anyone here would be nice enough to point me to some articles, documents, or something like that, on how to think about the cache or data alignment when writing classes/structs/code. Yes, I went looking, but unfortunately all I found was little tips written for people who already seemed to know :(


August 19, 1999, 02:26 AM

For CPU specific optimizations, check the website for the particular CPU.
Intel chipset manuals can be found at:

Click on your favorite cpu (left column) and select "manuals" on the following page. There is
a manual for optimizating each specific cpu.

To give exact details on every type of optimization would require writing a manual.
Hey - another tech file! (hint hint - someone???)

General tips that work for any platform:
1) Most chipsets suffer a penalty if variables are not properly aligned. A common technique
is to place all larger variables first (doubles, then floats/dword, then shorts, then
byte) This ensures proper alignment for each type ie: 8 byte vars at an 8 byte boundary,
4 byte vars on a 4 byte boundary, etc. Don't feel bad about adding in a filler field
to get the proper alignment. Note: One compiler optimization in most compilers will
automatically do this. That can increase the size of the record if you do not order them
properly, since the compiler may put in lots of filler fields!
ie: struct { float a; char b; short c[2]; long d; } is optimized to
struct { float a; char b; char filler1; short c[2]; short filler2; long d; }
reordering manually: struct { float a; short c[2]; long d; char b; } does not waste space.
2) Read about the internal configuration of the CPU. Pentium, Pentium II/III have different
internal caches. The manual explains how memory is broken up internally and how accesses
affect performance. This has a big impact on performance as well.
3) If you are using an assembler for some parts, instruction ordering is important. That is
also in the manuals. Good compilers will do this when generating code.
4) Another performance drain - "malloc" or "new". Some compilers have considerable overhead
in those routines and can seriously slow down rendering if called too often per frame.
You can override the new operator for a class so you are able to write custom memory
management routines. If used at the right times, it does improve the frame rate.

Hope this helped!
- tangent

Hunter Rognstad

August 21, 1999, 06:20 PM

>>Hope this helped!
>> - tangent

Just what I was looking for! Thanks.
I should have read those manuals a long time ago when I first saw them, instead of passing them by as technical mumbo-jumbo, hehe.

-Hunter Rognstad

This thread contains 3 messages.
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.