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? Steve
> On Sep 30, 2015, at 12:30 PM, Joe Taylor <j...@princeton.edu> wrote: > > Hi Bill, > > Thanks for the information on Apple compilers. > > Yes, there are several possible ways to slice the JT65 decoding task > that could benefit from parallel processing. Divide-by-frequency is one > possibility. > > A disadvantage is that it would provide little or no help in most EME > situations, which involve only one (or very few) signals. In such > cases, where we definitely want the best possible sensitivity, we'll > want to set "ntrials" to a fairly large number. Then, processing > distinct portions of the stochastic loop in different threads could be > the best way to go. > > -- Joe, K1JT > > On 9/30/2015 12:10 PM, Bill Somerville wrote: >> On 30/09/2015 16:57, Joe Taylor wrote: >>> Hi Bill, >> Hi Joe, >>> >>> A week or so ago you wrote "On the concurrency side the option to use >>> OpenMP is not available as there is no C/C++ OpenMP available on Mac". >>> >>> Aren't we using OpenMP now in jt9[.exe], on all platforms? Are you >>> saying that on the Mac we can use OpenMP from Fortran, but not from C/C++ ?? >> That's correct. Qt requires the Apple C++ compiler and neither Apple C >> nor C++ support OpenMP. They don't have a Fortran compiler either but >> fortunately with a bit of manipulation we can successfully link gfortran >> using OpenMP with Apple C++ compiled code. >> >> One possible route could be to not use Qt in jt9 but that would require >> quite a lot of work to re-write the necessary code to handle the shared >> memory. Also in the longer term it would preclude making the decoders >> callable functions. >> >> As an aside: Am I right in thinking that the decoders divide the >> received spectrum and attempt decodes across the spectrum. If so then is >> there a better concurrency opportunity in dividing by frequency, >> assuming that can be done independently, rather than at the lower level >> of codeword matching. I ask because there would seem to be less >> sub-tasks in the former which in theory would incur lower >> parallelization overhead. I realise that this may be most relevant to >> the HF problem but I suspect this is the larger one. >>> >>> -- Joe, K1JT >> 73 >> Bill >> G4WJS. >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > ------------------------------------------------------------------------------ > _______________________________________________ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
