Joe, > On 9/30/2015 2:57 PM, Steven Franke wrote: >> As Joe said, for EME we probably want to run very large numbers >> of trials. If one were to start multiple calls to sfrsd2, each >> with its own random seed, all at once, and ensure that each >> call runs in its own thread, would this accomplish much of what >> we are after? > > That's a possibile approach for cases in which many synchronized signals > need decoding. > > My idea (which should be useful even when there's only one signal to > decode) is simply to parallelize the "ntrials" loop starting around line > ~147 of sfrsd. Each thread would begin with its own random seed and > have its own local variables for era_pos, workdat, etc. Each thread > would keep track of its own nhard_min, nsoft_min, etc. When any one of > the threads produces a decode, it would terminate the others and > continue as a normal single thread.
Yes, that makes sense to me. I'm unencumbered by any hard knowledge about how these things are done, so I understand that my thinking is probably too simplistic to be practical. I was thinking that there is so little overhead before the ntrials loop that it might make sense to keep sfrsd2 more-or-less intact. Suppose that we re-wrote sfrsd2 using whatever C++ constructs necessary to make it a function that can run in its own thread. There is no need for shared data or communication between multiple sfrsd2 threads except for sending the input data (in the function call) and a return flag. Then, if we create a decode thread for each signal in the spectrum then each of those threads takes care of calling sfrsd2 several times (in multiple threads). Each decode thread would have to call multiple sfrsd2’s with the same input data and different seeds, and then wait for return flags to come in and act accordingly. This seemed like something that would be kind of modular and easy to program. Steve k9an ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
