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 post
Share on other sites

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 post
Share on other sites
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 post
Share on other sites
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 post
Share on other sites
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 post
Share on other sites
  • 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 post
Share on other sites
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 post
Share on other sites

Join the conversation

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

Guest
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.

  • Similar Content

    • By Gan Uesli Starling
      We have a gage supplied by a company that shipped it with a *.exe application targeted for LVRTE 2009. I need to retarget it for 2017, but don't have the source code. The supplier had said they'd gladly supply me with a copy of the *.LV source, but they have looked and cannot find their own copy in-house.
      History of Need: Our global corporate mother ship's IT department, in their infinite wisdom, is mandating an upgrade from Win7 to Win10. That with yet even further constraints. They enforce a list of "approved versions" of "approved applications". And for LVRTE, they are insisting upon 2017, with 2009 being a red light.
      So, then, my query. Is converting an app without the source for a higher LVRTE doable at all? File is attached.
      If it is doable, instructions on how?
      Concentricity-Gage.exe
    • By Dawid
      I'm trying to execute LPR.exe command to print some labels on a printer. However as its normal, problems occur. I could not find answer on any topic conneced with "sytem exec". I already tried all described methods (I think so). That's why I'm asking very kindly for any help.
      When trying to execute or call the LPR.exe from System exec VI, I'm receiving error:
      "'C:\Windows\System32\lpr.exe' is not recognized as an internal or external command, operable program or batch file."
      Generally I would like to call function: "lpr -S 192.168.1.5 -P lp C:\test\do_druku.txt" which works from command window without any problem.
       

      print.vi

    • By Huqs
      Hello Labview Users, 
      I happen to have thousands of csv data file that I work with. The only way I recognize them is putting their characteristics in the file name. Which brings the problem of making the names too long and Microsoft doesn't like to accept long name. So I wanted to build a database for all my files. I am in the preliminary stage of building it ( I have attached the file and some of you may have seen it before). 
      What I want to do is, have all my files in the database with random names and list them based on their characteristics. I want to do that in my application in the place of 'file' box. So that I can click on the file and run it (double-click on the file in application to make them work in active file). based on the parameters listed on the database I want to filter them to find any specific file. How the interface of database should look like is shown blow (Image) . 
      It doesn't have to be a real database, just a directory application. I am trying to make it without the database toolkit.  If anyone can help me out and guide me out or guide me in the right direction then that would be great. Thanks. 

      Multicolumn list box v1.5.vi
    • By PatCarbo
      Hi!
      I am looking for a Senior Software Developer to work on our LabVIEW based sensors and applications.
      I am also looking for Senior Software Developer(s) available for contracts (somewhat local to London) .
      Please note that this is about product development in LabVIEW (as opposed to test development).
      More info here: https://silixa.com/about-us/careers/
    • By LogMAN
      Hello everyone,
       
      I recently installed LabVIEW 2013 on my development machine to get rid of some issues in my current project.
      However the project is originally build in LabVIEW 2011, so I had to save all VIs for the new version (no issues )
      I'm still able to build the application executable with no problems too!
       
      Now I want to provide an installer for the customer to upgrade the Runtime engine and some additional stuff
      that has been changed for LabVIEW 2013. And there lies my problem, as I'm currently unable to build an
      installer. The configuration dialog shows 'error generating preview' for any executable in the project:
       

       
      Naturally I tried to generate the preview in the executable, but there seems to be no issue:
       

       
      Creating new specifications did not solve the problem and even creating a whole new project file and including
      the startup VI to it + creating new specifications did not solve the problem...
       
      I made a new project with a single VI for testing if the application builder is not working in general, but thats
      not the case, as I was able to create an application + installer with no issues.
       
      So I'm quite sure there is something wrong in my project that causes this behaviour, but I've currently no clue what that
      could possibly be. I read somewhere (in the NI forums I guess) that there could be issues if you have files in your project
      that are build in an older version (as one of the dll files), so I upgraded it... with no success...
       
      Now does anybody had an issue like that in the past / currently and is there anything I could do or check to regain the ability to provide a proper installer?
      What could possibly cause the installer dialog to fail generate a preview where the application dialog is successfull?
       
      Any ideas are welcome
×
×
  • Create New...

Important Information

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