I have a function that takes between 40ms and a second, depending on the
state of the program at any one time. This I expect. As such, I wanted to
put it in a thread such that it can be teamed with a faster but less robust
algorithm, and also so that I could get reasonable response from the
keyboard (rather than holding down q for a second or two before it realises
I want to stop…)
What I have found however, is that when threaded, the function’s speed is
intermitant. The change in speed should be gradual as it adapts to what it
is doing - it shouldn’t suddenly shift from 50ms up to 300ms (as the
program state can not change to that extent between iterations).
Any suggestions as to why it should have this problem? Any solutions?
(the thread doesn’t share much with what is beneath it. merely a boolean
that pauses activity, and another that quits, which are set by the main
program thread).
The function in question is used for locating and tracking objects in video,
the speed difference occurs due to its nature - it doesn’t have to search
so much when it already Knows where the object was on the previous update,
and hence can speed up.
Hi,
I have a function that takes between 40ms and a second, depending on the
state of the program at any one time. This I expect. As such, I wanted to
put it in a thread such that it can be teamed with a faster but less robust
algorithm…
What I have found however, is that when threaded, the function’s speed is
intermitant. The change in speed should be gradual as it adapts to what it
is doing - it shouldn’t suddenly shift from 50ms up to 300ms (as the
program state can not change to that extent between iterations).
Any suggestions as to why it should have this problem? Any solutions?
(the thread doesn’t share much with what is beneath it. merely a boolean
that pauses activity, and another that quits, which are set by the main
program thread).
Is there any other CPU-intensive stuff going on besides this thread? The
thread is getting the CPU in slices, along with all other threads (like
the main one). So the speed can depend on whether the CPU is also used
by other threads. I don’t just mean a general slowdown, but perhaps the
50 ms execution was not interrupted, while the 300 ms is really 60 ms,
using first 50 ms, then a long sleep, then the last 10?
If you can, get a thread-aware profiler and time the execution that way.
I’m guessing you use a timer right now? That will not really reflect
your algorithm’s running time, only the real-time wait for the result.
Bye,
Ben
I have a function that takes between 40ms and a second, depending on the
state of the program at any one time. This I expect. As such, I wanted to
put it in a thread such that it can be teamed with a faster but less robust
algorithm, and also so that I could get reasonable response from the
keyboard (rather than holding down q for a second or two before it realises
I want to stop…)
What I have found however, is that when threaded, the function’s speed is
intermitant. The change in speed should be gradual as it adapts to what it
is doing - it shouldn’t suddenly shift from 50ms up to 300ms (as the
program state can not change to that extent between iterations).
The function is now sharing the CPU with your other code. Unless you
have put in code to switch between the two threads there is no way to
know when your function is running and when it is not running. So, it
starts and stops at nearly random and arbitrary times. The result is
that the wall clock time it takes to run the function becomes
intermitant. In other words this is the expected behavior of code
running in a thread.
Any suggestions as to why it should have this problem? Any solutions?
(the thread doesn’t share much with what is beneath it. merely a boolean
that pauses activity, and another that quits, which are set by the main
program thread).
If you want two threads to run at the same time at the same speed they
ran at as a single thread then you need two CPUs. Pick up a
hyperthreading CPU or a dual CPU motherboard.
The function in question is used for locating and tracking objects in video,
the speed difference occurs due to its nature - it doesn’t have to search
so much when it already Knows where the object was on the previous update,
and hence can speed up.
What it does has nothing to do with the way threads work.
Bob PendletonOn Thu, 2004-05-20 at 06:34, murray evans wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+
If you want two threads to run at the same time at the same speed they
ran at as a single thread then you need two CPUs. Pick up a
hyperthreading CPU or a dual CPU motherboard.
Hyperthreading! Amazing what you forget to turn on… that improves things
measurably. I never thought to check that it was enabled before…
What it does has nothing to do with the way threads work.
Bob Pendleton
I know, but sometimes it helps clear up what you’re trying to ask.
Cheers.
If you want two threads to run at the same time at the same speed they
ran at as a single thread then you need two CPUs. Pick up a
hyperthreading CPU or a dual CPU motherboard.
Hyperthreading! Amazing what you forget to turn on… that improves things
measurably. I never thought to check that it was enabled before…
What it does has nothing to do with the way threads work.
Bob Pendleton
I know, but sometimes it helps clear up what you’re trying to ask.
Yeah, I realized my last comment was, pretty stupid after I read the
message when it came back to me on the list. It is always better to
include to much information than not enough. You never know what will
give someone the clue they need to solve the problem.
Cheers.
Bob PendletonOn Thu, 2004-05-20 at 11:28, murray evans wrote:
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-------------------------------------+