Date: Fri, 29 Nov 1996 07:35:08 -0500 (EST) From: Glen Miner To: Leath Muller cc: djgpp AT delorie DOT com Subject: Re: Optimization In-Reply-To: <329E319E.2A82@gbrmpa.gov.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > > There shouldnt be any problem running 16 bit data in 32 bit form. > > > I don't understand what is your problem here??? How did you get > > > the feeling that your program would actually get slower if you use > > > 32 bit data instead of 16 bit data. > > > > Well, my logic is this: You have to move 2x as much data around; this > > means your L1 cache fills up 2x as fast. This is not good. > > Hmmm...I would think that if about 20 people told me one thing, and I > was the only person considering the other, that I would be wrong... ;) I just figgured that because nobody was able to justify what they were saying I should press on :) > Now, here's the difference: if your accessing 32 bit data, and its in > the cache, you get it for free (ie: 0 cycles), if you access 16 bit > data, you have a size prefix (1 cycle). I have been able to confirm that a size override for word sized data does in fact cause a 1 cycle stall on Pentiums... (I went and looked it up) :) But (not that you were disputing this), this is a quote from the intel web site: > With 8-bit operands, try to use the byte opcodes, rather than using > 32-bit operations on sign and zero extended bytes. Prefixes for operand > size override apply to 16-bit operands, not to 8-bit operands. This was confusing, and needed to be made clear. The final story: avoid short ints, regular ints are just peachy, and keep on trucking with those chars. Have I got this clear? Peace ===[ Gabo / [ABC] : gaminer AT undergrad DOT math DOT uwaterloo DOT ca ]=================== Latest ABC Shogi: http://www.undergrad.math.uwaterloo.ca/~gaminer/shogi.html "What Greenpeace spends in a year General Motors spends in four hours" -Moby