p********g
发帖数: 8855 | 1 我有一部分code，做成了dll
现在使用的是隐式调用方式调用这个dll
如果调用dll，发现速度要比直接run code 要慢？
这个正常么？ 大概慢0.5秒
这个code需要openmp的支持。多谢 |
c*********e
发帖数: 16335 | 2 不就是个library吗，你调用一些references也是用的dll阿。
【在 p********g 的大作中提到】
: 我有一部分code，做成了dll
: 现在使用的是隐式调用方式调用这个dll
: 如果调用dll，发现速度要比直接run code 要慢？
: 这个正常么？ 大概慢0.5秒
: 这个code需要openmp的支持。多谢
|
p********g
发帖数: 8855 | 3 嗯。。自己编译的一个library
但是不清楚其中到底哪里出了问题，要慢半秒种
对openmp支持不好？
【在 c*********e 的大作中提到】
: 不就是个library吗，你调用一些references也是用的dll阿。
|
k**********g
发帖数: 989 | 4
Step into the disassembly. Or use a CPU instruction profiler like AMD
CodeAnalyst or Intel VTune.
If this 0.5 second delay only occurs on the first call after application
launch, I think this is an inevitable cost for using OpenMP. If it happens
on every call then there is a need to investigate.
With the debugger attached, check how many OpenMP threads are created. Also
make sure the EXE and DLL are linking against the correct OpenMP library.
【在 p********g 的大作中提到】
: 嗯。。自己编译的一个library
: 但是不清楚其中到底哪里出了问题，要慢半秒种
: 对openmp支持不好？
|
k**********g
发帖数: 989 | 5 What I mean by checking that they're both linked to the correct OpenMP
library.
http://stackoverflow.com/questions/18572237/multiple-intel-open
Incorrect linking means that both the application and the DLL allocate their
own thread pools, and both try to keep their threads busy - thus competing
for CPU time. |
