Re: [wsjt-devel] Threading

2014-10-17 Thread Bill Somerville

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

2014-10-17 Thread Joe Taylor
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

2014-10-17 Thread Bill Somerville
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

2014-10-17 Thread Michael Black
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

2014-10-17 Thread Bill Somerville
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


 --
 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

Re: [wsjt-devel] Threading

2014-10-17 Thread Joe Taylor


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