I removed all the flush(6) except the one in decoder.f90. There was an
unprotected one in jt9c.f90 which may explain the long runtimes I see
one-in-a-great while on my Windows 10 system. Last long runtime was 7
seconds using 2 threads before I removed the flushes.
I am now running a loop test to
Doing the same 20-pass run on my Windows 10 HP Envy with i7-4702MQ @ 2.2Ghz
(compare to the dual X5450 4-core CPU at 3Ghz) -- you can see Ghz doesn't
tell the whole story...
With 2 threads on Windows 10 I see a long run once in a great while.
Thread 1 2 %Diff
49300.790.82-
: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X Decoder Performance
On 04/02/2015 15:27, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> OK, by all means go ahead.
>
> BTW: I notice that jt9_omp.exe r4929 always runs with 4 threads on my
> 4-core machine. Since we h
Did a 20-pass run on the last two versions of interest - I have a dual
4-Core CPU so apparently would have 8 threads available on 4928 cut to 2
threads on 4930. So an ever so slight improvement with 1 thread..2 threads
got worse though but they were already worse to start with.
Col1 = TimeMem-1.0
On 04/02/2015 15:27, Joe Taylor wrote:
> Hi Bill,
Hi Joe,
>
> OK, by all means go ahead.
>
> BTW: I notice that jt9_omp.exe r4929 always runs with 4 threads on my
> 4-core machine. Since we have only two tasks running in parallal, I can
> see little reason to use more than 2 threads. Should we sp
Hi Bill,
OK, by all means go ahead.
BTW: I notice that jt9_omp.exe r4929 always runs with 4 threads on my
4-core machine. Since we have only two tasks running in parallal, I can
see little reason to use more than 2 threads. Should we specify two
threads explicitly?
-- Joe
On 2/4/20
On 04/02/2015 15:21, Joe Taylor wrote:
> Hi Bill and all,
Hi Joe,
> Note that decoder.f90 now decodes the two modes in parallel sections
> *ONLY* if txmode is JT9. I will fix this.
Joe, I already have this in hand, I can check it in if you wish.
> -- Joe
73
Bill
G4WJS.
-
Hi Bill and all,
Tests here suggest that r4929 produces a Windows jt9_omp.exe that runs
correctly. At least, it runs to completion on my sequence of 25 test
files -- which r4928 does not.
Timing results on a 4-core Win7 machine:
Params jt9 jt9_omp
--
-w 2 -m 1
Doing some testing on the 4928 jt9_omp on my Windows 10 box using command
line test. I'm getting periodic long runs of 40-100 seconds...kind of like
it's running wisdom again or such.
There are a lot more page faults when that happens too.
I haven't see this behavior on Windows 7 yet.
Mike W9MD
Just tested 4928 on Windows 7...jt9_omp would not finish running in 4926.
Runs fine nowa 20% improvement on a Dual CPU quad core 3Ghz Intel X5450
Also tested on my Windows 10 machine but the runtime on jt9_omp was very
unstable taking anywhere from .8 seconds to 8 or so seconds.
TimeMem-1.0.ex
On 04/02/2015 13:37, Joe Taylor wrote:
> Hi Claude,
Hi Claude & Joe,
>
> Thanks for your timing report.
>
> Your first test may have used the correct executables, too. To get a
> good test you must run a configuration at least twice. In the first
> run, the program accumulates "wisdom" about the
Hi Claude,
Thanks for your timing report.
Your first test may have used the correct executables, too. To get a
good test you must run a configuration at least twice. In the first
run, the program accumulates "wisdom" about the best way to configure
the FFT calculations. This wisdom is saved
On 02/04/2015 08:42 AM, Claude Frantz wrote:
> Please see here the result I have got with SVNVERSION 4928.
I'm very sorry, I have used the wrong executables. Here the right output
now:
$ time ./jt9 -p 1 -d 3 -w 2 -m 1
/home/claude/.wsjtx/bin/save/samples/130610_2343.wav
2343 -9 0.3 3196 @ WB
Please see here the result I have got with SVNVERSION 4928.
I have suppressed the "-m" flag because the software rejects it.
Best 88 de Claude
$ time ./jt9 -p 1 -d 3 -w 2 -e .
/home/claude/.wsjtx/bin/save/samples/130610_2343.wav
2343 -7 0.3 3196 @ WB8QPG IZ0MIT -11
2343 -16 1.0 3372 @ KK4
On 03/02/2015 22:25, Michael Black wrote:
Hi Mike and anyone else interested in the issues of multi-threaded
programming,
Below is a version of Mike's example Fortran code. I have updated it to
Fortran 90 and rather than just suggesting potential fixes, I have
actually tested the code as well ;
A(I) + B(I)
> !$OMP CRITICAL(io)
> WRITE(*,100) TID,I,C(I)
> !$OMP END CRITICAL(io)
> 100FORMAT(' Thread',I2,': C(',I3,')=',F8.2)
>ENDDO
> !$OMP END DO NOWAIT
!$omp critical(io)
> PRINT *, 'Thread',TID,'
>> C(I) = A(I) + B(I)
>> !$OMP CRITICAL(io)
>> WRITE(*,100) TID,I,C(I)
>> !$OMP END CRITICAL(io)
>>100FORMAT(' Thread',I2,': C(',I3,')=',F8.2)
>> ENDDO
>> !$OMP END DO NOWAIT
> !$omp
io)
> 100FORMAT(' Thread',I2,': C(',I3,')=',F8.2)
>ENDDO
> !$OMP END DO NOWAIT
!$omp critical(io)
>PRINT *, 'Thread',TID,' done.
!$omp end critical(io)
>
> !$OMP END PARALLEL
>
>END
>
> -Origi
one.'
!$OMP END PARALLEL
END
-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Tuesday, February 03, 2015 4:10 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X Decoder Performance
On 03/02/2015 21:48, Michael Black wrote:
Hi Mik
(dynamic,chunk)
>for (i=0; i {
> c[i] = a[i] + b[i];
> printf("Thread %d: c[%d]= %f\n",tid,i,c[i]);
> }
>
>} /* end of parallel section */
>
> }
>
>
>
>
>
> -----Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
NOWAIT
>
>PRINT *, 'Thread',TID,' done.'
>
> !$OMP END PARALLEL
>
>END
>
> Mike W9MDB
>
> -Original Message-
> From: Bill Somerville [mailto:g4...@classdesign.com]
> Sent: Tuesday, February 03, 2015 3:17 PM
> To: wsjt-d
Hi Bill,
Thanks for the explanation. I was looking for the CMake module OpenMP,
didn't realize it was the different find module.
It seems to be working here ( JTSDK v2 & Cmake 3.0.2 ):
--
-- Try OpenMP C flag = [-fopenmp]
-- Performing Test OpenMP_FLAG_DETECTED
-- Performing Test OpenMP_FLAG_D
rting...\n",tid);
#pragma omp for schedule(dynamic,chunk)
for (i=0; imailto:g4...@classdesign.com]
Sent: Tuesday, February 03, 2015 3:17 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X Decoder Performance
On 03/02/2015 21:04, Joe Taylor wrote:
> Hi Greg,
27;
!$OMP END PARALLEL
END
Mike W9MDB
-Original Message-
From: Bill Somerville [mailto:g4...@classdesign.com]
Sent: Tuesday, February 03, 2015 3:17 PM
To: wsjt-devel@lists.sourceforge.net
Subject: Re: [wsjt-devel] WSJT-X Decoder Performance
On 03/02/2015 21:04, Joe Taylor wrote:
> Hi Gr
On 03/02/2015 21:04, Joe Taylor wrote:
> Hi Greg,
Hi Greg & Joe,
>
> Yes, we need the "-fopenmp" flag to be set. I think that's being done
> appropriately now in CMakeLists.txt, although I confess I'm not always
> confident that I've understood its syntax fully. Bill should be able to
> give the
HI Joe,
Bill may be still working on this. I couldn't' find several things
including the "-fopenmp" flag, so I'll just wait and see what shakes out.
73's
Greg, KI7MT
On 2/3/2015 2:04 PM, Joe Taylor wrote:
> Hi Greg,
>
> Yes, we need the "-fopenmp" flag to be set. I think that's being done
> ap
Hi Greg,
Yes, we need the "-fopenmp" flag to be set. I think that's being done
appropriately now in CMakeLists.txt, although I confess I'm not always
confident that I've understood its syntax fully. Bill should be able to
give the definitive answer.
-- Joe
On 2/3/2015 3:36 PM, ki...
Hi Joe,
I'm not 100% certain on this, but for openmp on Windows, don't you have
to enable that as a C flag with something l-ke: -fopenmp
I would assume that's to be done in the CMakeLists.txt file. I'm not
sure about linking the libraries.
The Qt5 Tool chain has winpthreads and gcc -v has --en
On 03/02/2015 20:06, Joe Taylor wrote:
> Hi Bill and all,
Hi Joe,
>
> Perhaps you already tried jt9_omp in Linux, but I had not. I tried it
> today, and it seems to work OK, as is.
There are definitely thread safety issues but I think I have most of
them dealt with. I will commit them soon after
Hi Bill and all,
Perhaps you already tried jt9_omp in Linux, but I had not. I tried it
today, and it seems to work OK, as is.
Here are some timing tests made on my rather elderly 2-core Linux
machine. This time all tests were made with the "Deepest" setting,
ndepth=3, and all resulted in 17
Dear Colleagues,
I have made some further performance tests of the decoders in WSJT-X.
I copied a collection of 25 *.wav files into a clean directory. The
files wererecorded in *JT9+JT65* mode during a busy period of activity
on 20 meters. On average, around a dozen decodable signals are pres
On 02/02/2015 19:45, Joe Taylor wrote:
> Hi all,
>
> I have made further improvements to the speed of the decoders in WSJT-X,
> independently of any recourse to concurrent processing in machines with
> multiple CPUs.
>
> These measurements were made on a Windows 7 machine with 4-core i5-2500 CPU.
On 02/02/2015 08:45 PM, Joe Taylor wrote:
> The following table presents measurements of decoding speed for a number
> of tests using WSJT-X versions 1.3, 1.4.0-rc2, 1.5r4925, and 1.5r4926.
> "Time" gives the time is seconds to decode the sample file
> 130610_2343.wav, which has 8 decodable JT9 si
1JT
>
> On Mon, 2/2/15, Joe Taylor wrote:
>
> Subject: [wsjt-devel] WSJT-X Decoder Performance
> To: wsjt-devel@lists.sourceforge.net
> Date: Monday, February 2, 2015, 11:45 AM
>
> Hi all,
>
> I have made further improvements to the sp
Can one download an executable with these changes?
On Mon, 2/2/15, Joe Taylor wrote:
Subject: [wsjt-devel] WSJT-X Decoder Performance
To: wsjt-devel@lists.sourceforge.net
Date: Monday, February 2, 2015, 11:45 AM
Hi all,
I have made further
I should have mentioned that if you're especially interested in snappy
performance of the JT9 decoder, you may consider the penalty for using
menu setting "Decode | Fast" to be unimportant. It will cost you
nothing at all at the QSO frequency: that first decoding attempt is
always done at "Dee
Hi all,
I have made further improvements to the speed of the decoders in WSJT-X,
independently of any recourse to concurrent processing in machines with
multiple CPUs. The changes involve
1. Making better choices for NFFT1 and NFFT2 (the lengths of forward and
inverse FFTs in the JT9 downsamp
37 matches
Mail list logo
