LabVIEW
32 bit vs 64 bit for loops
eximo wrote:so the question remains, how does labview handle the different datatypes with regard to performance?
Sorry, I was misunderstood your initial question. If you interested what is difference between 32 / 64 bit handling regard to performance, then the first answer - in general you will get penalties with 64 bit. But of course it depends from the task. If you really need 64 bit integer arithmetic, then you may get advantages in comparison with your own solution. But in general 64 bit will slow down your code (as you can see in the benchmarks above).
To be honest, for deep understanding we should explore LabVIEW - generated code.
Before continue I'll recommend to you to read the following articles:
Inside LabVIEW - How the Compiler Works
Well, for example, I will prepare pretty simple VI with 32 bit increment:
Now I will disassemble the generated code (I will not explain how I'll do that, but hopefully I'll not break the license agreement, because its my code):
in ebp+430h — pointer to my I32 variable, inc edi - is increment. Pretty easy.
Now I'll change type to 64 bit:
The following code was generated:
As you can see, LabVIEW need more commands for increment 64 bit variable. inc command was replaced with add command, and LabVIEW will handle 64 bit variable in two steps: because additional 4 bytes will be transferred in mov [esi+4], eax follow to mov [esi], eax.
What about performance? No magic:
64 bit code more than twice slow in comparison with 32 bit.
One more point about LabVIEW code generator. Usually the code generated with "traditional" C compiler faster in comparison with LabVIEW. I using this fact for optimizing some bottlenecks in my applications.
For example, I will add one more increment here:
What is expected? One more inc edi command? No, see below:
at address 000000BC we have in edi our variable. Then value will be moved out, then moved in back, therefore three mov commands between two increments.
You will not get much penalties with code above (at least on my PC this code executed nearby the same time as single increment), but I believe, that more optimal assembler code is possible here.
Now back to your cycles with I32 / I64 counters.
The while loop like this:
will be compiled to code like this (I hope, the body of the cycle between AC - F7 extracted correctly):
and 64 bit code like this:
will be compiled to
Just compare amount of commands passed to CPU and you will understand why "32 bit" loop is faster than "64 bit".
And finally, if you need to speeding up your application, then first determine the "bottlenecks" in your code, and then look for faster solution.
General solutions for performance optimization:
1. Rewrite part of LabVIEW code with C (using good compiler such as Intel C++ compiler), then call this code from DLL
2. Look for the parts of the code which can be executed in parallel ans use multi core advantages
3. Change algorithm (for example, if you have sorting, look for different solutions, etc)
Other questions?
Andrey.
PS
The code above was generated under WinXP 32 bit/LabVIEW 32 bit. Pretty sure that the code will be the same under Windows 7 64 bit/LabVIEW 64 bit, but it was not tested yet. Probably will do that at weekend.
This particular application might be (most likely is) memory bandwith limited. This means in order for this algorithme to work the memory size which has to be accessed and copied is the most limiting factor of speed. Since a 64 bit value is double the size of a 32 bit value, a doubling of execution time doesn't seem that strange! Possibly an Inplace Structure inside the loop might make a difference here, though I would not bet on that, the LabVIEW DFIR optimizer is pretty good in optimizing simple shift register operations into the equivalent of an inplace operation.
It would be different if the entire code could be fully located within the CPU registers, but while an empty loop theoretically could be optimized to such code, it is a very academic exercise and I don't see why the LabVIEW developers should spend lots of development time to optimize such a theoretical use case. If you intend to do an empty loop you probably just as well could use a simple delay, which will cost less CPU time and also burn less energy to do nothing.
