On Wed, Oct 24, 2012 at 1:08 AM, d3fault <d3faultdot...@gmail.com> wrote:
> On 10/23/12, Alan Ezust <alan.ez...@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?
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest