Slow performance of "Polar to Complex"

[D*]

Why is the native "Polar to Complex" function is twice as slow as calculating via cosine and sine? 

[GerdW]

Hi D,

how is the formula you show in your message related to the PolarToComplex function?

[deceased]

I work a lot with the complex datatypes in LabVIEW, but I must confess I have never benchmarked these primitives.

There are some conversions that may go on behind the scenes, for example when you provide R and Theta, R should not be negative, if you provide a negative R it will be converted to a positive R, but offset by Pi.

Can you share the code you used for your benchmark?

0xDEAD

[D*]

Benchmark code attached.

Versus

[RavensFan]

On my system running your code, both sine/cosine and polar/complex came out around low 50msec.  The exp version was around 110 msec.

My results don't seem to confirm yours.

[D*]

Aha. The speed boost is only apparent using LV 64-bit.  I'm using 2018 18.0f2 (64-bit). 

When I try the same code using LV 32-bit indeed both go at the identical ~48ms.

[Bob_Schor]

I wonder if it could have anything to do with the way the functions do "array handling".  I just tried generating a million pair of numbers (not worrying if I used the same set for each test) and did a "Polar to Complex" function and a Real + Imaginary by computing both from r cos theta and r sin theta.  The difference was a few percent, trig winning (but I only tested once)(hold on, I'll run it again ...)(nope, the sine/cosine method still wins by about 8-10 msec/million numbers, or about 10 nsec/conversion).

Polar to Complex

This was done on Windows 10 x64, LabVIEW 2018 (32-bit).

Bob Schor

[D*]

@Bob : The Random number generation can be expensive.  In this case, it might even be comparable to what we are trying to measure.  Perhaps see how much of a performance boost if either :

A: Replace the random number generators with front panel controls. (LabVIEW still should have to read the front panel control every iteration).

B: Move the random number generation outside of the performance test.

Regarding "array handling":

Modern CPUs can optimize for applying a single operation to an array of data.  This is taken advantage by the LabVIEW compiler (remember the old SSE2 checkbox in the .exe builds?  That's what this is: the SSE2 Streaming Single Instruction, Multiple Data (SIMD) Extensions 2 (SSE2)).  Operating on arrays is also the case that I'm most interested in.  Putting the input number generation inside the for loop, may prevent that optimization. (must create a random number or read front panel control in between each polar-to-complex conversion). 

Side note : Be careful with the debugging switch in your test bench.

• If debugging is off, then LabVIEW will see that the loop doesn't have any outputs, and it will not compute it, and the test code will take about zero seconds.  If you tunnel the output and put it to an indicator then the big ForLoop will have to execute and you'll see the real performance.  Since LabVIEW has maximum performance with debugging off, especially in large N ForLoops with fast iterations, that's an important aspect to consider.
• If you have debugging on, then you may not have full compilation optimization, but LabVIEW won't cull code.  In the case we are discussing here, I still see improvement switching away from the native polar to complex even with debugging on.

I'm still curious why it's faster, and why it's only faster on 64-bit OS.  But I'll won't look the gift horse in the mouth.  Enjoy the boost!

-D

[alexderjuengere]

When I run Test polar to complex.vi ‏10 KB

---

@D* wrote:

Aha. The speed boost is only apparent using LV 64-bit.  I'm using 2018 18.0f2 (64-bit). 

When I try the same code using LV 32-bit indeed both go at the identical ~48ms.

---

"Polar to complex" appears to be a bit slower than "Sine and Cosine"

60..65 ms in comparison to 55..60 ms

with LabView 2018 x32 on Windows 10 x64:

[GerdW]

Hi,

for me PolarToComplex and SinCos are nearly the same speed:

(Intel i7-4700HQ)