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
