Qt

[uj]

Nokia has acquired Qt and open sourced it. Nokia is a big mobile phone maker and Qt is a C++ portable-GUI package.

http://www.qtsoftware.com/

Are there any known issues or problemsusingTBB with Qt?

Thank you.

[robert-reed]

Quoting - uj

Nokia has acquired Qt and open sourced it. Nokia is a big mobile phone maker and Qt is a C++ portable-GUI package.

http://www.qtsoftware.com/

Are there any known issues or problemsusingTBB with Qt?

I know of companies that have successfully employed both libraries in an application but combining them should be done with care. In a case I'm thinking of, adding Qt shifted resource use around sufficiently to cause substantial contention on a heretofore lightly contended lock, requiring a bit of redesign to avoid that condition. But keeping TBB out of the line of fire of the event interface should be a good start towards making them play nice together.

[uj]

Quoting - Robert Reed (Intel)

I know of companies that have successfully employed both libraries in an application but combining them should be done with care. In a case I'm thinking of, adding Qt shifted resource use around sufficiently to cause substantial contention on a heretofore lightly contended lock, requiring a bit of redesign to avoid that condition. But keeping TBB out of the line of fire of the event interface should be a good start towards making them play nice together.

Yes I have a feeling there could be conflicts in applications where TBB is not alone, but is competing with other modulesthat do their own multithreading. Thiscould be the case inthe TBB & Qt combination I was asking about for example.

I guessthis is ageneral problem that has to be investigated and worked out in each individual case. A precaution of course would be to limit TBB to be used only locally(everywhere there's an algorithm that would especiallybenefit from being run in parallel). But maybe that's too defensive because thenone may miss out on global load balancing?

I guess it's best to use TBB as globally as possible throughout an application but then again it's hard too foresee possible conflicts with competing modules. Which is the best strategy here? Is there sometool that can be used?

[robert-reed]

Quoting - uj

Yes I have a feeling there could be conflicts in applications where TBB is not alone, but is competing with other modulesthat do their own multithreading. Thiscould be the case inthe TBB & Qt combination I was asking about for example.

I guessthis is ageneral problem that has to be investigated and worked out in each individual case. A precaution of course would be to limit TBB to be used only locally(everywhere there's an algorithm that would especiallybenefit from being run in parallel). But maybe that's too defensive because thenone may miss out on global load balancing?

I guess it's best to use TBB as globally as possible throughout an application but then again it's hard too foresee possible conflicts with competing modules. Which is the best strategy here? Is there sometool that can be used?

Well the eventual solution is to treat threads and their communications mechanisms as a common resource, shared by all applications and the libraries they use, much like Intel has promoted in collaborating with other OpenMP vendors to provide a common OpenMP library to be shared regardless of which OpenMP front end is being used, which is dependent on the compiler used. Microsoft has suggested some directions they are considering for their next Visual Studio release and Intel is paying close attention. Maybe someday the Qts and TBBs of the world will all be in one big happy family, sharing common thread pools and cooperating in a fashion unimaginable today. Or maybe we'll just muddle about like we have for the last twenty years ;-).

[uj]

Quoting - Robert Reed (Intel)

Well the eventual solution is to treat threads and their communications mechanisms as a common resource, shared by all applications and the libraries they use, much like Intel has promoted in collaborating with other OpenMP vendors to provide a common OpenMP library to be shared regardless of which OpenMP front end is being used, which is dependent on the compiler used. Microsoft has suggested some directions they are considering for their next Visual Studio release and Intel is paying close attention. Maybe someday the Qts and TBBs of the world will all be in one big happy family, sharing common thread pools and cooperating in a fashion unimaginable today. Or maybe we'll just muddle about like we have for the last twenty years ;-).

Thank you.Justknowing that this is a problem indeed helps; and thatone gets the best result, or at least the fewest complications, if TBBrules the roost alone.

I guesslanguages with built-in multithreading, like Java, has an advantage.Fortunately C++finally seems tobe addressing multithreadingin the upcoming standard,

http://www.devx.com/SpecialReports/Article/38883

Willthis be enougth tosortthis problem out, or is it at leasta first step in the right direction?

[adunsmoor]

I don't think the language necessarily helps or hinders the solving the oversubscription problem. C++ and Java will have similar challenges .

As an application developer you typically try to find the "right" number of threads to allocate to get the best performance. TBB creates a pool of threads on initialization (typically) based on what it calculates to be the best number to fully utilize the processors without creating contention.

As you mentioned, when mixed with another framework that "right" number for the application might not be quite right since the other framework might also allocate its own threads. If you can know ahead of time that the other frameworks threads will typically be used then you can probably account for that when you initialize TBB.

I think what Mr. Reed alludes to is a more general problem that occurs when more and more applications become thread enabled (or you try to run many instances of your newly created threaded app). Now all of the applications are trying to use all of the processors all of the time. What is the "right" number of threads to create on startup in this case?

Quoting - Robert Reed (Intel)

Well the eventual solution is to treat threads and their communications mechanisms as a common resource, shared by all applications and the libraries they use, much like Intel has promoted in collaborating with other OpenMP vendors to provide a common OpenMP library to be shared regardless of which OpenMP front end is being used, which is dependent on the compiler used. Microsoft has suggested some directions they are considering for their next Visual Studio release and Intel is paying close attention. Maybe someday the Qts and TBBs of the world will all be in one big happy family, sharing common thread pools and cooperating in a fashion unimaginable today. Or maybe we'll just muddle about like we have for the last twenty years ;-).

For what it's worth, Apple has also proposed a model for sharing threading resources across applications in their upcoming OS X release. It would be interesting to hear Intel's position on this framework and whether TBB might one day integrate with it or perhaps support something similar on other platforms.

http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf

"Grand Central Dispatch is a revolutionary, pervasive approach to multicore processing. GCD shifts the responsibility for managing threads and their execution from applications to the operating system. Mac OS X Snow Leopard provides APIs for GCD throughout the system, and uses a highly scalable and efficient runtime mechanism to process work from applications. As a result, programmers can write less code to deal with concurrent operations in their applications, and the system can perform more efficiently."

I think we'll see a lot of interesting progress in the next few years in the state of the art for developing multi threaded applications.

[robert-reed]

Quoting - adunsmoor

For what it's worth, Apple has also proposed a model for sharing threading resources across applications in their upcoming OS X release. It would be interesting to hear Intel's position on this framework and whether TBB might one day integrate with it or perhaps support something similar on other platforms.

http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf

"Grand Central Dispatch is a revolutionary, pervasive approach to multicore processing. GCD shifts the responsibility for managing threads and their execution from applications to the operating system. Mac OS X Snow Leopard provides APIs for GCD throughout the system, and uses a highly scalable and efficient runtime mechanism to process work from applications. As a result, programmers can write less code to deal with concurrent operations in their applications, and the system can perform more efficiently."

I think we'll see a lot of interesting progress in the next few years in the state of the art for developing multi threaded applications.

Intel's James Reinders has a few words to say here about TBB and Grand Central Dispatch.