gdalgorithms-list

[Algorithms] Timing problems

[Paul at H. <pa...@ru...>]

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.

Re: [Algorithms] Timing problems

[Gregory J. <gj...@da...>]

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:pa...@ru...] 
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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.

 

 

Re: [Algorithms] Timing problems

[Paul at H. <pa...@ru...>]

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 
  To: 'Game Development Algorithms' 
  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:pa...@ru...] 
  Sent: Saturday, January 03, 2009 3:06 PM
  To: gda...@li...
  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
  GDA...@li...
  https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
  Archives:
  http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Emil P. <hu...@co...>]

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:pa...@ru...] 
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:gj...@da...>  

To: 'Game Development Algorithms'
<mailto:gda...@li...>  

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:pa...@ru...] 
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Paul at H. <pa...@ru...>]

Thanks Emil, I'll give that a go first. :)

Regards,
Paul Johnson.


  ----- Original Message ----- 
  From: Emil Persson 
  To: 'Game Development Algorithms' 
  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:pa...@ru...] 
  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 

    To: 'Game Development Algorithms' 

    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:pa...@ru...] 
    Sent: Saturday, January 03, 2009 3:06 PM
    To: gda...@li...
    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
    GDA...@li...
    https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
    Archives:
    http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list



------------------------------------------------------------------------------


  ------------------------------------------------------------------------------





------------------------------------------------------------------------------


  _______________________________________________
  GDAlgorithms-list mailing list
  GDA...@li...
  https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
  Archives:
  http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Dan W. <Da...@Pi...>]

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:pa...@ru...] 
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:hu...@co...>  
	To: 'Game Development Algorithms'
<mailto:gda...@li...>  
	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:pa...@ru...] 
	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:gj...@da...>  

		To: 'Game Development Algorithms'
<mailto:gda...@li...>  

		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:pa...@ru...] 
		Sent: Saturday, January 03, 2009 3:06 PM
		To: gda...@li...
		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
		GDA...@li...
	
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
		Archives:
	
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t

	
________________________________


	

	
------------------------------------------------------------------------
------
	
	
	

	
________________________________


	

	_______________________________________________
	GDAlgorithms-list mailing list
	GDA...@li...
	https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
	Archives:
	
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t
	
	

Re: [Algorithms] Timing problems

[Paul at H. <pa...@ru...>]

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 
  To: Game Development Algorithms 
  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:pa...@ru...] 
  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 
    To: 'Game Development Algorithms' 
    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:pa...@ru...] 
    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 

      To: 'Game Development Algorithms' 

      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:pa...@ru...] 
      Sent: Saturday, January 03, 2009 3:06 PM
      To: gda...@li...
      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
      GDA...@li...
      https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
      Archives:
      http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list



----------------------------------------------------------------------------


    ------------------------------------------------------------------------------





----------------------------------------------------------------------------


    _______________________________________________
    GDAlgorithms-list mailing list
    GDA...@li...
    https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
    Archives:
    http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list




------------------------------------------------------------------------------


  ------------------------------------------------------------------------------
  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
  GDA...@li...
  https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
  Archives:
  http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Gregory J. <gj...@da...>]

It doesn't matter whether you use threads or not -- your main process thread
can (and will) be moved by the OS from any core to any other core.
Single-threaded processes that use QPF/QPC will have the same issues as
massively-threaded ones.

Greg


  _____  

From: Paul at Home [mailto:pa...@ru...] 
Sent: Tuesday, January 06, 2009 2: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:Da...@Pi...>  
To: Game Development  <mailto:gda...@li...>
Algorithms 
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:pa...@ru...] 
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:hu...@co...>  
To: 'Game Development  <mailto:gda...@li...>
Algorithms' 
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:pa...@ru...] 
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  <mailto:gj...@da...> Junker 

To: 'Game Development  <mailto:gda...@li...>
Algorithms' 

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:pa...@ru...] 
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list



  _____  




----------------------------------------------------------------------------
--






  _____  




_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list





  _____  




----------------------------------------------------------------------------
--
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Mat N. <mat...@bu...>]

You can always set the affinity for a thread that controls the jobs submitted to other threads.

MSN
From: Paul at Home [mailto:pa...@ru...]
Sent: Tuesday, January 06, 2009 2: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:Da...@Pi...>
To: Game Development Algorithms<mailto:gda...@li...>
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:pa...@ru...]
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:hu...@co...>
To: 'Game Development Algorithms'<mailto:gda...@li...>
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:pa...@ru...]
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:gj...@da...>
To: 'Game Development Algorithms'<mailto:gda...@li...>
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:pa...@ru...]
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
________________________________
------------------------------------------------------------------------------

________________________________
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
________________________________
------------------------------------------------------------------------------
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Emil P. <hu...@co...>]

Well, that's not necessary, unless the other threads also need to read the
QPC independently (rather than being provided the QPC value from the main
thread). Calling SetThreadAffinityMask() only affects the thread you're
passing to it. So if you have a main thread and a bunch of worker threads
and QPC is only read in the main thread to compute your frame times there's
no need to call SetThreadAffinityMask() for any of the worker threads. It's
probably better to leave it up to Windows to schedule them anyway it likes.
Unless the work is very balanced and you know something about the cache
structure of the CPU so that you could get some benefits from
preserved/shared caches, but generally I would just leave it up to Windows.
If the work load is unbalanced between threads you may artificially throttle
your app performance if you force each thread to only run on a particular
core.

 

Another thing to note is that you can set the affinity mask to several CPUs.
For instance if you're forcing the main thread to run on CPU0, and the main
thread has a lot of work, it could be beneficial to set the affinity mask on
worker threads to allow all CPUs except CPU0, just to avoid them ever
stealing it from the main thread. Could be a performance gain if the main
thread is the bottleneck.

 

And just for the record there's also a SetProcessAffinityMask() function,
which sets the affinity mask globally to the process. I would generally
avoid that one.

 

-Emil

 

 

From: Mat Noguchi [mailto:mat...@bu...] 
Sent: 06 January 2009 23:31
To: Game Development Algorithms
Subject: Re: [Algorithms] Timing problems

 

You can always set the affinity for a thread that controls the jobs
submitted to other threads.

 

MSN

From: Paul at Home [mailto:pa...@ru...] 
Sent: Tuesday, January 06, 2009 2: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:Da...@Pi...>  

To: Game Development Algorithms
<mailto:gda...@li...>  

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:pa...@ru...] 
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:hu...@co...>  

To: 'Game Development Algorithms'
<mailto:gda...@li...>  

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:pa...@ru...] 
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:gj...@da...>  

To: 'Game Development Algorithms'
<mailto:gda...@li...>  

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:pa...@ru...] 
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

  _____  

----------------------------------------------------------------------------
--

  _____  

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

  _____  

----------------------------------------------------------------------------
--
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Ted J. <tju...@gm...>]

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:pa...@ru...] 
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:Da...@Pi...>  

To: Game Development Algorithms
<mailto:gda...@li...>  

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:pa...@ru...] 
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:hu...@co...>  

To: 'Game Development Algorithms'
<mailto:gda...@li...>  

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:pa...@ru...] 
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:gj...@da...>  

To: 'Game Development Algorithms'
<mailto:gda...@li...>  

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:pa...@ru...] 
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

  _____  

----------------------------------------------------------------------------
--



  _____  

_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

  _____  

----------------------------------------------------------------------------
--
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Mat N. <mat...@bu...>]

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:tju...@gm...]
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:pa...@ru...]
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:Da...@Pi...>
To: Game Development Algorithms<mailto:gda...@li...>
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:pa...@ru...]
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:hu...@co...>
To: 'Game Development Algorithms'<mailto:gda...@li...>
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:pa...@ru...]
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:gj...@da...>
To: 'Game Development Algorithms'<mailto:gda...@li...>
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:pa...@ru...]
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
________________________________
------------------------------------------------------------------------------
________________________________
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
________________________________
------------------------------------------------------------------------------
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Randall T. <ran...@vo...>]

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:mat...@bu...] 
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:tju...@gm...] 
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:pa...@ru...] 
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:Da...@Pi...>  

	To: Game Development Algorithms
<mailto:gda...@li...>  

	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:pa...@ru...] 
	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:hu...@co...>  

		To: 'Game Development Algorithms'
<mailto:gda...@li...>  

		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:pa...@ru...] 
		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:gj...@da...>


			To: 'Game Development Algorithms'
<mailto:gda...@li...>  

			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:pa...@ru...] 
			Sent: Saturday, January 03, 2009 3:06 PM
			To: gda...@li...
			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
			GDA...@li...
	
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
			Archives:
	
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t

		
________________________________


	
------------------------------------------------------------------------
------

		
________________________________


		_______________________________________________
		GDAlgorithms-list mailing list
		GDA...@li...
	
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
	GDA...@li...
	https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
	Archives:
	
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-lis
t

Re: [Algorithms] Timing problems

[Jon W. <jw...@gm...>]

Mat Noguchi wrote:
>
> Only if the threads never context switched while on that core. I 
> forget if context switches flush the CPU caches or not.
>

In general they don't have to, because caches will generally be on 
physical (not logical) addresses. However, whatever thread you switch to 
is likely (but not guaranteed) to be cache thirsty enough that, when you 
get switched back in, the majority of your data is no longer there.


Sincerely,

jw

Re: [Algorithms] Timing problems

[Gregory J. <gj...@da...>]

Correct.


Greg

 

  _____  

From: Paul at Home [mailto:pa...@ru...] 
Sent: Sunday, January 04, 2009 3:44 AM
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:gj...@da...>  

To: 'Game Development Algorithms'
<mailto:gda...@li...>  

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:pa...@ru...] 
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Gregory J. <gj...@da...>]

Sorry, that's what I get for posting right when I wake up.Emil had the
correct version; since it's a bitmask, you indicate the zero'th core with a
1. 


Greg

 

  _____  

From: Gregory Junker [mailto:gj...@da...] 
Sent: Sunday, January 04, 2009 10:07 AM
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Timing problems

 

Correct.


Greg

 

  _____  

From: Paul at Home [mailto:pa...@ru...] 
Sent: Sunday, January 04, 2009 3:44 AM
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:gj...@da...>  

To: 'Game Development Algorithms'
<mailto:gda...@li...>  

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:pa...@ru...] 
Sent: Saturday, January 03, 2009 3:06 PM
To: gda...@li...
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
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list

Re: [Algorithms] Timing problems

[Jon W. <jw...@gm...>]

Jan Wassenberg wrote:
> I have developed a workaround that uses HPET hardware (a >= 10 MHz counter  
> without the annoying flaws of other timers) by means of a mostly user-mode  
> driver.
>   

On a modern version of Windows, with proper motherboard and CPU drivers, 
QPC will use that same timer, so you don't need any custom driver.

Sincerely,

jw

Re: [Algorithms] Timing problems

[Jan W. <jan...@gm...>]

> On a modern version of Windows, with proper motherboard and CPU drivers,
> QPC will use that same timer, so you don't need any custom driver.
Yes, but as mentioned in the accompanying article (excerpt follows), HPET  
support hasn't been backported to Windows XP, which means many existing  
systems otherwise lack a decent timer.

>>
In the mean time, since Windows does not offer
a ubiquitous software solution, the TSC is not reliable. In an unfortunate
twist, it is precisely this timer that QPC uses on such dual-core  
platforms.
One can force it to use the PMT by adding /usepmtimer to boot.ini [QPC
Workaround], but making changes to such a critical system file should not
be asked of users. Finally, despite Microsoft having issued the HPET spec-
ification 5 years ago, support for it has not been patched into Windows XP
and it is only available on Vista.

These circumstances result in the moribund state of affairs that was previ-
ously described: on many systems today, only a mere millisecond-resolution
timer is available. According to [Valve Survey], 93% of the participating
systems are running Windows XP, and 22% have more than one processor
or core. This large proportion cannot be ignored, so we will have to find a
workaround for the above issue.
<<

Best Regards
Jan

Re: [Algorithms] Timing problems

[Jon W. <jw...@gm...>]

Paul at Home wrote:
> 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 ?


There are two fixes:

1) Keep the last value returned, and return max(lastValue, nextValue). 
Requires some degree of locking or compare/exchange to work in a 
multi-threaded fashion, or using TLS for the "lastValue".

2) Install proper CPU drivers for your system so you don't get 
incoherent results. <-- vastly preferred method

Sincerely,

jw

Re: [Algorithms] Timing problems

[Gregory J. <gj...@da...>]

> 
> 2) Install proper CPU drivers for your system so you don't get 
> incoherent results. <-- vastly preferred method
> 

Thus shifting the problem from the developers to post-sales support...

Re: [Algorithms] Timing problems

[Paul at H. <pa...@ru...>]

or "retard management" as I prefer to think of it.  :)

My old man is otherwise extremely intelligent but he still thinks if he 
presses the wrong keys at the wrong time that the USA will nuke China or 
something. Until that generation has moved on, I'll go with software-side 
fixes every time if possible. :)

Regards,
Paul Johnson.


----- Original Message ----- 
From: "Gregory Junker" <gj...@da...>
To: "'Game Development Algorithms'" 
<gda...@li...>
Sent: Monday, January 05, 2009 10:13 PM
Subject: Re: [Algorithms] Timing problems


>>
>> 2) Install proper CPU drivers for your system so you don't get
>> incoherent results. <-- vastly preferred method
>>
>
> Thus shifting the problem from the developers to post-sales support...
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list
>
> 

Re: [Algorithms] Timing problems

[Robert W. <fo...@ro...>]

Hi Jan, I wondered, is this driver still available by any chance?

I'm trying to access the HPET timer in my software in XP or in later
versions of Windows where it may be enabled in the BIOS but seems it
is disabled by default in the OS.

With the later versions of Windows I could instruct my users to enable 
it in Windows using bcdhedit but the problem with that is that in the online 
forums a few people report performance issues and possibly even freezes with 
it enabled (which may be why the default is for it to be disabled).

In XP there seems to be no way to access it normally.

It looks as if your driver might be a possible solution. But get 404 not found 
when I try to download the zip.

This is for a software metronome.

Thanks,

Robert Walker

Re: [Algorithms] Timing problems

[Jan W. <jan...@gm...>]

Hi Robert,
this driver is indeed still available. You can always check
http://trac.wildfiregames.com/browser/ps/trunk/source/lib/sysdep/os/win/aken
and I will investigate tonight where the zip file went.

Unfortunately there has been no progress in signing it - that is essential
for it to be usable by non-developers. Is there anyone who can help?

The difficulty is that it provides functions to map physical memory
(HPET is memory-mapped) and write model-specific registers, which
raises security concerns. Perhaps we can change the interface to provide
only 'safe' functionality, such as reading HPET and performance counters,
instead of allowing apps to do that and more.
Anyone willing and able to work together with me on this?

Re: [Algorithms] Timing problems

[Robert W. <fo...@ro...>]

Hi Jan,

Sorry hope you don't mind me posting again before you reply.

The thing is, I've just had a go at installing it - I found your 
install_aken.bat.

Got this message:

"To install the driver, please first enable test mode:
C:\Users\Robert\AppData\Local\0AD~1.ALP\binaries\system\INSTAL~1.BAT enabletest
(This is necessary because Vista/Win7 x64 require signing with
 a Microsoft "cross certificate". The Fraunhofer code signing certificate
 is not enough, even though its chain of trust is impeccable.
 Going the WHQL route, perhaps as an "unclassified" driver, might work.
 see http://www.freeotfe.org/docs/Main/impact_of_kernel_driver_signing.htm )
Then reboot (!) and install the driver:
C:\Users\Robert\AppData\Local\0AD~1.ALP\binaries\system\INSTAL~1.BAT install ["p
ath_to_directory_containing_aken*.sys"]
(If no path is given, we will use the directory of this batch file)
To remove the driver and disable test mode, execute the following:
C:\Users\Robert\AppData\Local\0AD~1.ALP\binaries\system\INSTAL~1.BAT remove
C:\Users\Robert\AppData\Local\0AD~1.ALP\binaries\system\INSTAL~1.BAT disabletest

Press any key to continue . . ."

So - it rather looks as if my code signing certificate is no good for this, as I 
thought might be a possibility. I expect it is necessary to use a Verisign 
certificate. 

I was told by someone at Microsoft support that it costs $99 per year for one of 
those, so that's the same cost as the certificate I already use - but I've 
already bought my certificate for the next year. Still I could consider it if it 
solves the problem and if there is no other solution.

ALSO HAD AN IDEA ABOUT AN EASY WAY TO MAKE THE DRIVER READ ONLY.

The idea is - there is no need to remove huge chunks of the driver - I can well 
understand it might take thought to do that without introducing new bugs. 

You could instead just #ifdef out the routines that write to the mapped 
hardware resources. I get the impression from your desciprion that probably, 
that would involve very few actual lines of code.

I imagine would be things like #ifdefs to remove the lines

__writemsr(..)

and in
ZwOpenSection
to replace OPEN_ALL_ACCESS
by
SECTION_MAP_READ

that sort of thing.

So - then the driver has all your other code for writing as before, but if some 
malware tries to use it to write to memory, it just "goes through the 
motions" but doesn't actually do anything. 

In the documentation you make clear that the driver is only to be used for read
operations.

Then from your other remarks, presumably if the driver doesn't call any
actual routines that write to hardware resources, then it mightn't need
signing at all at that point?

Is that true?

Just a thought,

Robert

Re: [Algorithms] Timing problems

[Jan W. <jan...@gm...>]

We have veered outside the scope of [gd-algorithms] - I will reply directly;
anyone interested in a reduced, ideally WHQL driver capable of accessing
HPET and performance counters, please join the conversation by writing us.

Have you gone through the WHQL experience before? Are there any pitfalls
to avoid? Would love to hear from you.