Re: [wsjt-devel] Threading
On 16/10/2014 21:12, Michael Black wrote: Hi Mike, Has any thought or attempt been given to multi-threading the decoding process? The decoding is almost exclusively Fortran code. Multi threading isn't really the way Fortran code is parallelized (is that a word?), normally a special compiler is used that can execute some array operations in parallel or a support library like OpenMP is used. Whatever the route chosen it isn't trivial as sequential code usually needs considerable rewriting to take advantage of either the facilities above. Mike W9MDB 73 Bill G4WJS. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Threading
Hi Mike, On 10/16/2014 4:12 PM, Michael Black wrote: > Has any thought or attempt been given to multi-threading the decoding > process? To what end? Are you concerned about decoding speed? Have you looked at the statistics in file 'timer.out', results from the built-in execution profiler for jt9.exe ? -- Joe, K1JT -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Threading
Well..yeah...speed..I would expect the "decode" phase to max out CPU until all decodes are done...hate to see idle electrons. I'm a speed freak. It doesn't appear to use 100% CPU (of even one core). Though I'm waiting for a really busy band to really see what it does. One thing I'm testing is I've removed the flush from decoder.f90 as being totally unnecessary (isn't it??) since there's a flush after the loop. --- decoder.f90 (revision 4198) +++ decoder.f90 (working copy) @@ -168,7 +168,7 @@ ndecoded=1 ccfok(iaa:ibb)=.false. done(iaa:ibb)=.true. - call flush(6) +! call flush(6) endif endif enddo Mike W9MDB -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Friday, October 17, 2014 11:03 AM To: WSJT software development Subject: Re: [wsjt-devel] Threading Hi Mike, On 10/16/2014 4:12 PM, Michael Black wrote: > Has any thought or attempt been given to multi-threading the decoding > process? To what end? Are you concerned about decoding speed? Have you looked at the statistics in file 'timer.out', results from the built-in execution profiler for jt9.exe ? -- Joe, K1JT -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Threading
Mike -- As a speed freak, you should pay attention to what timer.out can tell you. As for the "call flush(6)" at line 171 of decoder.f90: it's there (inside the loop) so that the GUI will display each decode immediately, when it occurs, rather than when the loop is finished. If you remove that call to flush, the O/S may decide to give you a list of decodes all at once, at the end of the loop. -- Joe, K1JT On 10/17/2014 12:28 PM, Michael Black wrote: > Well..yeah...speed..I would expect the "decode" phase to max out CPU until > all decodes are done...hate to see idle electrons. I'm a speed freak. > It doesn't appear to use 100% CPU (of even one core). Though I'm waiting > for a really busy band to really see what it does. > One thing I'm testing is I've removed the flush from decoder.f90 as being > totally unnecessary (isn't it??) since there's a flush after the loop. > > --- decoder.f90 (revision 4198) > +++ decoder.f90 (working copy) > @@ -168,7 +168,7 @@ > ndecoded=1 > ccfok(iaa:ibb)=.false. > done(iaa:ibb)=.true. > - call flush(6) > +! call flush(6) > endif > endif >enddo > > > Mike W9MDB > > -Original Message- > From: Joe Taylor [mailto:j...@princeton.edu] > Sent: Friday, October 17, 2014 11:03 AM > To: WSJT software development > Subject: Re: [wsjt-devel] Threading > > Hi Mike, > > On 10/16/2014 4:12 PM, Michael Black wrote: >> Has any thought or attempt been given to multi-threading the decoding >> process? > > To what end? Are you concerned about decoding speed? Have you looked at > the statistics in file 'timer.out', results from the built-in execution > profiler for jt9.exe ? > > -- Joe, K1JT > > > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Threading
On 17/10/2014 17:54, Joe Taylor wrote: > Mike -- > > As a speed freak, you should pay attention to what timer.out can tell you. > > As for the "call flush(6)" at line 171 of decoder.f90: it's there > (inside the loop) so that the GUI will display each decode immediately, > when it occurs, rather than when the loop is finished. If you remove > that call to flush, the O/S may decide to give you a list of decodes all > at once, at the end of the loop. Or to put it a different way, that flush is the current concurrency implementation as the jt9 and GUI processes run in parallel communicating via the console and shared memory. > > -- Joe, K1JT 73 Bill G4WJS. > > On 10/17/2014 12:28 PM, Michael Black wrote: >> Well..yeah...speed..I would expect the "decode" phase to max out CPU until >> all decodes are done...hate to see idle electrons. I'm a speed freak. >> It doesn't appear to use 100% CPU (of even one core). Though I'm waiting >> for a really busy band to really see what it does. >> One thing I'm testing is I've removed the flush from decoder.f90 as being >> totally unnecessary (isn't it??) since there's a flush after the loop. >> >> --- decoder.f90 (revision 4198) >> +++ decoder.f90 (working copy) >> @@ -168,7 +168,7 @@ >> ndecoded=1 >> ccfok(iaa:ibb)=.false. >> done(iaa:ibb)=.true. >> - call flush(6) >> +! call flush(6) >> endif >>endif >> enddo >> >> >> Mike W9MDB >> >> -Original Message- >> From: Joe Taylor [mailto:j...@princeton.edu] >> Sent: Friday, October 17, 2014 11:03 AM >> To: WSJT software development >> Subject: Re: [wsjt-devel] Threading >> >> Hi Mike, >> >> On 10/16/2014 4:12 PM, Michael Black wrote: >>> Has any thought or attempt been given to multi-threading the decoding >>> process? >> To what end? Are you concerned about decoding speed? Have you looked at >> the statistics in file 'timer.out', results from the built-in execution >> profiler for jt9.exe ? >> >> -- Joe, K1JT >> >> >> -- >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> >> >> -- >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Threading
Is showing up all at once a problem? At the moment the decodes show up quicker in WSJT-X than before. That flush could be adding 10's of MS per decode. JTAlert is also monitoring that file for changes so one flush seems like the best idea for it. Mike W9MDB -Original Message- From: Joe Taylor [mailto:j...@princeton.edu] Sent: Friday, October 17, 2014 11:55 AM To: WSJT software development Subject: Re: [wsjt-devel] Threading Mike -- As a speed freak, you should pay attention to what timer.out can tell you. As for the "call flush(6)" at line 171 of decoder.f90: it's there (inside the loop) so that the GUI will display each decode immediately, when it occurs, rather than when the loop is finished. If you remove that call to flush, the O/S may decide to give you a list of decodes all at once, at the end of the loop. -- Joe, K1JT On 10/17/2014 12:28 PM, Michael Black wrote: > Well..yeah...speed..I would expect the "decode" phase to max out CPU > until all decodes are done...hate to see idle electrons. I'm a speed freak. > It doesn't appear to use 100% CPU (of even one core). Though I'm > waiting for a really busy band to really see what it does. > One thing I'm testing is I've removed the flush from decoder.f90 as > being totally unnecessary (isn't it??) since there's a flush after the loop. > > --- decoder.f90 (revision 4198) > +++ decoder.f90 (working copy) > @@ -168,7 +168,7 @@ > ndecoded=1 > ccfok(iaa:ibb)=.false. > done(iaa:ibb)=.true. > - call flush(6) > +! call flush(6) > endif > endif >enddo > > > Mike W9MDB > > -Original Message- > From: Joe Taylor [mailto:j...@princeton.edu] > Sent: Friday, October 17, 2014 11:03 AM > To: WSJT software development > Subject: Re: [wsjt-devel] Threading > > Hi Mike, > > On 10/16/2014 4:12 PM, Michael Black wrote: >> Has any thought or attempt been given to multi-threading the decoding >> process? > > To what end? Are you concerned about decoding speed? Have you looked > at the statistics in file 'timer.out', results from the built-in > execution profiler for jt9.exe ? > > -- Joe, K1JT > > -- > -- > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
Re: [wsjt-devel] Threading
On 17/10/2014 17:59, Michael Black wrote: Hi Mike, > Is showing up all at once a problem? > At the moment the decodes show up quicker in WSJT-X than before. > That flush could be adding 10's of MS per decode. > JTAlert is also monitoring that file for changes so one flush seems like the > best idea for it. I believe your analysis is flawed, you are not considering that fact that decoding is prioritized with the current Rx DF being decode first, then the rest in the current mode and last the remainder in the other mode if dual mode is selected. With that included, an analysis should conclude that more concurrency may well decrease effective performance as it is likely to slow down the first pass which is almost always the only one that has a deadline associated with it i.e. starting or continuing a QSO. > Mike W9MDB 73 Bill G4WJS. > > -Original Message- > From: Joe Taylor [mailto:j...@princeton.edu] > Sent: Friday, October 17, 2014 11:55 AM > To: WSJT software development > Subject: Re: [wsjt-devel] Threading > > Mike -- > > As a speed freak, you should pay attention to what timer.out can tell you. > > As for the "call flush(6)" at line 171 of decoder.f90: it's there (inside > the loop) so that the GUI will display each decode immediately, when it > occurs, rather than when the loop is finished. If you remove that call to > flush, the O/S may decide to give you a list of decodes all at once, at the > end of the loop. > > -- Joe, K1JT > > On 10/17/2014 12:28 PM, Michael Black wrote: >> Well..yeah...speed..I would expect the "decode" phase to max out CPU >> until all decodes are done...hate to see idle electrons. I'm a speed > freak. >> It doesn't appear to use 100% CPU (of even one core). Though I'm >> waiting for a really busy band to really see what it does. >> One thing I'm testing is I've removed the flush from decoder.f90 as >> being totally unnecessary (isn't it??) since there's a flush after the > loop. >> --- decoder.f90 (revision 4198) >> +++ decoder.f90 (working copy) >> @@ -168,7 +168,7 @@ >> ndecoded=1 >> ccfok(iaa:ibb)=.false. >> done(iaa:ibb)=.true. >> - call flush(6) >> +! call flush(6) >> endif >> endif >> enddo >> >> >> Mike W9MDB >> >> -Original Message- >> From: Joe Taylor [mailto:j...@princeton.edu] >> Sent: Friday, October 17, 2014 11:03 AM >> To: WSJT software development >> Subject: Re: [wsjt-devel] Threading >> >> Hi Mike, >> >> On 10/16/2014 4:12 PM, Michael Black wrote: >>> Has any thought or attempt been given to multi-threading the decoding >>> process? >> To what end? Are you concerned about decoding speed? Have you looked >> at the statistics in file 'timer.out', results from the built-in >> execution profiler for jt9.exe ? >> >> -- Joe, K1JT >> >> -- >> -- >> -- >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel >> >> >> -- >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> ___ >> wsjt-devel mailing list >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > ___ > wsjt-devel mailing list > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > -
Re: [wsjt-devel] Threading
On 10/17/2014 12:59 PM, Michael Black wrote: > Is showing up all at once a problem? None of this is a problem, as far as I'm aware. Is showing up all at once undesirable? Yes, if that means that the first decode shows up later than it otherwise would have. The first decode is always the one at your selected Rx frequency. That's the station you're working, and you want to see his message as soon as possible. > That flush could be adding 10's of MS per decode. I think a test will show you that this estimate is orders-of-magnitude too large. -- Joe -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho ___ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
