LabVIEW
LabVIEW for Linux Faster?
Solved!
@danno-5-O wrote:
Some of my staff is averse to using 64 bit installs of LabView or TestStand - there are always instrument issues that make them shy away from it. In the meantime, we are continually asked to make our tests faster. I feel that using 32 bit Windows and the RAM limitation will make LabView run slower (you can always optimize to some extent but there is a limit). If I were to use LabVIEW on Linux I would be in a 64 bit architecture. Should I expect some (even if it is minimal reduction in execution time?
I have seen TestStand improve over the years where it cleared the memory it used while executing (I am pretty sure anything before 2010 just gobbles up memory). Long executions would slow down as they ran as memory became less available. Does LabVIEW benefit from more bits and working memory?
I may see if I can drum up some test cases to see if I can do some benchmarks. However, my limitation at the moment is buying licenses to prove my theories... I can just do it all in python and free up money instead of memory...
You would be hard-pressed to create a (well-programmed) LabVIEW application that uses up all memory available to a 32-bit application. LV 64-bit doesn't have any real advantage over LV 32-bit beyond having more memory space for humongous data (or sloppy programming).
@billko wrote:
You would be hard-pressed to create a (well-programmed) LabVIEW application that uses up all memory available to a 32-bit application. LV 64-bit doesn't have any real advantage over LV 32-bit beyond having more memory space for humongous data (or sloppy programming).
It really depends on the application. For image analysis applications or massive data crunching, 64-bit really can make a difference between working without having to do complicated memory partitioning of your data sets if it isn't even totally impossible to get it running.
But I would NOT expect a significant speed-up of program execution except for some very carefully chosen benchmark scenarios, if you were bound to proof that point. IMHO however it is not very useful to spend that time to find such scenarios just to point out that 64-bit can indeed be faster in isolated cases.
If your question is motivated by the fact that moving to Linux would force everybody to use 64-bit LabVIEW then that is certainly ill advised. There are reasons to choose for Linux development if you really want to, but it certainly won't make your life easier. Support for many Toolkits on Linux is limited and for a few even impossible as they use Windows DLLs internally. While NI makes an effort to have their Toolkits and libraries available for other platforms than Windows, that certainly can't be said for most third party providers. So grabbing that cool library (which internally uses a DLL or .Net) is simply out of question for many things. If your users oppose the move to 64-bit LabVIEW on Windows, they will be running away with loud screams if you propose to move to Linux. š
Unless you need >4GB memory, the performance should be within a couple of percents between them all.
Personally i don't fancy Teststand, though i can see the benefit if you're running lots of different tests made in different languages and platforms.
If the tests are slow, the questions are; what are you measuring and how is it programmed?
It might be physical limitations that hinders any speedup (as a heating process), but maybe some tests can be made in parallell?
It might very well be some inefficient code that increases time by several orders of magnitude compared to what it needs to be.
(I found a better way to handle some files in an old project that was ~100x faster on larger datasets, but it had only used small ones before so it wasn't really noticed how inefficient it was)
/Y
@danno-5-O wrote:
I feel that using 32 bit Windows and the RAM limitation will make LabView run slower
32 bit LabVIEW runs on 64 bit Windows just fine.
