Last week, we announced the 64-bit LabVIEW beta. That announcement reveals a little about how I've spent the last couple of years of my life.
A long, long time ago, when I first started at NI, we were pretty proud of the fact that LabVIEW started its life as a 32-bit Macintosh application. We didn't suffer the pains of some applications that were having to live in (and later convert from) the 16-bit DOS and Windows environments.
But in some parts of the source code, we weren't as rigorous with our data types as we should have been. I asked the guy next to me, "Hey, Steve. Should I be worried about all these places we assume pointers fit into 32 bits?"
"No," he responded, "we do that all over the place. Somebody far in the future will have to go through all of LabVIEW and fix that."
I did not know then that the "somebody" would be me.
As I alluded to in my Twenty Years post, when I first started working on this, it seemed like an insurmountable task. LabVIEW source code is big, with a lot of developers having their hands in the code over time. And it's part GUI, part compiler, part runtime engine, and part kitchen sink.
Fortunately, I soon got help—a small, but really good team—and we just started plugging away at it. The little milestones along the way...
- Compile the source code without errors
- Compile, link, and crash on launch
- Launch to Untitled 1
- Launch to the Getting Started window
- etc.
There was a snowball effect—we'd fix something, and then a whole bunch of stuff would start working.
I wouldn't say it's been easy. When we first started, I had a fair amount of skepticism... I had fears that we would hit a brick wall, or we'd discover something that would require more effort than we were willing to invest. That skepticism was justified. We had to make some tradeoffs to keep the project from getting out of hand.
From a software engineering perspective, I think we did a good job of containing the risk to 32-bit LabVIEW while pushing forward with 64-bit LabVIEW. (All the code is shared.) Perhaps more on that later.
I'm pretty happy with our level of quality in this beta release. If you've got access to a 64-bit Windows machine, I encourage you to sign up for the beta and give it a try. Here's a teaser for the kinds of things you'll be able to do. (Click to enlarge the image.)
9 comments:
Interesting... So, in your opinion, when will we switch to 128 bit? Is that a task that you foresee will be finished by a currently employed, "young" engineer? Or is that a task for a great great grand child?
Oh, don't think we haven't thought about it.
Part of me thinks it is a long way off. But part of me doesn't want to underestimate how quickly it will come.
I will say that we've tried to make our code work regardless of the internal pointer size. So while we aren't really anticipating a quick bump to 128 bits, we are trying to leave the code in better shape for when the time comes.
Will the 64-bit LV make use of a 64-bit Intel Math Kernel Library (MKL) which should be much faster than a 32-bit one? Matlab 64-bit runs about 15% faster than 32-bit for numerical calculations.
This is slightly off-topic, but I always thought that LV could be an excellent multi-processor compiler since it is much easier to detect separate potential threads in G than in C code. Combined with a multi-processor MKL, LV could be a very strong numerical calculation platform.
Thanks for your comments about the strengths of LabVIEW for numerical computation.
The answer is "yes", we are taking advantage of the 64-bit MKL.
Will this run on XP 64-bit platform, or only Vista x64?
Good question. At this point, we are only officially supporting Vista 64-bit OS's.
However, we have a few users who have successfully used LabVIEW on XP 64-bit and Windows Server 2003 64-bit.
It depends on whether you need drivers, which are much more sensitive to the variations between XP, Vista, and Server OS's than application software like LabVIEW.
This leads to a question that I have. (I may post this as a new topic in the blog.) How important is it for us to support Windows Server 2003 or 2008? Some of the larger (many core) machines are only certified to run the Windows Server OS's, and LabVIEW is an ideal software platform to take advantage of the many cores.
I for one would like to see Windows server support - we are planning to run a distributed DAQ system that could really benefit from having a single computer with say 4 sockets analyzing data (an embarrassingly parallel job in our case). Multicore doesn't help us as much due to still having only one memory link per socket. Not to mention some server/workstation class hardware doesn't have native drivers for xp/vista.
I would also like to see Windows Server 2008 support.. its virtualization and terminal server features look really interesting, and it would be nice to put our DAQ cards on it.
I'm working at a client's site that would love to see LabVIEW running on Windows Server 2008 with 64-bit support. We're doing a massive image acquisition/storage project, and it's going to take quite the machine to handle all of the data transfer. We've found a few 10GigE blade servers running Windows Server 2008 that could handle the processing, if LabVIEW and IMAQ could work on those systems.
Post a Comment