Announcing the LabVIEW 64-bit Pioneer Beta

[AdamKemp]

We don't need to debate the pros and cons of LabVIEW on the 64-bit beta forum.

Dan, I think you misinterpreted my comments. I am not trying to be insulting at all. I apologize if I was unclear.

I am just trying to determine what your needs are. There are many people using 64-bit Linux for many reasons which have nothing to do with large address spaces (for any applications), and I wanted to see if that was the case for you. That does not mean that those people (or you) are wrong for using 64-bit Linux. I wasn't making any judgment. I'm just trying to determine what YOUR use case is so that we can understand how LabVIEW fits into that use case. Like I said, our intent with the 64-bit port is to address use cases which require large amounts of memory in LabVIEW. There may be other benefits to running a 64-bit native LabVIEW, but we have to ask these questions in order to figure out what those uses are, how common they are, and how important they are for our users. Then we can weigh those issues and determine where we should be spending our time.

I understand that supporting multiple architectures can be a bit of work. That's what we're doing with LabVIEW in supporting Windows, Mac, Linux, PharLap, VxWorks, and now Windows 64-bit, and that is why we are taking such a cautious approach to adding another architecture before we fully understand the needs of our users.

[dgholstein]

altenbach;

OK, CLFN. (you really didn't get it from the context?)

I use LabView, I like LabView.  There are Puritans here who believe LabView is the best at everything -- when you move into 64 bit address space, with serious physics problems, where the overhead of a simple function call alone moves the programmer to use embedded C macros and MPICH-based clusters; LabView starts to need help.

Again, I like LabView, and I was asking for the ability to use the best of both worlds -- the response was:

---

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

---

I suspect LabView is written in C/C++, so why should we argue about which is the most efficient, I'd be pretty impressed if LabView is written, and compiled solely in LabView (isn't it Pharlap C?).

My LabView programs are not constrained by text-based programming thinking  (defending against the oblique put down), I get LabView very well, thank you.

---

Adam;

Thanks for the clarification.  Back to the wish list, for 64 bit LabView, please provide a CLFN for both 32 and 64 bit DLLs, nspluginwrapper may or may not be a model for doing that.  I imagine that would not be an easy task, but it would make everyone's lives far easier.

   ...Dan

[altenbach]

---

Adam Kemp wrote:
We don't need to debate the pros and cons of LabVIEW on the 64-bit beta forum.

---

This is not the 64-bit beta forum, but the plain LabVIEW forum. Still, I agree that this thread should be dedicated to the specifics of 64 bit LabVIEW. 🙂

---

dgholstein wrote:
OK, CLFN. (you really didn't get it from the context?)

---

Sorry, despite 10+ years of LabVIEW, I have also never heard of this acronym. It always helps to spell things out, in order to be as clear as possible. 🙂

dgholstein wrote:

I suspect LabView is written in C/C++, so why should we argue about which is the most efficient, I'd be pretty impressed if LabView is written, and compiled solely in LabView (isn't it Pharlap C?).

---

I cringe at the thought of basing an opinion on a suspicion. Even if it were so, you are falling into an analogy trap. With similar arguments, you could say that a chess program can never play better that the programmer who wrote it, or that a race-car could never possibly go faster than the running speed of the designer. Silly? Right!

---

dgholstein wrote:
My LabView programs are not constrained by text-based programming thinking  (defending against the oblique put down), I get LabView very well, thank you.

---

Sorry, again I don't know what an oblique put down is, but my comment was very generic and based on actual observations here in the forum. Why does everything I write need to have negative or positive connotations or be read as a personal attack? 😄 How many smileys do I possibly need to add? :D:D:D

First, I don't even know if you are a "seasoned" text programmer, and second, I sometimes do pick up on subtle nonverbal clues, such as the ability to spell LabVIEW with the correct capitalization. It is often (but not always, such as apparently in your case ;)) a sign of LabVIEW skills. 😮

There are plenty of old discussions in the LabVIEW forum comparing LabVIEW and text based code. If you feel that you have any new insights, more specific data, and if there is general interest, I started a new thread to continue this discussion.

[zipmanx]

So if Labview 64bit pioneer is the first native 64bit labview, what does that make the current labview 8.6, 8.5, 8.2 and DAQmx?

-> are vista 64 installs of labview 8.6 simply running as a 32bit app in vista? (like 32bit apps in win xp 64)

Will we see support of win xp 64bit? The other reseachers i know on the ualberta campus have stayed away from vista, and will also use win xp 64 instead of vista 64 for matlab and other applications.

[AdamKemp]

All current releases of LabVIEW are 32-bit applications, so yes, when you install LabVIEW on Vista 64 (or XP 64) you are getting a 32-bit application. In my experience, most applications that I install on Vista 64 are 32-bit applications, and there's not really a reason for most of them to port to native 64-bit code. The primary reason to make an application 64-bit native is to get more virtual memory space, which most applications don't need. Since some customers  want to or need to create applications with LabVIEW which use large amounts of memory, we decided to port LabVIEW to be a 64-bit native app.

[Chris_Megdanoff]

Are you still able to join the 64bit beta program?  If so, we would like the opportunity.  I do not see it in the list on the beta link.

We are interested in it because our application involves very large data sets that are currently slow to process because they must be read from the Hard Drive and the access time is the limiting factor.

Chris Megdanoff

[REM1]

Signup for the 64-bit pilot has closed.  Keep your eye on the forum, however, as new beta announcements come along from time to time.

[pallen]

Signup for the 64-bit pilot has closed.  Keep your eye on the forum, however, as new beta announcements come along from time to time.

Rats!  I just built my first serious gamer box in years.  Would have been fun to play with 64 bit LabVIEW.   

[REM1]

---

pallen wrote:

Signup for the 64-bit pilot has closed.  Keep your eye on the forum, however, as new beta announcements come along from time to time.

Rats!  I just built my first serious gamer box in years.  Would have been fun to play with 64 bit LabVIEW.   

---

Well...keep your eyes open.  You never know what will pop up. 

[RichardBallantyne]

Hi,

I just started using LabVIEW 8.5 on GNU/Linux, but I am unable to use the Call Library Function Node to call up functions contained in 64-bit shared libraries (*.so files).  This greatly reduces the usefulness of LabVIEW on GNU/Linux for me and is a big disappointment.  Isn't the future of computing on the desktop all 64-bit (not 32-bit)?  I think the only place for 32-bit these days is for netbooks and embedded stuff.  That being said, I think it would be wise for National Instruments to plan to add 64-bit support to LabVIEW on GNU/Linux eventually.  I know I don't want to end up having to compile 32-bit versions of all shared libraries just so that LabVIEW can access them.

So I guess my question is this:  Are there still no plans to add 64-bit support to LabVIEW on GNU/Linux as per the FAQ ( http://www.ni.com/linux/support.htm#2 )?

I was planning on developing a free SQL Database toolkit for LabVIEW on GNU/Linux that uses unixODBC and/or MyODBC.  The only reason why we still run Windows on our test stations is because that they need to interface with SQL databases.  Currently that is done using Invoke Nodes to ActiveX ODBCs, which only works in Windows.  However, I would prefer to replace Windows with GNU/Linux on all our test stations since it would be easier (for me at least) to lock down and secure GNU/Linux compared to Windows.  Plus if ran GNU/Linux on our test station PCs, then I could keep our IT people away and they wouldn't feel the need to interfere by installing anti-malware and monitoring software on them.  That seems to cause more problems than it solves since it slows down testing.

Also, LabVIEW 8.5 on GNU/Linux runs noticeably faster (more responsive) than LabVIEW 8.5 on Windows XP on equivalent PC hardware.  Has anyone else noticed this too?

Thanks,

Richard