Thread: Odd assembly problem

except that the results seem to indicate that the MS generated code with the inc in the loop runs slower, even though it 'should' run faster. Im just testing right now, i will probably write the final code in SSE, since speed and accuracy are both important.

You do have compiler optimisations enabled, right? With GCC, there is a huge difference even between "gcc" and "gcc -O1".

To be honest, the C++ loop and asm loop don't even look the same. The C++ loop uses some magic number (16777216) for the number of iterations. I can't even tell what the asm loop uses for the number of iterations.

The magic number is the same as the hex number in the ASM loop, so that's fine.

Try as I might, I can't get GCC to generate a loop instruction for the C++ version, nor get it to use the math intrinsics. Quite frustrating.

Originally Posted by CornedBee

The magic number is the same as the hex number in the ASM loop, so that's fine.

Try as I might, I can't get GCC to generate a loop instruction for the C++ version, nor get it to use the math intrinsics. Quite frustrating.

Try adding "-ffast-math" to your compile command-line.

@abachler:
Using the same decimal constant would reduce the number of "queries" on the "the code doesn't look like it's doing the same thing.

Also, you don't need to push and pop ecx - the compiler will understand register usage in __asm statements.

I prefer to use

Code:

__asm { 
   ... multiple 
   ... lines 
   ... of
   ... code
}

If you want to improve a bit [by "cheating", don't do the fstp/fld inside the loop - just leave the result of the previous loop in st(0).

Your variable "Stop" is never used, right?

Have you checked the assembler output from the while-loop in C? Have you tried using a

Code:

for(temp=0; temp < 167777216; temp++)

instead? Usually, the compiler produces better code for for-loops than while-loops when it comes to constant limit expressions - it may of course be that it makes no difference here.


--
Mats

-ffast-math indeed uses the intrinsics, unless I use -mfpmath=sse. Over a whole program, the advantage of SSE over x87 may well offset this loss.

Another thing to note: According to some information I've found, software sine implementations using SSE math could well be faster than the CPU x87 sine instruction. Especially if you do it on multiple data, and especially if you then go on to do other FP operations on the data. (x87<->sse moves are costly).

Also, 64-bit CPUs might show generally better results, because the x86-64 ABI specifies that floating point parameters are passed in SSE registers, while in the x86-32 ABI all floating point parameters must be passed on the stack. This leads to a severe slowdown when calling external trig implementations. I can actually confirm that from comparing the code generated for my Athlon64 and the Core1 I'm writing this on.

Tricky business, optimizing.

Seeing as SSE doesn't HAVE a sin/atan function, it's quite difficult to make it "use intrinsics" - it needs to copy the SSE register to x87 register and then use fsin to perform the actual fpu operation and then reverse that register to register move. It's slow and not very neat - and you don't really care if it's inlined or not - the overhead of a function call is in the fractions of a percent compared to the 150+ cycles that this function will take.

--
Mats

Originally Posted by swoopy

To be honest, the C++ loop and asm loop don't even look the same. The C++ loop uses some magic number (16777216) for the number of iterations. I can't even tell what the asm loop uses for the number of iterations.

that would be

Code:

        __asm mov   ecx , 0x01000000
 
and
 
        __asm loop begin

0x01000000 == 16777216

Originally Posted by CornedBee

The magic number is the same as the hex number in the ASM loop, so that's fine.



Try as I might, I can't get GCC to generate a loop instruction for the C++ version, nor get it to use the math intrinsics. Quite frustrating.

Im using VC 6.0 Enterprise w/service pack 5 and the processor pack installed

You might have to create a custom EMIT
E2 cb LOOP rel8 Decrement count; jump short if count ≠ 0.

as for SSE not having trig functions, its stil so much faster that You can derive the functions form simpler methods faster than you could get them from FPU instructions.

Originally Posted by abachler

that would be

Code:

        __asm mov   ecx , 0x01000000
 
and
 
        __asm loop begin

0x01000000 == 16777216

Thanks. After I read Corned Bee's post it made sense.

Have you looked into higher-level optimisations first?
For example the trigonometric identity:

Code:

sin(arctan(x)) = x / sqrt(1 + x*x)

According to: http://en.wikipedia.org/wiki/List_of...ric_identities

Of course that may well be slower, but it depends on how it fits with the rest of the surrounding code. E.g. if you're by chance calculating that exact denominator for some other reason anyway, then it would have to be faster. There's also Carmack's fast rsqrtf function to speed up such things.
There's more than one way to skin a cat!

Or perhaps you take the square of that thing anyway - then you can omit the sqrt completely.

Now that you've spend a week on this micro-optimisation, how has this affected the overall result?

For a start, have you run a profile of the program to find out where the real hot-spots are, and not just where you've guessed them to be?

Or as others have started to hint, seek out alternative algorithms which do the same job in a more efficient manner.

Originally Posted by iMalc

Have you looked into higher-level optimisations first?
For example the trigonometric identity:

Code:

sin(arctan(x)) = x / sqrt(1 + x*x)

According to: http://en.wikipedia.org/wiki/List_of...ric_identities

Of course that may well be slower, but it depends on how it fits with the rest of the surrounding code. E.g. if you're by chance calculating that exact denominator for some other reason anyway, then it would have to be faster. There's also Carmack's fast rsqrtf function to speed up such things.
There's more than one way to skin a cat!

That should certainly execute faster than the 240 clocks that the original code takes.

Code:

       fld   input      ;; 4
       fmul input     ;; 6    x * x
       fld1               ;; 4
       fadd              ;; 4   x * x + 1
       fsqrt              ;; 35
       fdivr  input    ;; 22
       fstp   input    ;; 2
                            ;; ==
                            ;; 77 clocks - so approximately 3 times faster than the original code.

--
Mats