Comments on: LabVIEW and the Multicore Crisis http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/ an unfiltered stream of data flow consciousness Fri, 5 Sep 2008 20:12:16 +0000 http://wordpress.org/?v=2.6.1 By: Martin Kretschmar http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1352 Martin Kretschmar Wed, 03 Oct 2007 11:28:44 +0000 http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1352 I'm sad so say, that I'm not 100% convinced using LabVIEW, see Event Driven Programming <a href="http://forums.ni.com/ni/board/message?board.id=170&message.id=272099&query.id=394668#M272099" rel="nofollow">. I had far too many crashes, "half" refreshed screens, etc. And often ones code is broken but one can't see where. Editing slightly larger nested structures can be a pain too, I killed a LV 8.2 during an insertation of an addtional case structure after 45 mintues with 100% cpu load. Also an change caused an internal recompile with takes ca. 5 seconds. With LB 8.2.1 the structure became editable and the compilation is done only while saving. And even with the inherent parallelism I still don't quite see how I could implement a queue of worker threads. So for me LabVIEW is more a kind of a nice gadget. I’m sad so say, that I’m not 100% convinced using LabVIEW, see Event Driven Programming
.

I had far too many crashes, “half” refreshed screens, etc. And often ones code is broken
but one can’t see where. Editing slightly larger nested structures can be a pain too, I
killed a LV 8.2 during an insertation of an addtional case structure after 45 mintues
with 100% cpu load. Also an change caused an internal recompile with takes ca. 5 seconds.
With LB 8.2.1 the structure became editable and the compilation is done only while saving.

And even with the inherent parallelism I still don’t quite see how I could implement
a queue of worker threads. So for me LabVIEW is more a kind of a nice gadget.

]]> By: Ken Roberge http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1101 Ken Roberge Thu, 20 Sep 2007 17:32:00 +0000 http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1101 Single but elegant purpose of LabVIEW is true. Unfortunately LabVIEW has an identity problem. I was looking to buy an advanced book on LabVIEW programming, and found 1 book at 3 major stores. They all had multiple shelves with many books of every other programming language. I would love to see LabVIEW expand into more than a single purpose package. It's no advantage for LabVIEW to have multi-CPU capabilities for those who want to program applications beyond what LabVIEW does. If NI could only envision how powerful LabVIEW could truly be, included in WEB, Gaming, etc. You may ask why? I ask... why not? (rhetorically) Single but elegant purpose of LabVIEW is true. Unfortunately LabVIEW has an identity problem. I was looking to buy an advanced book on LabVIEW programming, and found 1 book at 3 major stores. They all had multiple shelves with many books of every other programming language. I would love to see LabVIEW expand into more than a single purpose package. It’s no advantage for LabVIEW to have multi-CPU capabilities for those who want to program applications beyond what LabVIEW does. If NI could only envision how powerful LabVIEW could truly be, included in WEB, Gaming, etc. You may ask why? I ask… why not? (rhetorically)

]]> By: Chris Clark http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1099 Chris Clark Thu, 20 Sep 2007 16:35:55 +0000 http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1099 The theme of LabVIEW has something special reminds me of some article I read back in the early 90s comparing the exponential looking speed increase of computer hardware over time to the shallow slope of increases in the "power" of programming languages/tools over time. The increase of fragility with size looked like a crisis too. OOD was having some impact, Java was an improvement, because as Bill Joy said once, with C++ etc. languages your program really boils down to peeking and poking memory and that is not scalable. I think LabVIEW is a significant development. As a visual, high-level language LabVIEW brings a lot. Good essay about leveraging the multicore trend "for free." The theme of LabVIEW has something special reminds me of some article I read back in the early 90s comparing the exponential looking speed increase of computer hardware over time to the shallow slope of increases in the “power” of programming languages/tools over time. The increase of fragility with size looked like a crisis too. OOD was having some impact, Java was an improvement, because as Bill Joy said once, with C++ etc. languages your program really boils down to peeking and poking memory and that is not scalable. I think LabVIEW is a significant development. As a visual, high-level language LabVIEW brings a lot. Good essay about leveraging the multicore trend “for free.”

]]> By: Scott Hannahs http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1098 Scott Hannahs Thu, 20 Sep 2007 13:20:51 +0000 http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1098 Very true. I have to think that the term "crisis" is a bit harsh here. Even in textural languages one can fork and multi process. It is just that LV it is much easier to comprehend the code and avoid problems. This is an extension of the way that LV is easier to comprehend the code at a higher abstraction level of the 2-D graphic overview. I have been writing multi-CPU code since I did an FFT optimization on an SGI multi-cpu machine back in the lat '80s. This hardly makes it a crisis but more of merely a shift of the multi-core programming mind set into the public awareness. I suppose it is merely that the windows folks are finally catching up with the high perforamance computing and other OSs (you know which OS I mean!! :-) ) that have had this for years. A good objective framework can lead to a simple multi-CPU, event driven program in a text based language. The advantage of LV is the easy visualization and avoidance of race conditions due to the way of looking at the code. The LV IDE takes care of the snchronization, memory allocation issues etc. Of course as Norm points out this comes at price of memory usage. That can be managed, but takes careful programming. I suppose if it were easy everyone would do it! However remember that the kernel of whatever OS you use, real time OS especially, needs to be multi-CPU optimized at a very basic level. This is true of the Mach kernel and some of the linux distributions. Otherwise you are putting lipstick on a pig and all this multi-cpu features only work in simple demos. Very true. I have to think that the term “crisis” is a bit harsh here. Even in textural languages one can fork and multi process. It is just that LV it is much easier to comprehend the code and avoid problems. This is an extension of the way that LV is easier to comprehend the code at a higher abstraction level of the 2-D graphic overview.

I have been writing multi-CPU code since I did an FFT optimization on an SGI multi-cpu machine back in the lat ’80s. This hardly makes it a crisis but more of merely a shift of the multi-core programming mind set into the public awareness. I suppose it is merely that the windows folks are finally catching up with the high perforamance computing and other OSs (you know which OS I mean!! :-) ) that have had this for years.

A good objective framework can lead to a simple multi-CPU, event driven program in a text based language.

The advantage of LV is the easy visualization and avoidance of race conditions due to the way of looking at the code. The LV IDE takes care of the snchronization, memory allocation issues etc. Of course as Norm points out this comes at price of memory usage. That can be managed, but takes careful programming. I suppose if it were easy everyone would do it!

However remember that the kernel of whatever OS you use, real time OS especially, needs to be multi-CPU optimized at a very basic level. This is true of the Mach kernel and some of the linux distributions. Otherwise you are putting lipstick on a pig and all this multi-cpu features only work in simple demos.

]]> By: Dave Grimshire http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1097 Dave Grimshire Thu, 20 Sep 2007 12:09:06 +0000 http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1097 Odd that multi-core and parallelism is mentioned with an application like Labview. These are funcitions of the operating system. Without a good functional understanding of computer science principles we will see unrealistic expectations for our applications. Labview used to be a quick way to provide an excellent user interface to hardware. Single purpose but elegant. Odd that multi-core and parallelism is mentioned with an application like Labview. These are funcitions of the operating system. Without a good functional understanding of computer science principles we will see unrealistic expectations for our applications.
Labview used to be a quick way to provide an excellent user interface to hardware. Single purpose but elegant.

]]> By: Norm http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1084 Norm Wed, 19 Sep 2007 16:56:57 +0000 http://thinkinging.com/2007/09/19/labview-and-the-multicore-crisis/#comment-1084 Yeah, but you know we've been hearing this multi{whatever} crap for years. Multi-tasking, multi-threaded, Hyper-threaded, multi processor, multi-core. And every time they do this, NI goes on and on about the improvements in LV because of it. Personally I'm tired of them re-presenting the same line just wrapped up in new silicon. Yes I agree I love the fact that I get improvements just because I use LV, but I would much rather see LV not take up 100 Meg of memory just to be loaded, or multiple megabytes of memory for a VERY simple exe built in LV. Yeah, but you know we’ve been hearing this multi{whatever} crap for years. Multi-tasking, multi-threaded, Hyper-threaded, multi processor, multi-core. And every time they do this, NI goes on and on about the improvements in LV because of it.

Personally I’m tired of them re-presenting the same line just wrapped up in new silicon. Yes I agree I love the fact that I get improvements just because I use LV, but I would much rather see LV not take up 100 Meg of memory just to be loaded, or multiple megabytes of memory for a VERY simple exe built in LV.

]]>