LabVIEW
Is 64bit support planned for all toolkits?
@Sense wrote:
For me the benefit is I don't need to worry about seeing "out of memory" messages after long runtimes and I don't need to cut up the large measurements for display.
Listen, the increase in available memory is not even an order of magnitude (and if you e.g. want 128GB of RAM, cost will get into the way too), so if you often run out of memory on 32bit, you'll most likely will run out of memory on 64bit, just maybe a little later. Solving out of memory problems by simply throwing more hardware and technology at it is NOT the right way. There are very few applications that really need 64bit. And if the only reason is programming lazyness by blindly throwing gigantic amounts of data to indicators, it might not run out of memory, but it won't be very fast and usable either.
@Sense wrote:
And with native 64 bit I have a slight increase in performance.
"Slight" does not count. You can get a slight increase by disabling your antivirus, by limiting services, changing the power profile, or doing other trivial things.
Going to 64 bit will most likely not speed up your application at all.
You might get a medium increase by switching to a newer computer or different CPU brand.
You might get a large increase in performance by writing better code, optimize for inplaceness and multicore use. Here you can get orders of magnitude improvements that you cannot get any other way.
Computers today are amazingly powerful. It does not help getting the power of a ferrari if the driver is a clueless drunk.
64 bit will not generally give any noticable performance benefit at all. In addition it will normally increase the memory footprint of an application considerably. The only advantage it has is for applications that need to work with very large datasets, that easily can fill up the 2GB that are typically available in a 32 bit application. That is the reason why the IMAQ Vision Toolkit got ported to 64 Bit early on. Here it is more likely that users work with datasets (images) that easily can eat up 1 to 2 GB of memory and then the application simply chokes. If you are not working with explicitly large datasets but simply tend to run out of memory from bad programming habits, 64 bit will not solve anything, it will only run out of memory a little later and make debugging of such conditions even harder.
Another remark that was already made by Mike is that many of the Toolkits are actually fully written in LabVIEW only and therefore will easily recompile to 64 Bit. But their installer doesn't yet support installation into 64 Bit LabVIEW. Installing into 32 Bit LabVIEW and then copying the VIs over is however all that is needed for many Toolkits to work for 64 Bit. Yes it would be super convinient if NI would rewrite their installers to support both 32 bit and 64 bit installation, but no that is still not a very high priority. Most Toolkits are used in applications that benefit little to nothing from moving to 64 Bit. And 32 bit applications in 64 bit Windows simply work so flawlessly that it makes little sense to force that move.
Simple question and solution: Why dont NI write their installer in G? Then it'd install on 32 and 64 bit alike ...
/Y
Also the Windows installer technology is a beast of a thing that can do everything and then some. Rewriting that in LabVIEW is a complete waste of time and basically a hopeless project, and it would need to be adapted to every new Windows version. Then there would be the Mac variant which again is a similar story and since we are at it, make it also support Linux and its myriad of distributions and package manager technologies. That alone would be a project that could easily suck up the entire work force who is currently working on LabVIEW development.
@RavensFan wrote:
That would be a catch 22. If you wrote it in G, you'd need the LV runtime engine in order to be able to run the installer. But you can't use the runtime engine until you have installed it.
You need to rely on an installer that Windows can handle natively such as the MSI installers.
Do you ever install the toolkits without having LV runtime?
You shouldn't need to manually install and fix toolkits on the 64-bit LV, the installers should work.
/Y
@Yamaeda wrote:
@RavensFan wrote:
That would be a catch 22. If you wrote it in G, you'd need the LV runtime engine in order to be able to run the installer. But you can't use the runtime engine until you have installed it.
You need to rely on an installer that Windows can handle natively such as the MSI installers.
Do you ever install the toolkits without having LV runtime?
You shouldn't need to manually install and fix toolkits on the 64-bit LV, the installers should work.
/Y
That is not so trivial. An installer executable written in LabVIEW 2012 will need the LabVIEW runtime 2012 installed in order to execute. What if you have LabVIEW 2013 installed? There is no guarantee that you have the LV2012 Runtime engine installed already in that case. And if they update all installers to use the latest released runtime every time they update LabVIEW you have the same problem for users who want to use the toolkit with an earlier version of LabVIEW. Besides that would be a major hassle to not only take care about a LabVIEW release but also update any and every Toolkit each time.
@rolfk wrote:
That is not so trivial. An installer executable written in LabVIEW 2012 will need the LabVIEW runtime 2012 installed in order to execute. What if you have LabVIEW 2013 installed? There is no guarantee that you have the LV2012 Runtime engine installed already in that case. And if they update all installers to use the latest released runtime every time they update LabVIEW you have the same problem for users who want to use the toolkit with an earlier version of LabVIEW. Besides that would be a major hassle to not only take care about a LabVIEW release but also update any and every Toolkit each time.
Why an executable? Installer VI! 😄 recompiles on the fly, works in many LV versions, works on both 32 and 64 bit. If you have several LV versions you only need to start the appropriate one first.
/Y
@Yamaeda wrote:
@rolfk wrote:
That is not so trivial. An installer executable written in LabVIEW 2012 will need the LabVIEW runtime 2012 installed in order to execute. What if you have LabVIEW 2013 installed? There is no guarantee that you have the LV2012 Runtime engine installed already in that case. And if they update all installers to use the latest released runtime every time they update LabVIEW you have the same problem for users who want to use the toolkit with an earlier version of LabVIEW. Besides that would be a major hassle to not only take care about a LabVIEW release but also update any and every Toolkit each time.
Why an executable? Installer VI! 😄 recompiles on the fly, works in many LV versions, works on both 32 and 64 bit. If you have several LV versions you only need to start the appropriate one first./Y
Nice idea but not what most users expect. They want to run a setup.exe or even better yet have the CD/DVD autostart the installer.
