C support for multiport iterator for sparse inputs

[edwardalee]

This PR enables more efficient access to input multiports that are sparse, meaning that few of the channels (typically) have inputs present. This is used as in the following example:

     @sparse
     input[100] in:int;
     reaction(in) {=
         struct lf_multiport_iterator_t i = lf_multiport_iterator(in_ping);
         while(i.next >= 0) {
             // Input channel i.next is present.
             printf("Received %d on channel %d.\n", in[i.next]->value, i.next);
             lf_multiport_iterator_advance(&i);
         }
    =}

In my informal measurement, this yields a 15% improvement in the unthreaded execution of the Big benchmark (with the default setting of 120 Worker reactors).

[petervdonovan]

Directly including port.c in reactor_common.c seems to have worked for AppleClang. It is a hack, but we do it in a lot of places, and we may have a full refactoring of the C build process in the near future anyway. Perhaps it would be most expedient to apply that "fix" here and move on?

Edit: Sorry, never mind, I just saw that that causes other problems, which everyone was probably already aware of.

[petervdonovan]

I moved forward with the "hack" I described above, and everything seems to compile now. I propose to merge this branch without bothering to make the build process work "the right way." These kinds of problems might better be addressed by more comprehensive work on the build system to make it more like reactor-cpp. Related: lf-lang/lingua-franca#1245

[lhstrh]

This looks great! It looks like if the @sparse annotation is omitted, the iterator just checks all channels, which is the right thing to do.

[cmnrd]

Do we have any results on the performance of this change?

[petervdonovan]

In case anyone is still curious, the Apple Clang bug is explained in this StackOverflow post and will be fixed in c-refactoring2.

(@cmnrd, the decrease in execution time was reported as roughly 15% for the unthreaded runtime.)