On 20/09/2015 21:57, Steven Franke wrote: > Hi Bill, Hi Steve, > Thanks for the comments. I will have to use the Google to learn about the > Futures and Promises model… It's pretty simple, you request a function (or something like a function) to run in a thread (from a thread pool) and fetch the result later when it is cooked. So long as the initial arguments can be specific to a thread and the results can be easily packaged (in a struct for example) it is straightforward. The idea is to encourage developers to package up fully independent chunks of work for concurrent processing. > > I have been looking at this: > http://clang-omp.github.io/ > > I have no idea what shape it’s in, but it looked like a potentially easy way > for a low-level programmer like me to parallelize the sfrsd algorithm. Would > you recommend staying away from this approach even if this implementation of > OpenMP for Clang is in good shape? There is no sign of Apple picking up OpenMP, probably because they have no Fortran compiler. We are basically limited to Apple clang/clang++ because that is what Qt is built with. I don't consider this a huge issue as we have shown that we can use OpenMP with Fortran (gfortran) in a Qt application on Mac. > > Steve k9an 73 Bill G4WJS. > >> On Sep 20, 2015, at 11:53 AM, Bill Somerville <g4...@classdesign.com> wrote: >> >> On 20/09/2015 16:11, Steven Franke wrote: >>> You have probably already noticed the fact that the sfrsd should be easy to >>> parallelize. It should be possible to test a bunch of candidate vectors at >>> once. Perhaps that is something worth investigating for sfrsd. In an >>> earlier thread, Bill had suggested that using Qt’s threading facility is >>> the way to go, in general, for WSJT-X — but it’s not clear to me if that >>> applies for this stand-alone C program. >> The first thing I would say is that there is no good reason for this >> decoder to be a separate executable. It makes sense while comparisons >> are being made to KVASD which itself has non-technical reasons for being >> separate. If a KVASD like application is needed then a simple wrapper >> command line application should be written to call the underlying >> functionality. >> >> On the concurrency side the option to use OpenMP is not available as >> there is no C/C++ OpenMP available on Mac. The Qt option is there but >> will require some re-factoring of the code to C++ before it can be >> utilized effectively. The jt9 executable already has Qt dependencies for >> the shared memory access and locking. >> >> I am not a huge fan of concurrency for performance at the finer grained >> level using low level tools like raw pthreads or the Qt facilities. C++ >> itself has much better built in support in the latest language Standards >> with the Futures and Promises model which may be a good solution for >> this type of concurrency. >> >> 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
