www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/11/27/19:11:37

To: djgpp AT delorie DOT com
Subject: Re: Optimization
Message-ID: <19961128.160329.4455.4.chambersb@juno.com>
References: <Pine DOT SUN DOT 3 DOT 90 DOT 961127125213 DOT 12832A-100000 AT coop10>
From: chambersb AT juno DOT com (Benjamin D Chambers)
Date: Wed, 27 Nov 1996 19:02:55 EST

On Wed, 27 Nov 1996 13:17:14 -0500 (EST) Glen Miner 
>> : that is only one part of the optimization process. 

***** Actually, after several tests I ran, I found the best perfermance
came from C code with algorithmic optimizations, -O3 used, and NO
ASSEMBLY OPTIMIZATIONS.  At least with my code, GCC was able to figure
out better ways of shuffling registers than I was.  I'll admit, this
won't work with everyone though - you'll have to either profile with
different compilations or run some other benchmarks on them to know for
sure.


>types etc. For example: if I don't really need 32bits worth of int, 
>will 
>things be faster if I declare my variables as short ints? 

***** No!  Benchmarks show that a 486 is slowest with 8-bit data, about
twice as fast with 16-bit data, and even faster with 32-bit data!  On the
Pentium, the difference between 16-bit and 32-bit is even greater.  And a
Pentium Pro actually runs 16-bit SLOWER than a Pentium, with the 32-bit
code much faster than a Pentium.  AVOID 16-bit DATA!
***** Warning, though, if you get a 32-bit DWord aligned wrong, you COULD
actually end up with code that's less than half the speed it should be. 
I *believe* (I'm not sure) the way to make sure it's aligned properly is
to use
_PACKED_.
^^^^^^^^ Somebody check me here.  I could be wrong...

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019