Mail Archives: djgpp/1997/11/07/12:21:41
Peter Palotas <blizzar AT hem1 DOT passagen DOT se> wrote:
> >> Here are some tips on code optimizing that I saw somewhere:
> >> * First, profile your code and find what needs improving; it's often not
> >> what you think.
> >> * A good algorithm is likely to make the most difference in speed.
> >> * Tricks in rearranging syntax to get the compiler to make better code
> >> rarely help.
> >
> >I agree with Nate for 1 and 2. Not for 3 if you'll use GCC because for
> >somethings is really stupid and needs some help (I don't know about a better
> >compiler).
>
> Could you give some examples of situations when GCC really needs help to
> provide optimized code!
I don't remmember what steps I did, but when I did my plasma library I was
touching C code, then generating the ASM, etc ... all the time, I discovered
that sometimes you MUST take some desissions, like choose a register for a
variable (I don't mean the register keyword, but say: this local var MUST be
EAX and not other). Of course the difference range from 1 to 6 clocks, but in
the inner loop of the plasma that's executed 64000*70 times per second =
4,480,000 times/sec! so 1 or 2 clocks makes a difference.
I even discovered some bugs in GCC optimizer, I mean cases where is impossible
to teach GCC that he can avoid a reload, but I can easilly see the way. And I'm
not talking about ultra-complex things, these routines are 10 or less lines.
SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -