Hi Bill,
Ok, thanks.
I would think most would want to take advantage of multiple cores as much as
possible but wanted to make sure it wasn't a build variable.
73'sGreg, KI7MT
On Friday, February 13, 2015 10:39 AM, Bill Somerville <[email protected]>
wrote:
On 13/02/2015 17:35, [email protected] wrote:
> Hi Bill,
Hi Greg,
>
> From you previous SVN commit:
>
> " If parallel decoding is not required or desired, it can be constrained
> by setting the environment variable OMP_THREAD_LIMIT=1. "
>
> How or where is this variable set?
In the shell environment:
Windows 'set OMP_THREAD_LIMIT=1'
Everywhere else (shell dependent) 'export OMP_THREAD_LIMIT=1'
I would expect most if not all users to not bother and use the default
fastest dual mode decoding.
>
> 73's
> Greg, KI7MT
73
Bill
G4WJS.
>
> On 2/13/2015 10:20 AM, Bill Somerville wrote:
>> Hi All,
>>
>> some developers and testers of WSJT-X have been using the optimized
>> jt9_omp program to get parallel decoding of JT65 and JT9, until now a
>> patch was required to use this version.
>>
>> Now that the OpenMP parallel decoding variant of jt9 has stabilized, is
>> avaiable on all platforms and, seems to be very effective; I have
>> changed the CMake build script to use it by default. The patch is no
>> longer required. There is no jt9_omp program any more.
>>
>> One consequence of parallel decoding is that in dual JT65 and JT9
>> decodes are interleaved. Also even though the same code as before to
>> decode the Rx frequency quickly is in place, a decode from the "other"
>> mode may win the race and be displayed first. The "on frequency" decode
>> is still being delivered as quickly as is possible.
>>
>> If you want to test without parallel decoding, the OpenMP code can be
>> constrained to use only one thread thus casing sequential decoding of
>> modes in dual mode as before. This is done by defining the environment
>> variable OMP_THREAD_LIMIT=1, doing this could increase the overall
>> decoding elapsed time by up to 100% and will always delay the non-Tx
>> mode decodes.
>>
>> Also introduced in this change is a higher "patience" value for the
>> FFTW3 FTT plans, this means that the very first time a decode is
>> initiated from the jt9 program or WSJT-X a considerable time will elapse
>> while FFTW optimizes the FFT plans for your hardware. This could take
>> several minutes, don't assume WSJT-X is hanging, let it finish otherwise
>> it will have to do it all over again the next time you start WSJT-X.
>>
>> This higher optimization level only gives a small performance
>> improvement but apart from the initial calculations it costs nothing so
>> is probably worth the patience.
>>
>> 73
>> Bill
>> G4WJS.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
