delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/16/09:17:42

Date: Sun, 16 Apr 2000 18:47:06 +0600 (LKT)
From: Kalum Somaratna aka Grendel <kalum AT lintux DOT cx>
X-Sender: root AT darkstar DOT grendel DOT net
To: djgpp AT delorie DOT com
Subject: Re: inefficiency of GCC output code & -O problem
In-Reply-To: <Pine.SUN.3.91.1000416112149.2482o-100000@is>
Message-ID: <Pine.LNX.4.10.10004161837540.1138-100000@darkstar.grendel.net>
MIME-Version: 1.0
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

 On Sun, 16 Apr 2000, Alexei A. Frounze wrote:

> Just make either a plane C code (which is slower) or huge external ASM
> subroutine

Well Alexei, programmers have particularly bad tendency of finding where
the bottleneck in a program really is... say for example if a character
move genration algorithm takes up 90% of your programs time and the
blitting takes up only 10% then what use will writing the blitting in
assembly have..the move genration part is what you should optimise...since
it takes the most time..

So what I would suggest would be to write the entire (or as much code as
possible) using C..then you can run gprof and see which routines are
taking up the most cpu time...and belive me you will be surprised...
*then* you can decide on what routines to optimise or not...

And also I find that surprisingly enough a good optimizing compiler
produces faster code than a hadwritten assembly sequence. Because the
compiler can optimize the output of the C code taking in to advatage the
cpu characteristics of various x86 architectures...

And also the assembly you *think* is fast may sometimes be very slow (ie
there maybe a faster way of doing it) on diferent x86 cpu's....

Grendel



Hi, I'm a signature virus. plz set me as your signature and help me spread
:)

- Raw text -


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