From: yuntai AT my-deja DOT com
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Voodoo optimization?
Date: Fri, 14 Jul 2000 15:51:44 GMT
Organization: Deja.com - Before you buy.
Lines: 102
Message-ID: <8kncu8$hsl$1@nnrp1.deja.com>
References: <8kltnl$rs6$1 AT news DOT luth DOT se> <20000714021705 DOT 19228 DOT 00000026 AT ng-fk1 DOT aol DOT com>
NNTP-Posting-Host: 143.198.4.90
X-Article-Creation-Date: Fri Jul 14 15:51:44 2000 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
X-Http-Proxy: 1.1 x62.deja.com:80 (Squid/1.1.22) for client 143.198.4.90
X-MyDeja-Info: XMYDJUIDyuntai
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

interesting point:
djgpp seems to be a much better compiler than other commercial ones
(for MS-DOS progs anyway)

this is probably because of the way the compiler handles assembly code.
i found this interesting comparison in xaos:
  |            |
|                     |
  |compiler    |  options                              |  loops per
second   |

|____________|_______________________________________|_________________
   |
  |pgcc2.7.2p  | -O6 -ffast-math -mpentium -frisc      |  5 464
480          |
  |            | -fomit-frame-pointer -funroll-loops
|                     |
  |            | -fopt-reg-use -frisc
|                     |
  |egcs970828  |  -O3 -ffast-math -mpentium            |  5 405
405          |
  |            |  -fomit-frame-pointer -funroll-loops
|                     |
  |egcs970828  |  -O3 -ffast-math -m486                |  4 807
692          |
  |            |  -fomit-frame-pointer -funroll-loops
|                     |
  |gcc2.6.3    |  -O3 -ffast-math -m486                |  4 233
641          |
  |            |  -fomit-frame-pointer -funroll-loops
|                     |
  |gcc2.7.2.1  | -O3 -ffast-math -m486                 |  4 149
377          |
  |            | -fomit-frame-pointer -funroll-loops
|                     |
  |gpc2.0      | -O3 -ffast-math -m486                 |  3 433
962          |
  |            | -fomit-frame-pointer -funroll-loops
|                     |
  |vc5.0       | (optimalizace na max)                 |  3 060
908          |
  |wc10.0      |  -7 -5 -ol -ol+ -om -op -or -ot -fp5  |  2 222
222          |
  |            |  -fpi87
|                     |
  |wc10.0      |  -5 -7                                |  2 217
249          |
  |delphi      |                                       |  2 012
012          |
  |plan9       | (v IDE-586,speed+size optim.)         |  1 623
376          |
  |vc1.0       | (v IDE-586,speed+size optim.)         |  1 531
393          |
  |bc4.5       | (v IDE-486,fastest executable)        |  1 455
604          |
  |bc3.1       | (v IDE-386,fastest executable)        |  1 433
070          |
  |gcc2.7.2.1  |  (no optimizations)                   |  1 281
348          |
  |gpc2.0      |  (no optimizations)                   |  1 109
756          |
  |bp7.0       |                                       |  901
713            |
  |tc2.0       | -1 -f87 -O -r -Z -G -a -mt            |  846
511            |
  |bc4.0       | (v IDE-486,speed optimizations)       |  755
857            |
  |bc2.0       |                                       |  716
535            |
  |bc2.0       | -G -O -2 -Z -r                        |  716
535            |
  |tc2.0       |                                       |  546
546            |
  |bc4.0       | (v IDE-486,speed+size optim.)         |  -
3.6676456...      |

this chart doesnt include the new visual c++ 6.0 however.

compiling each source file i dont think would really help all that
much. the compiliation speed-ups come mainly from certain assumptions
that you can tell the compiler to make (such as loops optimization and
function integration).

a way to make a program truly faster would be to code parts that are
used frequently directly into assembly and to code it so that it can
use the registers of the cpu directly and not have to access the
memory. however, this requires knowledge that niether stl nor i possess
(unless someone decides to make a tirrean chip).

hopefully that chart i posted above will help you with finding more
optimizations for the code.

after seeing that, i saw no reason why to compile in visual c++ 6.0

visual c++ is really good for windows manipulations. (duh)





Sent via Deja.com http://www.deja.com/
Before you buy.