32 bit faster than 64 bit

[mlevine]

I ran a DAQ program on LabVIEW 2011 32 bit and it used 5-6% CPU according to the Task Manager.

I ran the same program under LabVIEW 2013 64 bit and it used 8-9% CPU according to the Task Manager.

I thought the 64 bit version would be more CPU effecient than the 32 bit version.  What's up?

Thanks,

Mark

[Norbert_B]

Mark,

why should using an extended address space use less CPU?

IF it is the very same system which you re-installed with the other OS version, i would expect the CPU load to be very similar.

BUT as we are talking about a general purpose OS: You never know if the services in background are really identical in terms of CPU load.

Also, even if the CPU load is indeed connected to the application itself, there are still several different sources where this increased CPU load could derive from.

One note: Using more CPU load to execute a specific segment of code does not indicate anything about the runtime performance speed-wise (unless being close to 100%).

Norbert

[mlevine]

It wasn't the extended address space but the accumulator size that should get faster performance.  I'd need less CPU cycles to do double precision math on a 64 bit processor than on a 32 bit processor.  Of course if LabVIEW 32 bit uses the 64 bit  accumulators than I wouldn't expect the CPU load to change.  Anyway the sales guy said I'd see a 20% improvement in execution time.  I don't see how that's possible with the CPU utilization has increased for the 64 bit version.

[Norbert_B · Accepted solution]

If you want to benchmark execution speed, simply looking at the CPU load gives you no useful information.

Do you have a benchmark code you can use to identify performance differences? If so, how do they look like?

Somehow, i get the feeling that you are talking about LV 32 bit on Win 64bit vs. LV 64bit on Win 64bit.Is my feeling correct? Also, are you perharps referring to LV 2012 32bit vs. LV 2013 64bit?

A note regarding the sales guy:

I do not know what you exactly was talking with him about. Simply stating figures like "You gain x% performance when using xyz" is very dangerous and, in many times, not accurate.

Benchmarks on different algorithms (e.g. image processing, matrix computations, ...) indicate, that increased system resources (yes, extended address space IS a type of resource increasing!) benefits the application by x% in average. But, regarding on the algorithm and the amount of data, you maybe don't see any difference at all.

Norbert

[altenbach]

---

@mlevine wrote:

It wasn't the extended address space but the accumulator size that should get faster performance.  I'd need less CPU cycles to do double precision math on a 64 bit processor than on a 32 bit processor.  Of course if LabVIEW 32 bit uses the 64 bit  accumulators than I wouldn't expect the CPU load to change.  Anyway the sales guy said I'd see a 20% improvement in execution time.  I don't see how that's possible with the CPU utilization has increased for the 64 bit version.

---

You seem to be throwing everything ( N bit processor, N bit LabVIEW, N bit OS, N bit address space, N bit accumulators, etc.) into one big blurry pile. We had a similar discussion a long time ago, see my comments here.

Except for the increased address space, using 64bit LabVIEW does not give you any significant advantage.

(Quite a while ago, I was doing some testing and recompiled my DLLs under 64bit intel Fortran and build a LabVIEW 64bit application of my EPR fitting program. The program contains an extensive benchmarking facility.  The 64 bit application was nearly identical in speed (or even slightly slower) and thus I abandoned the idea of potentially moving to 64bit.)

Runing LabVIEW 32bit on a 64bit OS gives you access to a full 4GB of RAM, while running the same on a 32 bit OS gives you less (2 or 3GB max), so going to a 64bit OS for a 32 bit application has clear advantages (details). Upgrading to 64bit LabVIEW is typically not worth it and you get less support for certain drivers and toolkits.

[nathand]

Why would higher CPU utilization be an indication of slower performance? It's often exactly the opposite - higher CPU utilization means the processor is spending less time idle and more time doing useful work.

[altenbach]

---

@nathand wrote:

Why would higher CPU utilization be an indication of slower performance? It's often exactly the opposite - higher CPU utilization means the processor is spending less time idle and more time doing useful work.

---

That's probably a different question and depends on the code quality itself.

Here we are comparing apparently the same program. (of course he was also switching from LabVIEW 2011 32bit to LabVIEW 2013 64bit which are way too many variables.)

If the program only uses <10% of the CPU, it probably means that the execution speed is not determined by the CPU power, but my some defined pacing in the code.

Most likely, there were also differences in hardware here (CPU model, RAM, etc.etc.).

[FTI_Newton]

"Anyway the sales guy said I'd see a 20% improvement in execution time. "

     

I seriously lol'd.

[alexderjuengere]

---

@FTI_Newton wrote:

"Anyway the sales guy said I'd see a 20% improvement in execution time. "

     

I seriously lol'd.

---

from: http://www.ni.com/white-paper/10184/en/

"[...] In addition to increased physical memory, additional registers on a 64-bit processor can increase execution speed of applications by as much as 20%, depending upon how the code is written. For our benchmark, we ran an application that computes the gravitational pull of multiple objects on each other. As indicated in the benchmarks, the larger amount of memory required for more objects results in a sharper contrast between 32-bit and 64-bit systems, with a performance gain of over 25%. [...]"

[altenbach]

---

@alexderjuengere wrote:

---

from: http://www.ni.com/white-paper/10184/en/

...the larger amount of memory required for more objects results in a sharper contrast between 32-bit and 64-bit systems, with a performance gain of over 25%. [...]"

---

Well, they do say that the performance is due to memory. Hard to say anything more without seeing the actual benchmarking code.

Even 25% is typically not worth it and is well within the natural fluctuation in code quality. I start paying attention once we talk factors of two or more. Also different hardware typically differs by more than 25% and if we wait another year, the computers are faster again. A well written program does not require extraordinary hardware, but runs great on an average machine. I still have a LabVIEW 4 program running fine on a 100MHz Pentium 1 with 64MB of RAM. My simulation and fitting program runs fine on either a netbook or a 48core Quad Xeon. the only difference is that the Xeon is about 300x faster (details). 😄

All that said, there are some corner cases where 64bit is faster, but that's due to different handling of NaN with SSE. I think I also noticed some speed increase with certain matrix operations.