Getting information about an actor from its enqueuer?

[drjdpowell]

As an aside, are you sure you are gaining from doing 200 plots in parallel, given that you are likely limited by CPU (and you have only a few CPUs) and possibly also the UI thread (and there is only one UI thread)?

[DMurrayIRL]

CaseyLamers1 wrote:

With 200 jobs you would not want to have different reply messages. Aside from doing the enqueuer matching I might ask if there is something unique and specific about the job that is known at spawning of that process. If so I would probably give the job an ID and include the ID in the response.

I include the task/job name in the message ID (so e.g. "Generate 2D Plot" in this case). Also, I include a timestamp in the ID. So with the enqueuer ID as well, I'm happy that I have a unique ID for every message.

[DMurrayIRL]

drjdpowell wrote:

As an aside, are you sure you are gaining from doing 200 plots in parallel, given that you are likely limited by CPU (and you have only a few CPUs) and possibly also the UI thread (and there is only one UI thread)?

This is a very good point, and the answer is - I don't know. Probably not, the way you phrase it. To be honest I'm not overly worried at this stage if I'm gaining any efficiencies, I'm more interested in learning techniques of parallelization.

In terms of working out efficiencies gained, do you have any links to posts on here/LAVA? (Or any guidelines yourself?) Obviously this is something I need to learn as well.

I think I have a second option here in any case, and that is where I could pipeline the generation of plots as the test program progresses. That changes the nature of the program to a certain extent though, as with pipelining I shouldn't be waiting for replies from the nested actors before continuing on with the rest of the test sequence (which is effectively what I'm doing when I do all plots at once in parallel, and check the replies before moving on with the program). So there's more to think about here as well, but that's where all the fun is .

[drjdpowell]

DMurrayIRL wrote:

In terms of working out efficiencies gained, do you have any links to posts on here/LAVA? (Or any guidelines yourself?) Obviously this is something I need to learn as well.

Don't do actor-oriented programming for parallelization performance benefits; do it for the conceptual benefits of separating semi-independent parts of you application.  There are multiple ways to get multi-CPU parallelism, such as parallizable FOR loops or dedicated worker loops, and all these ways can be bandaids for poor program efficiency.  Leave "techniques of parallelization" low on your list of priorities.