CPU load distribution across cores

[Ben_Phillips]

I read on the wiki for actor oriented programming that one of the reasons they started going down that path in the 60's was that it would be able to 'easily' harness the ability to utilize multiple processors/cores.

In the LV AF framework, do you know if this is the case?  Is there some reason I'm overlooking that it would not be able to balance, say 32 equally hungry actors across 32 cores?  The UI thread will still be a bottleneck, being constrained to a single core, but it seems like number crunching should be able to be shared without additional work, provided that your actors are well balanced.

If this is true, this could be a huge reason for people moving to AF in the coming years, even if you're not very concerned with reusability and extensibility.

(Interestingly, Paul Graham wrote recently that if someone could come up with a compiler that could make many core/processors look to the programmer like one fast processor, they'd upend an entire industry.  #6 in this list:  http://paulgraham.com/ambitious.html )

[Daklu]

Ben_Phillips wrote:

In the LV AF framework, do you know if this is the case?  Is there some reason I'm overlooking that it would not be able to balance, say 32 equally hungry actors across 32 cores?  The UI thread will still be a bottleneck, being constrained to a single core, but it seems like number crunching should be able to be shared without additional work, provided that your actors are well balanced.

Setting aside the question about *32* cores, since I have no idea if LV (or Windows/Mac/Linux) can handle that many cores correctly...

The AF itself doesn't do any load balancing--that's all handled by the LV Runtime Engine.  From that perspective, the AF (or any actor-oriented programming in Labview) doesn't provide any capabilities that are not already available to non-AOP applications.  LV uses the same scheduling algorithm to assign executable chunks to individual cores for all multi-threaded code regardless of whether you have two separate actor objects or two loops on a single block diagram.

The value of AOP for LV developers is it gives guidelines and puts constraints on how we write multi-threaded code.  There's a lot of multi-threaded LV code out there based on public sequence QSMs loaded with unidentified race conditions.  (JKI's SM is a private sequence QSM and doesn't have the same structural failings.)  Actor oriented programming makes it easier to reason about the application and figure out what it will do.

[Ben_Phillips]

Sure, I get that it's LV engine under the hood deciding where the threads happen, and that an old school multithreaded app has the same capabilities.  I've just never run across a massively multi-threaded app that was even close to extensible without major pain.  (your slave loop methodology is the closest I've seen, although I'm admittedly a journeyman vying for master status in all this, so might not know about other success stories.)

If the ability to extend the processing power of your app is just writing more code to get some more actors (and cores) into the fray, that's a huge step from having to completely tear down the design and rewrite.

[Daklu]

Ben_Phillips wrote:

I've just never run across a massively multi-threaded app that was even close to extensible without major pain.  (your slave loop methodology is the closest I've seen, although I'm admittedly a journeyman vying for master status in all this, so might not know about other success stories.)

Hmm... I probably ought to go back and add notes to those posts to help prevent confusion.  That terminology has been deprecated.  Slave loops more or less evolved into actors, though it took me a while before I was comfortable calling them that because I wasn't sure what the defining characteristics of an actor were.