preFire checks takes a substantial part of the execution
Opened this issue · 6 comments
The preFire function takes a substantial part of the execution time and should be redesigned. It is the while loop over consumers that is most costly. For the decoderDemo preFire takes about 30% of the total.
Such redesign should also consider how to incorporate freeing tokens that are references and have structured tokens, e.g. free after all consumers are done with the token.
I have a few questions and suggestions regarding this issue.
The return value from ART_ACTION_SCHEDULER() is discarded in the worker thread.
What was its purpose?
Could we re-porpose it to return: the number of firings (>0), yield (0), and blocked (<0) in order to simplify pre- and postFire?
The original idea was to return information about which input the actor blocks for. A clever actor scheduler (runtime) would then reactivate an actor when its input becomes available, rather than re-checking conditions over and over again. I suspect these re-checks are the reason why preFire/postFire consume so much of the time.
From this perspective, the solution is really to have a smarter runtime that doesn't re-run actors waiting for input (until that input becomes available). The less information we provide in the return value, the more often we will re-run actors in vain.
Conversely, the way to avoid unnecessary preFire/postFire would be to check the conditions when selecting an actor to run. I seem to remember doing something like that for some other, proprietary and rather parallel, machine at some point.
The return value is a vector. In the first code generator (in actors EU project) different actor specific constant vectors was returned dependent on why actor stopped. Unfortunately in caltoopia we have never implemented this and return just one constant vector. From what I remember the return value was only used for statistics and analysing execution.
Actually, the return value is a pointer to a vector. (Semantics, I know, but there's a point.) Currently, each actor has a single such vector, and returns a pointer to that vector, OR a pointer to one of these (actors-rts.h):
extern const int exit_code_terminate[];
extern const int exit_code_yield[];
The runtime could/would/should/might/... simply compare the returned pointer to these two constant pointer values; if neither matches, it means the actor has blocked for FIFO input.
Hence, replacing the return value with an enum would make little (most likely zero) difference. These pointer values are, compiler-wise, equivalent to enums (albeit with funnier values than most enums).
Yes, and in caltoopia we have never reimplemented the different vectors for blocking FIFO but only have one. One of the last things Calle (implemented this the first time) said on caltoopia was that we should fix this so that we get proper halt messages again. Maybe Johan knows the format of the returned referenced vector.
It's OK with me either way.
Thanks, your comments clarifies a lot. This was a side issue that turned out to run deeper than I had expected, so I'll leave it as-is for now.