Mail Archives: djgpp/1996/12/15/04:57:27
On Fri, 13 Dec 1996 01:09:38 GMT, "Pin F. Sun"
<pfsun AT undergrad DOT math DOT uwaterloo DOT ca> wrote:
>I just changed some heavily used mathematical functions to assembly,
>surprisingly, the performance gain is only 10%. I fully optimized
>the assembly codes according to the floating point rules to make sure
>each mul and add only takes one cycle, but for a function that involves
>15 muls and 30 adds the performance gain is 10%. Is it because DJGPP
>is so efficient that I shouldn't bother to code in assembly? or 10% is
>actually a reasonable increase? I used inline assembly, is there any
>tricks that I don't know about for inline assembly(it's not that I know
>any, but what kind of tricks could be there??) I also tried to write
>an external assembly routine, but MASM reported trillions of errors when
>I changed the memory mode to flat(it was a working assembly routine when
>I used memory mode small & large). I've never worked with flat mode
>assembly before, sorry if this is something out of the topic, is there
>anything else I should do other than just switched the keyword?
>
Assuming that you are calculating with the floating point coproccessor, you
would not get much speed improvement from assembly because you can't fiddle
with the order of calculations enough to get much improvement with any
compiler that optimizes floating point reasonbly well. Unless you are able to
do something fancy like adding using regular proccessor functions while the
floating point coproccessor is processing a long operation.
With MASM flat model, you have to put the proccessor directive before the
.MODEL directive, and don't use the @data, @code macros since using them gave
me incompatible types errors. With those precautions an assembly routine
compiled with the /coff switch successfully.
Bill Lanam
- Raw text -