Hi,

I think you'd give us much more information if youprovide the asm for the whole function.
Is the index r passed as the function's parameter?
BTW, why the source code of the function Intersect4SSEis different in those two cases?

You might try the following untested code:

if(det > 0.0f)
{
  f32 b = -((f32*)&_ba)[r];
  int r1 = 1 << (r*2);
  if(abs(b) < det)
  {
     f32 i2 = b + det;
     if(i2 < distance[r])
     {
       distance[r] = i2;
       retval |= r1 + r1;
     }
  }
  else
  {
    if(b >= 0.0f)
    {
      // b >= det
      f32 i1 = b - det;
      if(i1 < distance[r])
      {
        distance[r] = i1;
        retval |= r1;
      }
    }
    
  }
}

Jim Dempsey

Unfortunately, I neither can recognize the code as open source nor find it by goggling. Would the testing make any sense with taking arbitrary input values and array sizes? I dont think so. What Im missing?

Yeah.. I identified the problem. Investigating... Which compiler you were using?

Hi,

I found out that all cycles in the loop the value of dets is -1.#IND00
This is due to calculation of _mm_sqrt_ps(_dets), where _dets for some reason contains negative values.
Thus, all the cycles the code executes 'if (-1.#IND00 > 0.0f)' only, which is surprisingly very slow on Corei7.
I have doubt that your results were collected in the same conditions. Would you advise how to fix the code?

OK. Doesnt mean that any conclusions can be made, just observations.

First of all check you asm generated by your compiler. What youll see might be surprising. What I got:
With MFST compiler I get extremely ineffective FP comparison code (I checked both debug and release). Here the half of the CPU clock ticks are stalled because of this damned fcomp instruction, which modifies C1 FPU flag and the conveyer waits this instruction to be retired. In release the fcom st(1) is being used not even better. There is some contribution to the stalls due to branch misprediction short trip count probably the reason. Besides decent number of PF assists generated to cope with the undefined value.
Not surprising that on my Corei7 this code required 25% more clock ticks. The more pipeline stages, the more penalty for partial flags and misprediction.

Of course I wanted to play with Intel Compiler. Version 11.1 gave me 60x speed up on Core2 (not forgetting that nothing useful is being calculated, just values population and repetition of the cycle with one comparing instruction). This is due to moving all the code to SIMD area (by default Intel Compiler sets up arch:SSE2 option). Instead of FPU comparison we have comiss instruction scalar compare of values in xmm registers.

The interesting things started when I tried the code on Core i7 (although not equal to Core2 by clock tick rate). Here the Intel code is still faster then MSFTs FPU based code, but not that faster and slower then on Core 2 approx. 20x.
Many branch mispredictions and some other stalls that might be due to floating point assists. Unfortunately, I dont see SIMD_ASSIST event on Core i7 and I cant check it.

But again, this not looks like normal execution path, its a kind of anomaly, and Id like to know how to fix the code to try real execution (I could fix it my self, but the values I could choose might not make any sense for the application and expose another anomaly).

Quoting - Vladimir Tsymbal (Intel) Of course I wanted to play with Intel Compiler. Version 11.1 gave me 60x speed up on Core2 (not forgetting that nothing useful is being calculated, just values population and repetition of the cycle with one comparing instruction). This is due to moving all the code to SIMD area (by default Intel Compiler sets up arch:SSE2 option). Instead of FPU comparison we have comiss instruction scalar compare of values in xmm registers.

Am I to understand there was a requirement for specific unstated options in use of the Microsoft compiler, and it may have been the 32-bit one? Apparently, the normal options /arch:SSE2 /fp:fast /Ox aren't acceptable? Those options are more conservative than the Intel compiler defaults.

Quoting - tim18 Am I to understand there was a requirement for specific unstated options in use of the Microsoft compiler, and it may have been the 32-bit one? Apparently, the normal options /arch:SSE2 /fp:fast /Ox aren't acceptable? Those options are more conservative than the Intel compiler defaults.

I didn't see any requirements to MSFT Compiler, so I took the project as is, may be I messed something. Anyway, with MSFT options set to /arch:SSE2 (/fp:fase as well) I observe almost the same (Although, Intel is"faster" 4x then MSFT on Core2. Yes, looks like MSFT's are more conservative).

Hi,

I did some tests with the code when the -1.#IND values were completely eliminated and defined that the performance of Core2 and Core i7 is practically the same. So, I made up a synthetic test with comiss %xmm1, %xmm0 instruction handling -1.#IND value in one of the operand register and found out that Core i2 is noticeably slower in executing this combination then Core2, most likely due to internal Assists. (No matter which compiler is being used). Although this sounds like a big issue of Core i7, I believe it is not since in real code we should avoid using such values in any calculations (in this example we should check the input for negative values in square root operation). So yes, as you mentioned, this is example of "poorly programmed edge case" and I'm glad you've found another way - that branchless SSE version of the function.