delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/03/05/22:58:45

From: leathm AT solwarra DOT gbrmpa DOT gov DOT au (Leath Muller)
Message-Id: <199703060354.NAA20358@solwarra.gbrmpa.gov.au>
Subject: Re: Netlib code [was Re: flops...]
To: peter AT atmosp DOT physics DOT utoronto DOT ca (Peter Berdeklis)
Date: Thu, 6 Mar 1997 13:54:43 +1000 (EST)
Cc: djgpp AT delorie DOT com
In-Reply-To: <Pine.SGI.3.91.970305110130.8933B-100000@atmosp.physics.utoronto.ca> from "Peter Berdeklis" at Mar 5, 97 04:11:39 pm

> First, as has been mentioned in other threads, reducing the precision of 
> the FPU to less than 64 bits does not generally reduce the execution 
> time, although it does significantly reduce the precision.  I would 
> suggest using 64 bit doubles unless space is a significant concern.

Unless you do a lot of divides and square roots, then reducing precision
is almost a must... :)
 
> As to the problem of gcc reloading memory locations already in registers, 
> this is not just a problem of FPU code.  I used the -S option to generate 
> asm code for a interrupt handler that I wrote in C.  The asm code had _a 
> lot_ of unnecessary register reloads that I had to eliminate.  I think 
> that this is a deficiency in the gcc optimizer.  (Considering the 
> performance of DJGPP relative to other compilers, I assume that the 
> problem is not unique.)

Are the official gcc dudes (FSF is it?) looking at a pentium optimization
for gcc (and thus DJGPP) in the near future? Is there a way to find out,
or even make suggestions? (Well, I know there is, I just dont know where
to go... :)

Leathal.

- Raw text -


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