AF with Pure Queue - Experimental Fork

[komorbela]

I am usually testing AF for speed and memory usage as designing my Advanced Message Maker to be sure not to introduce any performance limitation.

I found that using Priority Messages takes much of the time when there is really nothing else to do just send empty messages (for looping or triggering or so...)

So I tried to change the messaging to a simple queue, and the results are impressive. For example to run an actor which runs in a loop by sending message to itself became more than double speed.

By the way thanks to AQ to supply this Experimental fork which I used. It is really easy to test some modifications of the AF and revert is as you like!

I don't know if any of you worried about AF messaging speed (like I have done) but if yes (and you don't need prioritized messages), than I can assure you that using a simple queue is possible and fast. Just download this Experimental version and try it out. You can install it with VIPM, and revert it back with uninstall and install the original AF (my current is 4.1.1.33).

I also  include the test project I used. Just open the project, and run the two different versions to compare the AF's self adressed loop to traditional while loop:

Test Run in Actor.vi

Test Run in While Loop.vi

After you run you see how much time was needed to execute the loop "Goal" times.

The "IterationsOfHeavyLoad" input runs some computation in the loop, but if it's zero, it is really a minimalistic loop.

Important: This is only an experiment, I don't suggest anyone to use it. In case you need this performance I would suggest to cooperate with the owners of AF to make using a simple queue an extra option in the Actor Framework.

[fabric]

Hi komorbela,

I have also had some performance issues with the priority queues. Some time back I did some benchmarking and it turned into quite an interesting project!

Basically I was looking at messaging overhead when running tight messaging loops. I built a simple "time logger" VI and used this VI in a number of different looping architectures to compare results. Here's a quick summary:

1. Baseline: Running time logger VI in a while loop   >>   2.5us
2. As above, but with time logger VI wrapped in a "Do.vi" (dynamic dispatch)   >>   5us
3. Converted into a QMH. Message queue ref wrapped in a class. See screenshot below   >>   8.5us
4. As above, but messages are enqueued from inside the Do.vi. This is really just a slimmed down actor framework with "simple queues"   >>   14us
5. The AF. Messages are enqueued from inside Do.vi   >>   36us

Here's a screenshot of "3":

This was an interesting exercise for me because I rarely need priority queues, but I often need low-latency messaging.

As you can see, adding cool features like dynamic dispatch messages doesn't add much overhead, but adding Enqueuer/Dequeuer wrappers and priority messaging results in a significant performance hit.

I don't have much time to benchmark your "simple queues" version of the AF right now, but my feeling is that it would offer some good performance benefits.

I'm sure this must have been discussed somewhere but I've often thought that the message queue class should be a simple queue which can be overridden with a priority queue child class if required.

[AristosQueue (NI)]

fabric: As I have mentioned elsewhere, I disbelieve any performance specs that do not come with code that I could run on the grid here at NI. The grid is a bank of ~40 theoretically identical machines that, by averaging, has allowed us to remove the wild swings introduced by cache misses, disk optimizations, OS interrupts and a host of other effects that interfere with benchmarking on modern computers. LV R&D has found, through a couple years now of sampling, that any numbers that come from just one system are wildly unreliable, even when allowed to run for a long time or multiple iterations. There's also the multitude of times that people have claimed performance aspects of classes -- both good performance and bad -- that simply wasn't reproducible by anyone else or was based on flawed VIs.

Can you post the VIs that you used to produce these numbers?

(Note: I am not saying your numbers are wrong, just that they are a single data point and we need more points before any such evaluation can be made.)

[komorbela]

to Fabric,

Thank you for your comments and results, it's really motivating to see I am not the only one I also would be interested in to try your VIs, so if you share it I would happily be another "single data point".

to AQ:

I don't know if you got the VIs from Fabric, but you could also run a test on what I sent. What is your opinion about adding the option of using simple queue or priority queue to AF?

[fabric]

Guilty until proven innocent, eh?! Don't worry - I'd be happy to post my code (and I'd be even happier if you prove my results to be incorrect! 🙂

I've just arrived home after a very busy trip to China so I might need a day or 2 to get organised... stay tuned!

[AristosQueue (NI)]

To deploy into the grid, a VI needs to have the standard 4x2x2x4 conpane with number of iterations as an Int64 input in the top left corner for "number of iterations" and a Double output in the top right for "total time of all iterations in milliseconds". All subVIs must either be part of vi.lib or must be in the VI's directory or a subdirectory thereof. No toolkits or modules are installed on the core grid (which is the one I would run on... spares me getting FPGA or RT folks involved).

[fabric]

Its been a busy few weeks... more travel, lots of work on... but I've finally found some time to rejoin this thread! 🙂

As promised, here is a link to my test code (LV2012 using AF4.1)

AQ:  This is not going to run on "the grid", at least not without some work. It was intended more to provide some vaguely quantitative timing comparisons between the fully-blown AF and a range of increasingly simpler messaging approaches.

komorbela:  The "Simple Actor" method is a hacked and simplified version of the regular AF which uses simple queues, although the message queue class is written such that it could be overridden with a priority queue implementation (untested). In my mind, providing a simple queue with a possible override makes much more sense than giving priority queues to all actors...