[Interest] Heavily Commented Example: Simple Single Frontend with Two Backends

[Alan Ezust]

On Wed, Oct 24, 2012 at 1:08 AM, d3fault <d3faultdotxbe at gmail.com> wrote:

> On 10/23/12, Alan Ezust <alan.ezust at gmail.com> wrote:
> >
> > http://www.ics.com/designpatterns is one place where you can see the
> book's
> > contents and download the code examples. It requires you to
> register/login
> > but it's free.
> >
>
> Which example are you referring to? Life or PrimeThreads? I read the
> whole chapter on QThreads and QtConcurrent...
>

PrimeThreads is the example that is rewritten using QThread and also
QtConcurrent.


>
> I stopped reading Life's source when you called
> QtConcurrent::blockingMappedReduced from the main window class (these
> aren't the designs I'm looking for).
>

The duration of each call to blockingMappedReduced is not very long in that
example.
The main point of that example is to show a puzzle that can take advantage
of a map/reduce.


> I am pretty sure the reason your QtConcurrent version of PrimeThreads
> is significantly faster than the QThread version is because:
> a) QtConcurrent pre-generates the list of numbers to check against ahead
> of time
> b) The QThread version QMutex-grabs the next number each time
> c) Generating prime numbers scales horizontally... though I guess your
> for loop generating QThreads should too... so maybe (c) shouldn't be
> here
>

There are LOTS of reasons why PrimeThreads is slower when it manages its
own threads and
creates mutexes.   You listed some of them there, I listed others in my
book.

But the time to generate the list of numbers (a) is also being taken into
account in the measurements.


>
> I'm inclined to believe that QtConcurrent::filter() uses something
> similar to QMutex behind the scenes... but maybe not? Maybe
> QtConcurrent::filter() is more optimized while still providing similar
> functionality (without using QMutex specifically)? I don't know how
> it's implemented. However the tests already don't seem fair.
>

"fair"? I don't know how i could possibly make it "fair" when the
qtconcurrent one removes the need
for QMutex.


>
> For the example I'm creating I am not demonstrating resource sharing
> so I'm not going to use QMutex anywhere...


You were using volatile in your example when you should have been using
something higher-level such as
an atomicInt or a mutex.



> and I can't determine a
> reason that a single long running (non-horizontally-scaling) backend
> would benefit from using QtConcurrent (especially since with
> QtConcurrent it will just be 1 QThread pulled out of a QThreadPool
> anyways, right?).
>


Then you can probably do it all with only one thread and an event loop.
Why do you need another thread at all then?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121024/05e90a62/attachment.html>