Hi,
I just finished an analysis of the Win32 SDL threads and it seems like
my application is still serialized according to VTune. I would expect
my threads to run concurrently (given that I have 4 cores to run them
on). The way I implemented my system, each threads run in a do {} while
(1) loop and the work they want to do is waiting with SDL_CondWait,
triggered by SDL_CondBroadcast from the parent thread which busy loops.
What I notice is that when I fire a broadcast, the first thread runs and
only after it is completed does the second thread go and etc.
I have implemented a similar logic with Pthread/Win32 using barriers and
all threads start simultaneously there giving me a very nice 2.5x speedup.
Is it a known issue that the SDL threads aren’t multicore friendly? Or
am I doing something dumb here?
Chris
Is it a known issue that the SDL threads aren’t multicore friendly? Or am I
doing something dumb here?
Look up how to find out the CPU affinity of threads in Win32, you
might find out that your process has a CPU affinity set. I am told
that in some cases, the Windows Explorer has a CPU affinity to just
the first processor, and the CPU affinity is inherited by processes
that it launches…
http://blogs.msdn.com/oldnewthing/archive/2005/03/21/399688.aspxOn Tue, Jun 3, 2008 at 1:33 AM, Chris T wrote:
–
http://pphaneuf.livejournal.com/
I used SDL threads on my multicore machine and they run fine in
parallel. However, when I ported the code base to Microsofts Visual
Studio I noticed that in Debug mode only a single core appeared to be
used. In release both cores were.On Tue, Jun 3, 2008 at 6:33 AM, Chris T wrote:
Hi,
I just finished an analysis of the Win32 SDL threads and it seems like my
application is still serialized according to VTune. I would expect my
threads to run concurrently (given that I have 4 cores to run them on). The
way I implemented my system, each threads run in a do {} while (1) loop and
the work they want to do is waiting with SDL_CondWait, triggered by
SDL_CondBroadcast from the parent thread which busy loops. What I notice is
that when I fire a broadcast, the first thread runs and only after it is
completed does the second thread go and etc.
I have implemented a similar logic with Pthread/Win32 using barriers and all
threads start simultaneously there giving me a very nice 2.5x speedup.
Is it a known issue that the SDL threads aren’t multicore friendly? Or am I
doing something dumb here?
Chris
I’ve tried release and debug and both give the same results. It’s
concerning to me in the first place that debug./release do not behave
the same unless the SDL ppl strictly decided that it was easier to debug
with serialized threads. Either way, I’m still running 4 threads using
SDL threads that are not parallelized, they are serialized. I doubt
it’s the affinity as another reader mentioned, otherwise PThreads for
Win32 would probably have the same issue. This is SDL specific.
Currently, I’m using pthreads for win32 which is definitely not an ideal
solution as far as portability is concerned.
C)_> I used SDL threads on my multicore machine and they run fine in
parallel. However, when I ported the code base to Microsofts Visual
Studio I noticed that in Debug mode only a single core appeared to be
used. In release both cores were.
On Tue, Jun 3, 2008 at 6:33 AM, Chris T <@Chris_T> wrote:
Hi,
I just finished an analysis of the Win32 SDL threads and it seems like my
application is still serialized according to VTune. I would expect my
threads to run concurrently (given that I have 4 cores to run them on). The
way I implemented my system, each threads run in a do {} while (1) loop and
the work they want to do is waiting with SDL_CondWait, triggered by
SDL_CondBroadcast from the parent thread which busy loops. What I notice is
that when I fire a broadcast, the first thread runs and only after it is
completed does the second thread go and etc.
I have implemented a similar logic with Pthread/Win32 using barriers and all
threads start simultaneously there giving me a very nice 2.5x speedup.
Is it a known issue that the SDL threads aren’t multicore friendly? Or am I
doing something dumb here?
Chris
with serialized threads. Either way, I’m still running 4 threads using
SDL threads that are not parallelized, they are serialized.
What version of SDL is this?
–ryan.
Chris T wrote:
The way I implemented my system, each threads run in a do {} while
(1) loop and the work they want to do is waiting with SDL_CondWait,
triggered by SDL_CondBroadcast from the parent thread which busy loops.
What I notice is that when I fire a broadcast, the first thread runs and
only after it is completed does the second thread go and etc.
That would be the expected behavior if each thread is keeping the mutex
associated with the condition locked for the whole duration of its work.
Are you sure you’re not doing that?
Or am I doing something dumb here?
We can’t tell since you’re not showing us what you’re doing. Seeing your
source code would help diagnose the problem.
-Christian
This is SDL 1.2.13 (Top-of-tree stable)
C)_>> with serialized threads. Either way, I’m still running 4 threads using
SDL threads that are not parallelized, they are serialized.
What version of SDL is this?
–ryan.
Is it a known issue that the SDL threads aren’t multicore friendly? Or
am I doing something dumb here?
No, there’s nothing inherent in SDL threads that would prevent them from
using multiple cores. Maybe you can post a link to the source for your
test program?
See ya,
-Sam Lantinga, Lead Software Engineer, Blizzard Entertainment
Chris T wrote:
I’ve tried release and debug and both give the same results. It’s
concerning to me in the first place that debug./release do not behave
the same unless the SDL ppl strictly decided that it was easier to
debug with serialized threads. Either way, I’m still running 4
threads using SDL threads that are not parallelized, they are
serialized. I doubt it’s the affinity as another reader mentioned,
otherwise PThreads for Win32 would probably have the same issue.
This is SDL specific. Currently, I’m using pthreads for win32 which
is definitely not an ideal solution as far as portability is
concerned.
this is a shot in the dark, but could it be that you use SDL events in
your threads? IIRC SDL events implementation is thread save and may
contain mutex locks. i havn’t checked though.
clemens