Jump to content

Any difference between application 64 bits vs 32 bits?


Recommended Posts

Hello to all.

I have a 32 bit application created with application builder 32 bits Labview 2015 SP1.

It runs in 64 bits OS but sometime it is slow.

So I think that one solution could be to create a 64 bits application.

is it going to improve from 32 bits to 64 bits?

I am using Vision adquisition software toolkit and its run-time vision.

Thanks a lot.

Link to comment

This document talks about the 32 to 64 bit comparison.

http://www.ni.com/white-paper/10383/en/

The main take away is that not all toolkits are 64 bit compatible and you may not be able to make your program in 64 bit.  Vision appears to be one that is supported so you might be okay.  I've never made a 64 bit LabVIEW program but I've heard the benefits are minimal.  You can give it a try but if your program is running slow now, don't expect it to run fast in 64 bit.  A much larger contributor to performance is going to be how the program was written, and the state of the machine running it.  Is the computer slow in general?  Then this program likely isn't going to run any better.  If you do make the switch be sure and report what your experience is.

Link to comment
19 hours ago, ASalcedo said:

So I think that one solution could be to create a 64 bits application.

is it going to improve from 32 bits to 64 bits?

I am using Vision adquisition software toolkit and its run-time vision.

If your code is using a large amount of memory ~2 GB or greater then yes you might benefit from 64 bit. I'm guessing at the processor level there are also some differences in performance -- for example I believe x86_64 has more processor registers, making some calculations quicker, but on the other hand instructions are larger which uses more memory just for the code itself. Long story short the only way to really answer that is "try it" and the likely answer is not more than a few percent faster or slower.

The better starting point would be to use the profile http://digital.ni.com/public.nsf/allkb/9515BF080191A32086256D670069AB68 and DETT (if you already own it, http://sine.ni.com/nips/cds/view/p/lang/en/nid/209044) tools to evaluate your performance. The profile tool is kind of weird to use and understand but its handy. DETT gives you a trace which can help you detect things like reference leaks (you forget to destroy your imaq image ref, for example) or large memory allocations (building a huge array inside of a loop). And of course there is no substitute for breaking down your code into pieces and testing the parts separately.

Link to comment
On 9/2/2017 at 2:56 PM, hooovahh said:

This document talks about the 32 to 64 bit comparison.

http://www.ni.com/white-paper/10383/en/

The main take away is that not all toolkits are 64 bit compatible and you may not be able to make your program in 64 bit.  Vision appears to be one that is supported so you might be okay.  I've never made a 64 bit LabVIEW program but I've heard the benefits are minimal.  You can give it a try but if your program is running slow now, don't expect it to run fast in 64 bit.  A much larger contributor to performance is going to be how the program was written, and the state of the machine running it.  Is the computer slow in general?  Then this program likely isn't going to run any better.  If you do make the switch be sure and report what your experience is.

I am going to use performance toolkit to improve speed program. But I am going to heck if 64 bits program is better.

Thanks!

Link to comment
On 10/2/2017 at 4:59 AM, smithd said:

If your code is using a large amount of memory ~2 GB or greater then yes you might benefit from 64 bit. I'm guessing at the processor level there are also some differences in performance -- for example I believe x86_64 has more processor registers, making some calculations quicker, but on the other hand instructions are larger which uses more memory just for the code itself. Long story short the only way to really answer that is "try it" and the likely answer is not more than a few percent faster or slower.

The better starting point would be to use the profile http://digital.ni.com/public.nsf/allkb/9515BF080191A32086256D670069AB68 and DETT (if you already own it, http://sine.ni.com/nips/cds/view/p/lang/en/nid/209044) tools to evaluate your performance. The profile tool is kind of weird to use and understand but its handy. DETT gives you a trace which can help you detect things like reference leaks (you forget to destroy your imaq image ref, for example) or large memory allocations (building a huge array inside of a loop). And of course there is no substitute for breaking down your code into pieces and testing the parts separately.

Thanks a lot for replying.

Is there any examples to use DETT toolkit?

Thanks.

Link to comment
  • 4 weeks later...
On 2/9/2017 at 9:54 AM, ASalcedo said:

Hello to all.

I have a 32 bit application created with application builder 32 bits Labview 2015 SP1.

It runs in 64 bits OS but sometime it is slow.

So I think that one solution could be to create a 64 bits application.

is it going to improve from 32 bits to 64 bits?

I am using Vision adquisition software toolkit and its run-time vision.

Thanks a lot.

The quick answer is: It depends!

And any more elaborate answer boils down to the same conclusion!

Basically the single most advantage of a 64 bit executable is if your program uses lots of memory. With modern computers having more than 4GB of memory, it is unlikely that your application is trashing the swap file substantially even if you get towards the 2GB memory limit for 32 bit applications. So I would not expect any noticeable performance improvement either. But it may allow you to process larger images that are impossible to work with in 32 bit. 

Other than that there are very few substantial differences. Definitely in terms of performance you should not expect a significant change at all. Some CPU instructions are quicker in 64 bit mode since it can process 64 bits in one single go, while in 32 bit mode this would require 2 CPU cycles. But that advantage is usually made insignificant by the fact that all addresses are also 64 bit big and therefore a single address load instruction moves double the amount of data and therefore the caches are also filled double as fast.

This of course might not apply to specially optimized 64 bit code sections for a particular algorithm, but your typical LabVIEW application does not consist of specially crafted algorithms to make optimal use of 64 bit mode, but instead is a huge collection of pretty standard routines that simply do their thing and will basically operate exactly the same in both 32 bit and 64 bit mode.

If your application is sluggish, this is likely because of either hardware that is simply not able to perform the required operations well within the time you would wish, or maybe more likely some programming errors, like un-throttled loops, extensive and unnecessary disk IO, frequent rebuilding of indices or selection list, building of large arrays by appending a new element every time, or synchronization issues. So far just about every application I have been looking at because of performance troubles, did one or more of the aforementioned things, with maybe one single exception where it simply was meant to process really huge amounts of data like images.

Trying to solve such problems by throwing better hardware at it is a non-optimal solution, but changing to 64 bit to solve them is a completely wasteful exercise.

Link to comment
On 8/3/2017 at 9:17 PM, rolfk said:

The quick answer is: It depends!

And any more elaborate answer boils down to the same conclusion!

Basically the single most advantage of a 64 bit executable is if your program uses lots of memory. With modern computers having more than 4GB of memory, it is unlikely that your application is trashing the swap file substantially even if you get towards the 2GB memory limit for 32 bit applications. So I would not expect any noticeable performance improvement either. But it may allow you to process larger images that are impossible to work with in 32 bit. 

Other than that there are very few substantial differences. Definitely in terms of performance you should not expect a significant change at all. Some CPU instructions are quicker in 64 bit mode since it can process 64 bits in one single go, while in 32 bit mode this would require 2 CPU cycles. But that advantage is usually made insignificant by the fact that all addresses are also 64 bit big and therefore a single address load instruction moves double the amount of data and therefore the caches are also filled double as fast.

This of course might not apply to specially optimized 64 bit code sections for a particular algorithm, but your typical LabVIEW application does not consist of specially crafted algorithms to make optimal use of 64 bit mode, but instead is a huge collection of pretty standard routines that simply do their thing and will basically operate exactly the same in both 32 bit and 64 bit mode.

If your application is sluggish, this is likely because of either hardware that is simply not able to perform the required operations well within the time you would wish, or maybe more likely some programming errors, like un-throttled loops, extensive and unnecessary disk IO, frequent rebuilding of indices or selection list, building of large arrays by appending a new element every time, or synchronization issues. So far just about every application I have been looking at because of performance troubles, did one or more of the aforementioned things, with maybe one single exception where it simply was meant to process really huge amounts of data like images.

Trying to solve such problems by throwing better hardware at it is a non-optimal solution, but changing to 64 bit to solve them is a completely wasteful exercise.

Thanks a lot for replying.

Absolutely change from 32 bits to 64bits didn't change anyhthing. Finally I decided to check different issues in my program and that is the solution.

Specially synchronization issues.

Thanks a lot.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.