32 bit vs 64 bit for loops

[eximo]

Windows 7, Ultimate

64 BIT dual core centrino

4 GB memory

I am seeking to optimize my code for performance and wrote a test vi to determine which was faster.....a FOR LOOP that was completely 32 bit, or a FOR LOOP that was 64 bit.

I was expecting the 64bit code to win (I actually don't know why I think 64bit should be faster.....)

But the 32 bit code was faster, which leave me with several questions

Why is there not a way to initialize the "i" in the FOR LOOP to a particular representation?  (4 bit, vs 8 bit, vs 16 bit, vs 32 bit, vs 64 bit)

If I change the representation of the i before it is used any where, does it cost performance?

Attached

the vi with the performance test.

A interesting article talking about performance differences between 64 and 32 bit. 

[GerdW]

Hi eximo,

that has been discussed before. And probably there is also an idea in the IdeaExchange to change the "i" datatype...

"does it cost performance?"

Yes, as you have to copy the value of "i" to an other memory location for the type conversion.

[eximo]

If it has been posted before, would you be kind enough to post the link; I have searched and search and have not found an elegant explanation, or a discussion on the topic, that is a specific to this.

[altenbach]

Your benchmark is completely meaningless, because both loops run at the same time and are competing for the same resources. You are basically measuring the scheduling algorithm. Results will also vary depending on the number of CPU cores.

Using a different datatype has nothing to do with 32bit vs 64bit processing. What are you trying to prove?

For proper benchmarking, you should also disable debugging and remove any controls and indicators from inside the loops. Currently, most of the CPU is probably spent updating the indicators.

The iteration terminal is I32, so it can never exceed the range of I32 and converting to anything bigger does not do anything useful. If you want to increment in another representation (e.g. U64), use a shift register instead.

 So far you only told us about the OS. Are you using 32bit LabVIEW or 64 bit LabVIEW???

(Also, please simply give us a link to a public site. It makes no sense to attach an entire zipped up website. 😞 )

Back to the drawing board! 

[altenbach]

---

eximo wrote:
If it has been posted before, would you be kind enough to post the link

---

 See my second reply here, and also the link in my first reply in the same idea discussion.

[altenbach]

---

altenbach wrote:

(Also, please simply give us a link to a public site. It makes no sense to attach an entire zipped up website. 😞 )

---

 To make things easier for everybody, here's the direct link to the website in question. 🙂

[eximo]

Thankyou Altenbach for your investigation into my question, I will read your other post. 

Try this attachment, if you are short on time, you can skip to the bottom for the conclusions on the 64vs32, the original page has been moved, hence the attachment instead of a link.

64bit Labview 2009 is being used.

The page indicates that 64bit datatypes should be faster than 32 bit data types on a 64bit system.  However every single time I ran that vi the 32 bit out performed the 64 bit loop.  I can only guess what is going on behind the scenes.

The purpose of this experiment was to determine, in the instance that memory is not a limitation, and speed is the goal. What data type I can use in a labview program that will yield the fastest reliable program.

I am trying to discover the optimum use of datatypes in loops for my system/program.  I have obviously found that given this configuration the 32 bit datatype is faster.  Is there another way of configuring loops such that the 64bit datatype usage will be faster.

I don't understand why the developers of labview failed to make it possible to initialize the data type of the (i)teration variable.  Maybe there is, and I want to know how, and I want to know if it matters.

My vi should be a relevant and reliable test between 32bit and a 64bit speed.  The first loop to the goal wins.  If they alternated or had a close margin it would be a toss up or an irrelevant test, however the 32 bit loops consistently beats the 64 bit loop on my computer.  Given that the white paper I posted in my attachment suggest that 32bit operations on a 64bit computer should be slower, I would like to know why the opposite is true of this vi. 

[altenbach]

---

eximo wrote:

 I have obviously found that given this configuration the 32 bit datatype is faster.  

---

 No! You have not! As explained above, your benchmark is completely meaningless. It does not tell us anything useful or informative. 😄

(Also note that 64bit OS/code primarily defines the size of the address space and not any specific datatypes. )

[Andrey_Dmitriev]

---

eximo wrote:

...

The page indicates that 64bit datatypes should be faster than 32 bit data types on a 64bit system.  However every single time I ran that vi the 32 bit out performed the 64 bit loop.  I can only guess what is going on behind the scenes.

The purpose of this experiment was to determine, in the instance that memory is not a limitation, and speed is the goal. What data type I can use in a labview program that will yield the fastest reliable program...

---

Hi,

At the first, how can you propagate experience with one application (Stata for Windows) to another application (LabVIEW)?. There are lot of differences in term of used compiler, architecture, etc. Your imagine that if you will change type of variables to 64 bit and your VI will be faster - its not true.

At the second - right way for benchmarking (as altenbach mentioned) is something like that:

Compare with your VI and see differences.

And finally, if speed is your goal, then initially you should determinate the bottlenecks in your cycle. If you have loops with millions iterations, then probably you can perform unrolling for reducing penalties caused by index increment. Especially in your case while loops can be replaced with for-loops. And for for loops you can use parallelizm introduced in LabVIEW 2009:

I would like to recommend to you to concentrate on parallelism in your application, because from dual cores you can get much more than from dual bits 😉

Andrey.

Message Edited by Andrey Dmitriev on 01-25-2010 06:54 PM

[altenbach]

---

Andrey Dmitriev wrote:

And for for loops you can use parallelizm introduced in LabVIEW 2009:

---

Since both FOR loops depend entire on diagram constants, they will probably be folded at compile time and benchmarking might again be impossible.