On 04/02/2015 21:49, Michael Black wrote: Hi Mike, > So does this also mean if you don't check the Flatten box that your decodes > would be slower since it does the flatten later if the GUi doesn't do it? > Or is always being done anyways...just not for display unless checked? That's above my pay grade at the moment :( > What does this if check look for in jt9.f90 > if(nhsym.ge.1 .and. nhsym.ne.nhsym0) then That code is calling symspec for each symbol sized chunk (or is that half symbol sized) which is similar to what the happens in the GUI. The audio input thread sends the audio received in chunks to accumulate the symbol spectra and to drive the waterfall and RX meter.
Note that the GUI path to the decoder is back up at the call to jt9a, this code is command line jt9 only. > > > BTW..running this now and it seems like decodes are screaming by > comparatively....good job guys... It's going to be painful to going back to crunching CAT issues after this brief period of big improvements :( > > Mike W9MDB 73 Bill G4WJS. > > -----Original Message----- > From: Joe Taylor [mailto:j...@princeton.edu] > Sent: Wednesday, February 04, 2015 3:21 PM > To: WSJT software development > Subject: Re: [wsjt-devel] r4932 > > Hi Mike, > > The change was to replace "slope", a currently undefined, vestigial remnant > of some old code, to "nflatten" -- the correct argument to pass > to symspec. The variable "slope" was undefined in jt9.f90. Inside > symspec, its value supposedly controlled whether the spectrum being computed > for the waterfall would be flattened, or not. Since the variable was > undefined, it might sometimes be zero, sometimes nonzero. > Not a good situation if we're trying to make comparative timing tests. > > Perhaps you will like it better to set nflatten=0 in jt9.f90. That will > make jt9 or jt9_omp run faster from the command line, especially since > "flat3" is kinda slow. But if you normally check the "Flatten" box in the > GUI, your decoding results may not be exactly the same. > > In normal operation the timing difference is moot, because the extra work > takes place during the Rx minute rather than at its end. It's for the > CPU-bound stuff at the end of the Rx minute that I have been speeding things > up. > > Perhaps I should look at "flat3", to see why it's so slow -- even though its > slow behavior has essentially no effect noticeable to an operator. > > -- Joe > > On 2/4/2015 3:45 PM, Michael Black wrote: >> The change on jt9.for replacing nflatten with slope really made >> processing times much worse. >> >> Mainwindow.cpp is using nflatten.so I don't quite understand the log >> comment about making them consistent. >> >> >> >> On my testing jt9_omp went from 1.12 to 1.81 seconds. >> >> >> >> Mike W9MDB >> >> >> >> >> >> ---------------------------------------------------------------------- >> -------- 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 >> wsjt-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wsjt-devel > ---------------------------------------------------------------------------- > -- > 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 > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > ------------------------------------------------------------------------------ > 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 > wsjt-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wsjt-devel ------------------------------------------------------------------------------ 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
