gamedevlists-general

RE: [GD-General] profiling multi threaded applications

[Lewin, G. <gl...@ea...>]

You could have your START and END macros (I assume you use something
like that) include EnterCriticalSection and LeaveCriticalSection=20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Andras Balogh
> Sent: Wednesday, July 20, 2005 11:37 AM
> To: gam...@li...
> Subject: Re: [GD-General] profiling multi threaded applications
>=20
> Pretending that this is not an option, are there any other=20
> possibilities?
>=20
>=20
> Christian Laforte wrote:
> > If possible, design your architecture so that your threads=20
> can work in=20
> > a lockstep mode, with one central mutex controlling which thread is=20
> > running at any given moment. That way you can at least get=20
> a partial=20
> > profile and optimize each thread individually.
> >=20
> > This type of design can also prove very useful to debug deadlocks.
> >=20
> > Hope that helps a bit,
> >=20
> > Christian Laforte
> > www.feelingsoftware.com
> >=20
> >=20
> >>-----Original Message-----
> >>From: gam...@li...
> >>[mailto:gam...@li...]=20
> On Behalf Of=20
> >>Andras Balogh
> >>Sent: Wednesday, July 20, 2005 10:36 AM
> >>To: gam...@li...
> >>Subject: [GD-General] profiling multi threaded applications
> >>
> >>I was about to add a simple profiler into our engine, but I've just=20
> >>realized that the usual hierarchical profiler that measures=20
> the time=20
> >>for a chunk of code won't cut it, in a multithreaded application.
> >>
> >>I understand that even when I have a single threaded app, there are=20
> >>usually several other applications are running in the=20
> background, but=20
> >>mostly they are all idle, so it's just noise. But in this case, I=20
> >>would have multiple, heavily working threads. If the OS=20
> switches back=20
> >>and forth between these threads all the time, then how is=20
> it possible=20
> >>to make accurate, or even just usable measurements??
> >>
> >>Thanks,
> >>
> >>Andras
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration=20
> Strategies from IBM. Find simple to follow Roadmaps,=20
> straightforward articles, informative Webcasts and more! Get=20
> everything you need to get up to speed, fast.=20
> http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

RE: [GD-General] profiling multi threaded applications

[Lewin, G. <gl...@ea...>]

That shouldn't be a problem, I assumed your START and END pairs can be
nested.

From MSDN:
=20
After a thread has ownership of a critical section, it can make
additional calls to EnterCriticalSection or TryEnterCriticalSection
without blocking its execution. This prevents a thread from deadlocking
itself while waiting for a critical section that it already owns. The
thread enters the critical section each time EnterCriticalSection and
TryEnterCriticalSection succeed. A thread must call LeaveCriticalSection
once for each time that it entered the critical section.

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Andras Balogh
> Sent: Wednesday, July 20, 2005 1:50 PM
> To: gam...@li...
> Subject: Re: [GD-General] profiling multi threaded applications
>=20
> Yeah, I have something similiar, except that it's=20
> hierarchical, so START and END can be nested, in which case=20
> it gets a bit trickier to use CriticalSections, but I think I=20
> could give that a try!
>=20
> thx,
>=20
> Andras
>=20
> Lewin, Gareth wrote:
> > You could have your START and END macros (I assume you use=20
> something=20
> > like that) include EnterCriticalSection and LeaveCriticalSection
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration=20
> Strategies from IBM. Find simple to follow Roadmaps,=20
> straightforward articles, informative Webcasts and more! Get=20
> everything you need to get up to speed, fast.=20
> http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

Re: [GD-General] profiling multi threaded applications

[brian s. <bri...@gm...>]

Andras, are all of your threads doing the same thing? Otherwise, a critical=
=20
section won't do anything for you. If only one thread tries to acquire the=
=20
object, it will (trivially) always get it.

Now, if you're thinking going to put this critical section at the top level=
=20
of your app and make all threads go through it, then you're back to=20
Christian's suggestion:

If possible, design your architecture so that your threads can work in a
lockstep mode, with one central mutex controlling which thread is running a=
t
any given moment. That way you can at least get a partial profile and
optimize each thread individually.

This type of design can also prove very useful to debug deadlocks.

--brian

On 7/20/05, Lewin, Gareth <gl...@ea...> wrote:
>=20
> That shouldn't be a problem, I assumed your START and END pairs can be
> nested.
>=20
> From MSDN:
>=20
> After a thread has ownership of a critical section, it can make
> additional calls to EnterCriticalSection or TryEnterCriticalSection
> without blocking its execution. This prevents a thread from deadlocking
> itself while waiting for a critical section that it already owns. The
> thread enters the critical section each time EnterCriticalSection and
> TryEnterCriticalSection succeed. A thread must call LeaveCriticalSection
> once for each time that it entered the critical section.
>=20
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...] On
> > Behalf Of Andras Balogh
> > Sent: Wednesday, July 20, 2005 1:50 PM
> > To: gam...@li...
> > Subject: Re: [GD-General] profiling multi threaded applications
> >
> > Yeah, I have something similiar, except that it's
> > hierarchical, so START and END can be nested, in which case
> > it gets a bit trickier to use CriticalSections, but I think I
> > could give that a try!
> >
> > thx,
> >
> > Andras
> >
> > Lewin, Gareth wrote:
> > > You could have your START and END macros (I assume you use
> > something
> > > like that) include EnterCriticalSection and LeaveCriticalSection
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> > Strategies from IBM. Find simple to follow Roadmaps,
> > straightforward articles, informative Webcasts and more! Get
> > everything you need to get up to speed, fast.
> > http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
> >
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>

Re: [GD-General] profiling multi threaded applications

[Andras B. <and...@gm...>]

I don't have anything against lockstep mode, if it's automagically 
forced only during profiling, but I don't want to design the app to work 
that way during normal operation. The reason is that if these steps are 
not fine enough, it could hurt interactivity, which I can live with 
while profiling, but cannot accept in "final" mode.


brian sharon wrote:
> Andras, are all of your threads doing the same thing? Otherwise, a critical 
> section won't do anything for you. If only one thread tries to acquire the 
> object, it will (trivially) always get it.
> 
> Now, if you're thinking going to put this critical section at the top level 
> of your app and make all threads go through it, then you're back to 
> Christian's suggestion:
> 
> If possible, design your architecture so that your threads can work in a
> lockstep mode, with one central mutex controlling which thread is running at
> any given moment. That way you can at least get a partial profile and
> optimize each thread individually.
> 
> This type of design can also prove very useful to debug deadlocks.
> 
> --brian
> 

RE: [GD-General] profiling multi threaded applications

[Lewin, G. <gl...@ea...>]

Well if that's the case, just implement a simple Critical Section around
the main loop of each thread, with a Sleep, and turn it only on in
profile=20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Andras Balogh
> Sent: Wednesday, July 20, 2005 2:33 PM
> To: gam...@li...
> Subject: Re: [GD-General] profiling multi threaded applications
>=20
> I don't have anything against lockstep mode, if it's=20
> automagically forced only during profiling, but I don't want=20
> to design the app to work that way during normal operation.=20
> The reason is that if these steps are not fine enough, it=20
> could hurt interactivity, which I can live with while=20
> profiling, but cannot accept in "final" mode.
>=20
>=20
> brian sharon wrote:
> > Andras, are all of your threads doing the same thing? Otherwise, a=20
> > critical section won't do anything for you. If only one=20
> thread tries=20
> > to acquire the object, it will (trivially) always get it.
> >=20
> > Now, if you're thinking going to put this critical section=20
> at the top=20
> > level of your app and make all threads go through it, then=20
> you're back=20
> > to Christian's suggestion:
> >=20
> > If possible, design your architecture so that your threads=20
> can work in=20
> > a lockstep mode, with one central mutex controlling which thread is=20
> > running at any given moment. That way you can at least get=20
> a partial=20
> > profile and optimize each thread individually.
> >=20
> > This type of design can also prove very useful to debug deadlocks.
> >=20
> > --brian
> >=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration=20
> Strategies from IBM. Find simple to follow Roadmaps,=20
> straightforward articles, informative Webcasts and more! Get=20
> everything you need to get up to speed, fast.=20
> http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D557
>=20

Re: [GD-General] profiling multi threaded applications

[Andras B. <and...@gm...>]

Yeah, I guess I'll just do something like that. Thanks!


Lewin, Gareth wrote:
> Well if that's the case, just implement a simple Critical Section around
> the main loop of each thread, with a Sleep, and turn it only on in
> profile 
> 

Re: [GD-General] profiling multi threaded applications

[Andras B. <and...@gm...>]

Yeah, I have something similiar, except that it's hierarchical, so START 
and END can be nested, in which case it gets a bit trickier to use 
CriticalSections, but I think I could give that a try!

thx,

Andras

Lewin, Gareth wrote:
> You could have your START and END macros (I assume you use something
> like that) include EnterCriticalSection and LeaveCriticalSection