- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
currently I met a performance problem of a DMIP class,
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.
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.
1 Solution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page