On 07/02/2015 16:56, Claude Frantz wrote: > On 02/07/2015 01:03 PM, Bill Somerville wrote: > >> The current situation as far as I am concerned is that we need to make a >> decision whether to go ahead with using OpenMP to get parallelism in >> WSJT-X. If we decide "yes" then the CMake script will build jt9 with >> OpenMP on platforms that have a tool chain available that supports >> OpenMP, this is a trivial change and jt9_omp will just disappear. Having >> an option is not really viable as it is not something you can turn on >> and off effectively, >> IMHO single CPU processors are history > Hi Bill, Hi Claude, > > Single CPU processors are history, but they are recent history. Windows > XP is history but it is still used at many stations. The problem with > the Mac is a today's reality. The increased performance of OMP is, IMHO, > rather marginal. I disagree. For example the JT65 decoder and the JT9 decoder are pretty much independent and there is virtually no contention between them. This means that they can be run in parallel on two CPUs with little or no overhead for distributing them across the two CPUs. That means that give equal amounts of work it is possible to deliver the decoding results in almost half the time compared to running them sequentially.
Perhaps more importantly the decoders both decode the "low hanging fruit" quickly so, working in parallel, the first decodes from both modes are nearly instantaneous whereas when working sequentially the quick decodes from the other mode are not delivered until the first mode has exhausted its search for ever more difficult decode opportunities. This is exactly the strategy that has been implemented by using OpenMP in jt9. > > Perhaps that the situation will change if better algorithms, allowing a > more deep decoding of weak signals will come into the game. These changes already achieve that use case, for example a user who could not use "Deepest" decode mode on the JT9 decoder because it delayed JT65 decodes too much will now be able to leave "Deepest" set because the JT65 decodes will be delivered even while the JT9 decoder struggles to find those weak hard to decode messages that before were delaying the delivery of all JT65 messages before. This statement does have a caveat in that the OpenMP parallel decoding only happens if more that one CPU thread is available which of course is very relevant because the uni-processor user is also likely to be the user that has decodes that are too slow in JT9 "Deepest" mode :( > > Just my own opinion... > > Best 88 de Claude 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 wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
