Context switches don't (trigger cache flushes) on 360/PS3. I'd doubt
they do in PC land, but there's so many flavors of so many
hardware/software combos I'd shudder to have to "prove" that's the case.
Keeping threads core-assigned helps coherency on the 360 and makes no
difference on the PS3 and see "so many flavors" above for the PC.
As far as measuring performance, yet again the PC is challenging. I'd do
stopwatch-tests. (forty bazillion iterations.) The other two are pretty
straightforward, though most of this discussion re: lockfree vs.
critical section is moot for the PS3 as far as performance goes. (But
you'll save on your limited OS objects on the PS3 by using lockfree
implementations.)
Basically, on the 360, you get about 4x performance improvement in
high-contention scenarios using lockfree vs. cs'd containers. Approx.
Sometimes more, sometimes less.
________________________________
From: Mat Noguchi [mailto:***@bungie.com]
Sent: Tuesday, January 06, 2009 5:13 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Timing problems
Only if the threads never context switched while on that core. I forget
if context switches flush the CPU caches or not.
MSN
From: Ted Jump [mailto:***@gmail.com]
Sent: Tuesday, January 06, 2009 3:04 PM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Timing problems
You could also go so far as always setting affinity, but rotating which
CPU it is done on and letting your timer basis code be thread local.
You could not compare absolute values between threads (without a global
locked timer) but you could at least be assured that if QPC/whatever was
core-specific that you were getting consistent values per-thread.
Or I'm missing something wacked here, very possible too.
-t
Ps: in theory, would keeping threads core-assigned improve cache
coherency?
From: Paul at Home [mailto:***@rubicondev.com]
Sent: Tuesday, January 06, 2009 4:18 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Timing problems
I did wonder about this actually, especially with the other hot topic
being about parallel computing!
My problem that led me to post in the first place had me confused as all
the examples people are talking about on here don't fit my case anyway.
My entire codebase doesn't use threads in earnest (apart from a
background pre-loader that's gone by the time I'm looking) and my
chip/mobo and everything else is brand new so shouldn't have any legacy
problems.
But using the affinity mask as detailed did indeed make my samples much
smoother. I don't see how that could be a bug in my own code so now I'm
worried I've stumbled across something new.
And what happens if I decide to do more aggressive threading, possibly
utilising the code being discussed elsewhere. How do you guys get your
timings to do any profiling with whilst running so many different
threads ?
Regards,
Paul Johnson.
----- Original Message -----
From: Dan White <mailto:***@PipeWorks.Com>
To: Game Development Algorithms
<mailto:gdalgorithms-***@lists.sourceforge.net>
Sent: Tuesday, January 06, 2009 7:58 PM
Subject: Re: [Algorithms] Timing problems
We stuck the SetThreadAffinityMask code in our libraries, and
our timing problems went away.
However, about 6 mo later, we ended up with a weird bug:
We have a converter that run as part of our build process. To
speed up the build, we started running multiple instances of the
converter on a multicore machine. However, the build times didn't go
down, and closer examination showed that only one CPU use being used.
Turns out SetThreadAffinityMask was doing exactly what it was
supposed to and making all our processes run on one core. Our solution
was to look at the processor identifier and skip the affinity business
CPU's we know to work correctly.
-D
________________________________
From: Paul at Home [mailto:***@rubicondev.com]
Sent: Sunday, January 04, 2009 8:32 AM
To: Game Development Algorithms
Subject: Re: [Algorithms] Timing problems
Thanks Emil, I'll give that a go first. :)
Regards,
Paul Johnson.
----- Original Message -----
From: Emil Persson <mailto:***@comhem.se>
To: 'Game Development Algorithms'
<mailto:gdalgorithms-***@lists.sourceforge.net>
Sent: Sunday, January 04, 2009 2:36 PM
Subject: Re: [Algorithms] Timing problems
The problem doesn't arise from threading your
application, but from calling QPC from different CPUs. In a multi-core
machine Windows will schedule each thread to run on any CPU as it sees
fit. First time-slice for your application may run on CPU0, the next one
perhaps on CPU2, and then CPU1 etc. By the time you're reading QPC you
could be on any CPU and it could be different cores every frame. Unless
of course you call SetThreadAffinityMask(). Something like this at the
beginning of the application should do:
SetThreadAffinityMask(GetCurrentThread(), 1);
This will stick the thread to CPU 0.
-Emil
From: Paul at Home [mailto:***@rubicondev.com]
Sent: 04 January 2009 12:44
To: Game Development Algorithms
Subject: Re: [Algorithms] Timing problems
I've seen this around but I'm not using any threads. Not
deliberately anyway. Do you put a zero in for "me" ?
Regards,
Paul Johnson.
----- Original Message -----
From: Gregory Junker <mailto:***@dayark.com>
To: 'Game Development Algorithms'
<mailto:gdalgorithms-***@lists.sourceforge.net>
Sent: Sunday, January 04, 2009 2:07 AM
Subject: Re: [Algorithms] Timing problems
Hi Paul
By "jump problem", do you mean this?
http://support.microsoft.com/kb/274323
Either way, simply set the thread that is your
time master to run on only a single core, using SetThreadAffinityMask()
(on Win32, of course - not sure what the equivalent, if any, might be on
Linux).
http://msdn.microsoft.com/en-us/library/ms686247(VS.85).aspx
Yes, it's a hack, but at present, it's what we
got. ;)
Greg
________________________________
From: Paul at Home [mailto:***@rubicondev.com]
Sent: Saturday, January 03, 2009 3:06 PM
To: gdalgorithms-***@lists.sourceforge.net
Subject: [Algorithms] Timing problems
I've just fallen foul of QPC not working
correctly having just gone from a single processor to a quad core.
I remember reading somewhere that multiple
processors could cause problems in the future, but I guess the future
(for me) just arrived. I do handle the well-known "jump" problem but I
guess that's old news now anyway.
Can anyone point me in the right direction for
how to fix this please ?
Regards,
Paul Johnson.
________________________________
------------------------------------------------------------------------
------
________________________________
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t
________________________________
------------------------------------------------------------------------
------
________________________________
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t
________________________________
------------------------------------------------------------------------
------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
________________________________
_______________________________________________
GDAlgorithms-list mailing list
GDAlgorithms-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t