5 Oct
2002
5 Oct
'02
8:21 a.m.
On Saturday 05 October 2002 11.01, you wrote:
On Saturday 05 October 2002 10.51, you wrote:
Uhh... it seems to be totally unrelated to anything... just some
spurious cache problem, sometimes, if the code is executed in a
particular order, the memory layout is beneficial, sometimes it is not.
dlopen seems to have nothing to do with it. I just have to live with
it...
/Anders Torger
On Sat, Oct 05, 2002 at 09:12:31 +0200, Anders
Torger wrote:
Yes, it probably is in some way (to my knowledge, this only occurs
when I have quite large blocks to process), however, the task and
data is the same for both cases, the difference is that some
unrelated code has been run in a dlopen'd module before it. The
work-around I'm doing now is to fork the convolution process early,
before any dlopen stuff, it makes the initialisation much more
cumbersome, but the performance problem goes away. Although I have disabled the use of the
dlopen()'d modules (for
debugging this problem), running the init code in the beginning
causes the convolution loop to take 109ms instead of 62ms.
Just a guess, but it could be cache related. I've had exteme
performance changes when things end up just fitting in the cache or
just not.