Nonblocking Algorithms and Scalable Multicore Programming | Hacker News Reader

Nonblocking Algorithms and Scalable Multicore Programming

queue.acm.org

74 pointssbahra11 comments

> "the design and implementation of correct, efficient, and scalable concurrent software is often a daunting task"

A few years ago, I had to help our EEs write some testing software in LabVIEW. I was blow away by how elegantly it solves concurrency and fault tolerance to bad data. It took no extra design to utilize multiprocessing and multithreading hardware. All of the deadlock and race conditions problems that threads introduce were a thing of the past.

Has anyone else had a similar experience? Why don't more people use LabVIEW or languages like it outside of data acquisition?

I had some experience with LabVIEW for FIRST Robotics, and I honestly hated it. I could fit so much fewer code on a screen, making it harder to debug/understand, and the compile times were absolutely horrific. (2 hours for the robot equivalent of "Hello, World!" is really unacceptable)

The following year we switched to C++, which compiled in <10s on the same machine. Supposedly LabVIEW got some performance tweaks, but we didn't bother to check back with it.

So while I never used the multithreading aspects of it (And I can see how they would work, variables are passed in such a way to explicitly lay out what modifies them), I can easily see people having issues with LabVIEW.

Yes, it's true LV has its own issues. It's a memory hog and the UI is cluttered. Reminds me of where JavaScript was before V8 came out.

My experience was very different from yours. I couldn't believe how simple it was to add an additional test in parallel. It was just a copy/paste, update the functions, test parameters, and I/O. If only writing multithreaded code was that simple. After my experience, I could see how LV could be a good fit for computer vision apps running on highly parallel architectures.

It's too bad there aren't any other modern, open dataflow languages out there. I wonder how much research academia has put into dataflow concurrency.

Oh I definitely agree with you there! LabVIEW was amazingly easy to just grab and run with,and I didn't have any issues with the language design. I think it's something with a ton of potential (especially for writing multithreaded code), it just needs to compile large programs faster (maybe precompile functions you import from libraries?) and shrink the default spacing between elements.

I wouldn't call LabVIEW open, though - isn't a retail copy close to $3000? (might be another reason it isn't as commonly used)

Read this paper: http://pdf.aminer.org/000/055/177/static_tokens_using_datafl...

If you want more:

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=145814...

http://web.njit.edu/~ziavras/MICPRO-2002.pdf

http://www.cs.ucf.edu/courses/cop4020/sum2012/COP4020_Lectur...

I wonder how much research academia has put into dataflow concurrency.

Me too! Anybody here know about this?

From what I remember of how LV works underneath, it's essentially a task stealing system: a bunch of worker threads pulling out clumps of code from a queue and executing them. I don't remember for sure, but I suspect it uses locking underneath to protect the queue. The reason I bring this up is that it wouldn't work very well if your parallelism was very fine-grained.

It's an elegant abstraction but by no means is it unique. Haskell springs to mind as another language with a similarly elegant abstraction for parallelism. I'm necessarily generalizing a bit but I would say that all these "automagical parallelizing" systems suffer from the problem of not working very well unless the granularity of parallelism the runtime was designed for matches the granularity of parallelism that your program has.

As with anything else, it depends on what you wish to achieve.

For FPGA programming it worked great. LabView by design is fully parallel, which is exactly what you want in this case: it's like having 1000s of small, independent CPUs. With VHDL it took an order of magnitude more time to achieve the same. Also it was easy with LV to tweak the low level details until everything fits in the 3M or so gates available.

Other use case would be when the customers of your app are only engineers who know LabView. They (might) accept the limitations in exchange of quick tweaking here or there.

For anything else I would avoid LV. Larger projects are very hard to maintain, the declarative programming will scare most of the developers away and I could not find any advantage over mainstream programming languages.

In my (admittedly limited undergraduate-level) work with it, it seemed like so many of these anybody-can-program-just-use-icons-yeah! programming environments, which are super productive as long as (1) you know where all the buttons and knobs are (seemed like I spent ages looking for the right icon, wishing I could just type a line of code instead) and (2) you don't want to stray off the path assumed by the environment's designers (in which case the thing feels exponentially byzantine).

It's become kind of a nascent movement to start writing and using these systems for new application domains. Here's one for node.js: http://noflojs.org/

There are various dataflow languages. http://en.wikipedia.org/wiki/Dataflow_programming#Languages

Reply on news.ycombinator.com