Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.

the correct way to use DMIP

Lamp
Beginner
784 Views
Hi,

currently I met a performance problem of a DMIP class,
[cpp]class DmipHelper { void Calc() { Graph graph; .... graph.Compile(); graph.Execute(); } }[/cpp]

I have been told that "in DMIP we do not support nested parallelism", so I have to add monitor in order to call it in a multi-threading environment,

void SomeMethod()
{
Monitor::Enter(someLock);
helper->Calc();
Monitor::Exit(someLock);
}

if there are two threads calling this method, one have to wait until the other exit the lock, it looks very ugly and i do not see any benifits for DMIP if work like this.

Please provide me some sample that use DMIP in a correct way.
0 Kudos
1 Solution
Igor_B_Intel1
Employee
784 Views
Hi,
Unfortunatly to find a solution of your problem need to analyze whole architecture of your app. If I remember correctly you have got some number of your own threads and they do some similar calculations with DMIP butDMIP is designed toutilize allarch resources.
It seems to me that some global app pipeline reorganization may help. I don't know what can help exactly but it can be something like that: merging DMIP graphes or create DMIP task queue or maybe just limit number of DMIP threads to save resources for your own task.
Based on your example I may guess you may waste a time in Monitor::Enter because it can significatly increase percentage of serial code in your app: one thread works but other just wait it. So simple solution doesn't help.

Igor S. Belyakov

View solution in original post

0 Kudos
4 Replies
Igor_B_Intel1
Employee
785 Views
Hi,
Unfortunatly to find a solution of your problem need to analyze whole architecture of your app. If I remember correctly you have got some number of your own threads and they do some similar calculations with DMIP butDMIP is designed toutilize allarch resources.
It seems to me that some global app pipeline reorganization may help. I don't know what can help exactly but it can be something like that: merging DMIP graphes or create DMIP task queue or maybe just limit number of DMIP threads to save resources for your own task.
Based on your example I may guess you may waste a time in Monitor::Enter because it can significatly increase percentage of serial code in your app: one thread works but other just wait it. So simple solution doesn't help.

Igor S. Belyakov
0 Kudos
Lamp
Beginner
784 Views
Thanks Igor,

Yes we got a bad performance since two threads using the method, from the log, something looks like:

Thread1 enter DMIP
Thread1 exit DMIP
Thread2 enter DMIP
Thread2 exit DMIP
Thread1 enter DMIP
Thread1 exit DMIP
Thread2 enter DMIP
Thread2 exit DMIP

CPU wasting time on switching between threads, I think create a DMIP task queue is a good idea.

Regards
0 Kudos
Sergey_K_Intel
Employee
784 Views
Hi xiehuanxie,

May I ask you a question? What threading technique do you use?

I am asking this because if an application uses direct threading control (via thread API on Windows, or pthreads on Linux) it is quite hard for DMIP (or, any other threaded library) to avoid oversubscription, when number of application's active threads exceed the number of logical CPUs. There must be an application-wise threading control logic.

Regards.
Sergey
0 Kudos
Lamp
Beginner
784 Views
Hi,

We are using thread pool from .NET, currently seems there is not problem even invokes DMIP in athreadfor thousands times;

anyway two threads cannot access DMIP at the same time, DMIP taskqueue may make our application more complex, so i'm going torewrite our code to use normal IPP method instead of DMIP.

Regards,
Xie
0 Kudos
Reply