Parallel execution

[george seifert]

I'm sure the answer to this is buried somewhere, but I haven't seen anything yet that answers these questions. If I have two VIs set to run in parallel does one have to return before the next can start? If I have a dual core processor will the two VIs truely run in parallel? Now what if I have three VIs set to run in parallel on a dual core processor? Will two run at the same time and then the third?

Ultimately I'm trying to figure out if can control 12 PXI-4130 SMUs (in one rack with an integrated processor) with the kind of timing resolution that I need. I'm not quite sure how to estimate the time needed for the execution of the VIs. A coworker thinks that if I setup 12 parallel timed loops that everything will run in parallel. I don't think that's right. Maybe half of them can run in parallel.

George

[Aristos Queue]

• If you have a single processor and you start two VIs running, they will run at the same time, with the OS thread swapping back and forth between them.
  
• If you have a dual processor and you start two VIs running, hopefully your OS is smart enough to give one thread to each CPU and just let them run.
  
• If you have a single processor and you start one VI running with two parallel sections, they will run at the same time with the OS thread swapping back and forth between the sections.
  
• If you have a dual processor and you start one VI running with two parallel sections, they will run at the same time and hopefully your OS gives one section to each CPU.
  
• Or, more specifically, if you have N processors and you start M VIs running with K parallel sections among them, LV will spawn N*4 threads and pass those threads out to as many parallel pieces of code, on the same or disparate VIs, as it can. If K > N (i.e. there are more parallel sections than threads), as each thread finishes a "clump" of code (decided by the LV compiler) it will pick up another clump that hasn't had processor time, and thus make sure no one starves for processor attention.
  

All of this without you having to break a sweat and figure out when to do thread spawning, thread unification and thread synchronization. It is the single most beautiful aspect of LabVIEW and dataflow programming. It is this optimal thread scheduling that virtually no other programming language can determine without significant input from the programmer.

As far as timed loops and determinism, it is my understanding that if you have N processors, you can have up to N timed loops and LV Real Time will keep them deterministic.

[george seifert]

QUOTE (Aristos Queue @ May 6 2008, 09:58 PM)

• If you have a single processor and you start two VIs running, they will run at the same time, with the OS thread swapping back and forth between them.
  

But they can't actually run at the same time can they? Let's break it down to the bare minimum. Say all each VI does is add two numbers. Those adds don't execute at the exact same time, right?

[Tim_S]

QUOTE (george seifert @ May 7 2008, 08:53 AM)

But they can't actually run at the same time can they? Let's break it down to the bare minimum. Say all each VI does is add two numbers. Those adds don't execute at the exact same time, right?

I think the answer to this is the same as the answer to if a system is "real time"... it depends on your perspective. If your perspective is (sub-)nanoseconds, then no the VIs do not execute at the same time as a single processor can only perform one task at a time. If your perspective is in milliseconds, then the VIs execute simultaneously.

The first caveat is that both VIs have to have all the data for their inputs at the same time so they start at the same time. If data flow is such that one VI obtains all of it's inputs before the other does then the first will start and can terminate before the second starts execution.

The second caveat is that many PCs out there have more than one processor; this allows the PC to perform two (or more depending on the number of processors) tasks at the same time. Two subVIs that both have all of their data can start, execute and terminate at, quite literally, the same time down to the (sub-)nanosecond level on a dual processor PC.

The assignment of threads to processors is at the mercy of the operating system, which could decide to run two threads on one processor because, say, someone assigned a database to run on the second processor exclusively.

Tim

[Phillip Brooks]

You might want to try and attend one of the Developer Education Day events. I just attended the one in Boston yesterday and there were sessions (Multicore Systems and Improving Application Performance) that discussed parallelism and clumping.

If the event has already happened in your area, contact your sales rep and ask for a copy of the bound materials. Mine has the following barcode info on the back: 351296D-01 Apr08.

[gb119]

QUOTE (Aristos Queue @ May 7 2008, 02:58 AM)

• Or, more specifically, if you have N processors and you start M VIs running with K parallel sections among them, LV will spawn N*4 threads and pass those threads
  

Why 4 - as opposed to any other small positive integer ?

[Rolf Kalbermatter]

QUOTE (Gavin Burnell @ May 7 2008, 06:00 PM)

Why 4 - as opposed to any other small positive integer ?

A question of tweaking and benchmarking by the LabVIEW developer team. The general reasoning is like this:

A too small value will limit the ability of LabVIEW to offload some of the thread management to the OS. A to high value will cause performance degradation due to increased management overhead by the OS.

So 4 is probably a good compromise in allowing LabVIEW to map several code "clumps" directly to OS threads without having to schedule code clumps to much itself and the extra overhead the OS will have in managing multiple threads effectively. In terms of number of allocated threads per process LabVIEW is really one of the heavier heavy weights of most typical applications.

Rolf Kalbermatter

[Aristos Queue]

QUOTE (george seifert @ May 7 2008, 07:53 AM)

But they can't actually run at the same time can they? Let's break it down to the bare minimum. Say all each VI does is add two numbers. Those adds don't execute at the exact same time, right?

As mentioned in another post, no, a single processor can only do one thing at a time. But let's say that one VI does serial "add add add" and another VI does serial "multiply multiply multiply", the processor might very well do "add multiply add add multiply multiply" or any other interleaving. The VIs as a whole do run concurrently, though the individual nodes are done one by one.

[george seifert]

QUOTE (Aristos Queue @ May 8 2008, 09:23 AM)

As mentioned in another post, no, a single processor can only do one thing at a time. But let's say that one VI does serial "add add add" and another VI does serial "multiply multiply multiply", the processor might very well do "add multiply add add multiply multiply" or any other interleaving. The VIs as a whole do run concurrently, though the individual nodes are done one by one.

Thanks. That confirms what I thought.