Announcing the LabVIEW 64-bit Pioneer Beta

[Dennis_Knutson]

Beta definition.

[altenbach]

---

Cory K wrote:

Is this a free version you would like us to test?

---

Did you completely read the first post of this thread?

I's free in a sense that you don't have to pay for it, but it is expensive because it will take a lot of your free time. It will expire once the beta is over.

Unless you are an experienced LabVIEW programmer and have access to a 64bit machine, you should probably not apply. 😉 It is not a good idea to learn LabVIEW on a potentially buggy beta version.

[REM1]

---

Cory K wrote:

Is this a free version you would like us to test?

Or are you just informing us there is a new version out?

---

This post is to inform you that LabVIEW has a new beta program open that you can apply to join.

[dgholstein]

What is the status of Linux x86-64 LabView?

   ...Dan

[AdamKemp]

We currently are only planning on releasing 64-bit LabVIEW for Windows. We have been compiling 64-bit LabVIEW on Linux in order to help with the effort on Windows (gcc finds more issues than MSVC), but we don't currently plan to release it. So far the customers we have talked to about Linux just need a 32-bit LabVIEW to run on 64-bit Linux (without the need for more address space). I know of several customers that have been doing this successfully (sans drivers) for a while now.

We're interested in hearing from customers about their needs so we can evaluate where we should spend our time. Can you tell us what your specific needs are for 64-bit Linux support? Do you just need LabVIEW to run on a 64-bit OS, or do you actually need a 64-bit native LabVIEW? In the latter case what are your reasons for needing a 64-bit-native LabVIEW? What is your goal and what are your current limitations with 32-bit LabVIEW?

Thanks.

[dgholstein]

Adam, thanks for asking.

I can't imagine needing 64 bit address space for any LabView app, apps like that should be written in C/C++ anyway (same could be said for Java and Python, sorry to you LabView Absolutists/Puritans).

64 bit "support" would be helpful, though.  Since I'm running 32 bit LabView (7.1) on a 64 bit Linux system, I'm forced to maintain 2 sets of libraries (and drivers) and have to explicitly call for 32 bit compile objects since my system would always automatically compile for 64 bit.  In other words, my job is made more difficult.

Skip full 64 bit support, just provide:

• 64 bit integers (signed and unsigned)
• 64 bit CFLNs

   ...Dan

[AdamKemp]

We have had 64-bit integer support in 32-bit LabVIEW since 8.0.

As far as I know it is not possible to call or even load a 64-bit DLL (.so) from a 32-bit process in Linux, so we can't support that use case without providing our own out-of-process system. If performance is not a major concern then you could consider rolling your own out-of-process system for these calls using TCP, named pipes, or some other inter-process communication method.

Our intent with 64-bit LabVIEW is to support applications which require huge amounts of memory. For applications which do not require huge amounts of memory, a 32-bit version of LabVIEW should be sufficient on either 32-bit or 64-bit OSes.

If you don't need a 64-bit address space then why are you using 64-bit Linux at all?

[dgholstein]

Adam;

Quite honestly, there are other reasons to use computers besides LabView, 64 bit Linux allows me to run large PIC models -- I use a network of computers.  Yes, I don't need 64 bit LabView address space and wonder if anyone does, but the networks I use are all 64 bit.  Let me repeat, it's a maintenance issue, why would I dedicate a computer (or VM) to LabView when I can run it from where I do most of my work.

Certainly, I know about TCP/IP sockets, I've used them plenty, but you posed the question, what would 64 bit LabView users be looking for?  I answer, and you say I don't need that, and ask why I need 64 bit Linux -- that's pretty insulting.

What's up with that?  Really sorry I put in my 2 cents.

BTW:  From what you've just posted, no one needs 64 bit LabView, they can all pass along the intense computations through TCP to a real program written in C/C++.

   ...Dan

[altenbach]

I think Adam gave a perfectly good answer, so I don't know why you (or whoever) would give it a one star rating.

dgholstein wrote:

Skip full 64 bit support, just provide:

• 64 bit integers (signed and unsigned)
• 64 bit CFLNs

---

As Adam said, 64 bit integers are supported since LabVIEW 8.0, so all you need is upgrade to get that benefit. 🙂

(And what in the world are CFLNs???)

dgholstein wrote:

 I answer, and you say I don't need that, and ask why I need 64 bit Linux -- that's pretty insulting.

Well, Adam said "If you don't need a 64-bit address space then why are you using 64-bit Linux at all?", so he's asking you a question. He never said you don't need it.

dgholstein wrote:

BTW:  From what you've just posted, no one needs 64 bit LabView, they can all pass along the intense computations through TCP to a real program written in C/C++.
...

I can't imagine needing 64 bit address space for any LabView app, apps like that should be written in C/C++ anyway (same could be said for Java and Python, sorry to you LabView Absolutists/Puritans).

---

How do you possibly expect a serious answer in a LabVIEW board, if you ridicule and belittle LabVIEW like that. I thought that was pretty insulting. 😉

LabVIEW can probably run circles around your C/C++ programs, especially with highly parallel code on multiprocessor systems.

LabVIEW is a real programming language and can be used to write real programs. Unfortunately, seasoned text programmers often have a difficult time to correctly embrace the dataflow paradigm, and you'll end up with grossly inefficient code, peppered with local variables and race conditions. This is not the fault of LabVIEW. Maybe you're currently stuck in that trap. 🙂

[Darren]

---

@altenbach wrote:

 

(And what in the world are CFLNs???)

---

I think he fat-fingered CLFNs.

-D