gamedevlists-general

RE: [GD-General] responsive threading

[Mat N. \(BUNGIE\) <mat...@mi...>]

What else are you doing on the IO thread to make it eat up so much CPU
time?

MSN
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Andras Balogh
Sent: Friday, July 29, 2005 10:44 AM
To: gam...@li...
Subject: [GD-General] responsive threading

I'm developing a graphics application, that I want to be very=20
responsive, very smooth, all the time! The rendering is pretty simple,=20
the framerate is high and stable, so I just lock to vsync, and=20
everything moves beautifully smooth! The CPU usage for this thread is=20
always below 10%.

However, I also have another thread, that has to do some heavy work.=20
This thread does tons of IO operations, and also makes the CPU sweat!

There is no synchronization between the two threads, so they should be=20
able to run independently. Still, I'm experienceing sudden spikes in the

framerate, when the second thread is really hammering. What could be the

reason for this? Is it possible to do something about it, to regain the=20
continuous framerate? I'm really not interested in the performance of=20
the second thread, I just want my first thread to run as smooth as=20
possible! I've tried lowering the priority for the second thread, and it

does help, but there are still some spikes. Is it possible that it's=20
Windows itself doing some operations at higher priority, like memory=20
management, IO stuff, and the likes?

Thanks,


Andras


-------------------------------------------------------
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

RE: [GD-General] responsive threading

[Mat N. \(BUNGIE\) <mat...@mi...>]

If you are both reading and decompressing on the IO thread, you are
likely causing a lot of context switches if you have not modified the
priority on either thread.

MSN
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Andras Balogh
Sent: Friday, July 29, 2005 1:35 PM
To: gam...@li...
Subject: Re: [GD-General] responsive threading

I'm loading lots of "small" (avg. 1k x 1k) regions from lots of huge=20
(5GB+) wavelet compressed images. I'm using a 3rd party library to do=20
this (ECW), so I don't know the implementation details, but I could look

at the code, if I knew what to look for..



Andras


Mat Noguchi (BUNGIE) wrote:
> What else are you doing on the IO thread to make it eat up so much CPU
> time?
>=20
> MSN
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Andras Balogh
> Sent: Friday, July 29, 2005 10:44 AM
> To: gam...@li...
> Subject: [GD-General] responsive threading
>=20
> I'm developing a graphics application, that I want to be very=20
> responsive, very smooth, all the time! The rendering is pretty simple,

> the framerate is high and stable, so I just lock to vsync, and=20
> everything moves beautifully smooth! The CPU usage for this thread is=20
> always below 10%.
>=20
> However, I also have another thread, that has to do some heavy work.=20
> This thread does tons of IO operations, and also makes the CPU sweat!
>=20
> There is no synchronization between the two threads, so they should be

> able to run independently. Still, I'm experienceing sudden spikes in
the
>=20
> framerate, when the second thread is really hammering. What could be
the
>=20
> reason for this? Is it possible to do something about it, to regain
the=20
> continuous framerate? I'm really not interested in the performance of=20
> the second thread, I just want my first thread to run as smooth as=20
> possible! I've tried lowering the priority for the second thread, and
it
>=20
> does help, but there are still some spikes. Is it possible that it's=20
> Windows itself doing some operations at higher priority, like memory=20
> management, IO stuff, and the likes?
>=20
> Thanks,
>=20
>=20
> Andras
>=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_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&op=3Dclick
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>=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_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

Re: [GD-General] responsive threading

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

Even if this was the case, it would hurt overall performance, no? 
Overall performance is very good, I just don't like the occasional spikes...


Mat Noguchi (BUNGIE) wrote:
> If you are both reading and decompressing on the IO thread, you are
> likely causing a lot of context switches if you have not modified the
> priority on either thread.
> 
> MSN

RE: [GD-General] responsive threading

[Mat N. \(BUNGIE\) <mat...@mi...>]

Without knowing exactly what you are doing on both threads, it is very
hard to determine the source of framerate spikes that are caused by
multithreading.

MSN
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Andras Balogh
Sent: Friday, July 29, 2005 2:34 PM
To: gam...@li...
Subject: Re: [GD-General] responsive threading

Even if this was the case, it would hurt overall performance, no?=20
Overall performance is very good, I just don't like the occasional
spikes...


Mat Noguchi (BUNGIE) wrote:
> If you are both reading and decompressing on the IO thread, you are
> likely causing a lot of context switches if you have not modified the
> priority on either thread.
>=20
> MSN


-------------------------------------------------------
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

Re: [GD-General] responsive threading

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

I understand that, and I am thankful for your suggestions, but the 
problem is that I don't really know what's going on in this 
decompression library myself.. I was just assuming that whatever it 
does, there is a way to make it not disturb my main thread.


Andras


Mat Noguchi (BUNGIE) wrote:
> Without knowing exactly what you are doing on both threads, it is very
> hard to determine the source of framerate spikes that are caused by
> multithreading.
> 
> MSN
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Andras Balogh
> Sent: Friday, July 29, 2005 2:34 PM
> To: gam...@li...
> Subject: Re: [GD-General] responsive threading
> 
> Even if this was the case, it would hurt overall performance, no? 
> Overall performance is very good, I just don't like the occasional
> spikes...
> 
> 
> Mat Noguchi (BUNGIE) wrote:
> 
>>If you are both reading and decompressing on the IO thread, you are
>>likely causing a lot of context switches if you have not modified the
>>priority on either thread.
>>
>>MSN
> 

RE: [GD-General] responsive threading

[Mat N. \(BUNGIE\) <mat...@mi...>]

Unfortunately, there are many function calls that can cause stalls under
multithreading: mixing blocking and non-blocking file i/o, allocating
memory with malloc/free, CRT functions that manipulate global state,
etc.

MSN
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Andras Balogh
Sent: Friday, July 29, 2005 3:07 PM
To: gam...@li...
Subject: Re: [GD-General] responsive threading

I understand that, and I am thankful for your suggestions, but the=20
problem is that I don't really know what's going on in this=20
decompression library myself.. I was just assuming that whatever it=20
does, there is a way to make it not disturb my main thread.


Andras


Mat Noguchi (BUNGIE) wrote:
> Without knowing exactly what you are doing on both threads, it is very
> hard to determine the source of framerate spikes that are caused by
> multithreading.
>=20
> MSN
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Andras Balogh
> Sent: Friday, July 29, 2005 2:34 PM
> To: gam...@li...
> Subject: Re: [GD-General] responsive threading
>=20
> Even if this was the case, it would hurt overall performance, no?=20
> Overall performance is very good, I just don't like the occasional
> spikes...
>=20
>=20
> Mat Noguchi (BUNGIE) wrote:
>=20
>>If you are both reading and decompressing on the IO thread, you are
>>likely causing a lot of context switches if you have not modified the
>>priority on either thread.
>>
>>MSN
>=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_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

Re: [GD-General] responsive threading

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

Yeah, that's what I was thinking too, that this decompressing library 
makes some Win32 API calls, that result in the Windows kernel doing some 
system maintanence at a higher priority..

Mat Noguchi (BUNGIE) wrote:
> Unfortunately, there are many function calls that can cause stalls under
> multithreading: mixing blocking and non-blocking file i/o, allocating
> memory with malloc/free, CRT functions that manipulate global state,
> etc.

Re: [GD-General] responsive threading

[Beau A. <alb...@cy...>]

Mat makes a good point about MT memory allocations (and CRT).  We have 
ran into issues that stemmed from MT heap allocations in "huge" MT 
apps.  Probably a good place to start.

-Beau

Andras Balogh wrote:

> Yeah, that's what I was thinking too, that this decompressing library 
> makes some Win32 API calls, that result in the Windows kernel doing 
> some system maintanence at a higher priority..
>
> Mat Noguchi (BUNGIE) wrote:
>
>> Unfortunately, there are many function calls that can cause stalls under
>> multithreading: mixing blocking and non-blocking file i/o, allocating
>> memory with malloc/free, CRT functions that manipulate global state,
>> etc.
>
>
>
> -------------------------------------------------------
> 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=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

Re: [GD-General] responsive threading

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

Could you be a bit more specific? Should I try to decrease the number
of memory allocations? Should I try using a custom memory manager?
BTW: this is not "huge" app by any means, and it only uses two
threads, that's all..

Friday, July 29, 2005, 7:48:48 PM, you wrote:

> Mat makes a good point about MT memory allocations (and CRT).  We have
> ran into issues that stemmed from MT heap allocations in "huge" MT 
> apps.  Probably a good place to start.

> -Beau

> Andras Balogh wrote:

>> Yeah, that's what I was thinking too, that this decompressing library
>> makes some Win32 API calls, that result in the Windows kernel doing
>> some system maintanence at a higher priority..
>>
>> Mat Noguchi (BUNGIE) wrote:
>>
>>> Unfortunately, there are many function calls that can cause stalls under
>>> multithreading: mixing blocking and non-blocking file i/o, allocating
>>> memory with malloc/free, CRT functions that manipulate global state,
>>> etc.

Re: [GD-General] responsive threading

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

I'm loading lots of "small" (avg. 1k x 1k) regions from lots of huge 
(5GB+) wavelet compressed images. I'm using a 3rd party library to do 
this (ECW), so I don't know the implementation details, but I could look 
at the code, if I knew what to look for..



Andras


Mat Noguchi (BUNGIE) wrote:
> What else are you doing on the IO thread to make it eat up so much CPU
> time?
> 
> MSN
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Andras Balogh
> Sent: Friday, July 29, 2005 10:44 AM
> To: gam...@li...
> Subject: [GD-General] responsive threading
> 
> I'm developing a graphics application, that I want to be very 
> responsive, very smooth, all the time! The rendering is pretty simple, 
> the framerate is high and stable, so I just lock to vsync, and 
> everything moves beautifully smooth! The CPU usage for this thread is 
> always below 10%.
> 
> However, I also have another thread, that has to do some heavy work. 
> This thread does tons of IO operations, and also makes the CPU sweat!
> 
> There is no synchronization between the two threads, so they should be 
> able to run independently. Still, I'm experienceing sudden spikes in the
> 
> framerate, when the second thread is really hammering. What could be the
> 
> reason for this? Is it possible to do something about it, to regain the 
> continuous framerate? I'm really not interested in the performance of 
> the second thread, I just want my first thread to run as smooth as 
> possible! I've tried lowering the priority for the second thread, and it
> 
> does help, but there are still some spikes. Is it possible that it's 
> Windows itself doing some operations at higher priority, like memory 
> management, IO stuff, and the likes?
> 
> Thanks,
> 
> 
> Andras
> 
> 
> -------------------------------------------------------
> 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=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 
> 
> -------------------------------------------------------
> 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_id492&op=click
> _______________________________________________
> 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] responsive threading

[Brian H. <ho...@bo...>]

At the risk of asking the obvious, have you also set your primary 
thread to run at the highest priority (REAL_TIME or whatever it's 
called on Windows)?

I run audio mixing in a separate thread and by setting things 
appropriately (and sleeping when necessary) I never get hiccups.

Brian

On Fri, 29 Jul 2005 14:35:21 -0600, Andras Balogh wrote:
> I'm loading lots of "small" (avg. 1k x 1k) regions from lots of
> huge (5GB+) wavelet compressed images. I'm using a 3rd party
> library to do this (ECW), so I don't know the implementation
> details, but I could look at the code, if I knew what to look for..
>
>
> Andras
>
>
> Mat Noguchi (BUNGIE) wrote:
>> What else are you doing on the IO thread to make it eat up so
>> much CPU time?
>>
>> MSN
>> -----Original Message-----
>> From: gam...@li...
>> [mailto:gam...@li...] On
>> Behalf Of Andras Balogh Sent: Friday, July 29, 2005 10:44 AM To:
>> gam...@li... Subject: [GD-General]
>> responsive threading
>>
>> I'm developing a graphics application, that I want to be very
>> responsive, very smooth, all the time! The rendering is pretty
>> simple, the framerate is high and stable, so I just lock to
>> vsync, and everything moves beautifully smooth! The CPU usage for
>> this thread is always below 10%.
>>
>> However, I also have another thread, that has to do some heavy
>> work. This thread does tons of IO operations, and also makes the
>> CPU sweat!
>>
>> There is no synchronization between the two threads, so they
>> should be able to run independently. Still, I'm experienceing
>> sudden spikes in the
>>
>> framerate, when the second thread is really hammering. What could
>> be the
>>
>> reason for this? Is it possible to do something about it, to
>> regain the continuous framerate? I'm really not interested in the
>> performance of the second thread, I just want my first thread to
>> run as smooth as possible! I've tried lowering the priority for
>> the second thread, and it
>>
>> does help, but there are still some spikes. Is it possible that
>> it's Windows itself doing some operations at higher priority,
>> like memory management, IO stuff, and the likes?
>>
>> Thanks,
>>
>>
>> Andras
>>
>>
>> ------------------------------------------------------- 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
>>
>>
>> ------------------------------------------------------- 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_id492&op=3Dclick
>> _______________________________________________ Gamedevlists-
>> general mailing list Gam...@li...
>> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
>> Archives:
>> http://sourceforge.net/mailarchive/forum.php?forum_idU7
>
>
> ------------------------------------------------------- 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

Re: [GD-General] responsive threading

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

I've tried setting the primary thread to time critical and the other 
thread to idle (and I also disabled it's priority boost), and it does 
help quite a bit, but I'm still seeing some small glitches. I'm not 
saying it's bad, it's pretty good actually, and people are so used to 
bad framerates nowadays that I'm sure they wouldn't complain a tiny bit. 
I do admit that I'm a bit on the perfectionist side on this one :)

I have tried setting the process priority class to real-time too, but in 
that case my "idle" priority thread won't be really idle anymore, 
actually, the hiccups get much worse. I guess I could run in a separate 
process even, but that's really overkill.


Andras

Brian Hook wrote:
> At the risk of asking the obvious, have you also set your primary 
> thread to run at the highest priority (REAL_TIME or whatever it's 
> called on Windows)?
> 
> I run audio mixing in a separate thread and by setting things 
> appropriately (and sleeping when necessary) I never get hiccups.
> 
> Brian
> 
> On Fri, 29 Jul 2005 14:35:21 -0600, Andras Balogh wrote:
> 
>>I'm loading lots of "small" (avg. 1k x 1k) regions from lots of
>>huge (5GB+) wavelet compressed images. I'm using a 3rd party
>>library to do this (ECW), so I don't know the implementation
>>details, but I could look at the code, if I knew what to look for..
>>
>>
>>Andras
>>
>>
>>Mat Noguchi (BUNGIE) wrote:
>>
>>>What else are you doing on the IO thread to make it eat up so
>>>much CPU time?
>>>
>>>MSN
>>>-----Original Message-----
>>>From: gam...@li...
>>>[mailto:gam...@li...] On
>>>Behalf Of Andras Balogh Sent: Friday, July 29, 2005 10:44 AM To:
>>>gam...@li... Subject: [GD-General]
>>>responsive threading
>>>
>>>I'm developing a graphics application, that I want to be very
>>>responsive, very smooth, all the time! The rendering is pretty
>>>simple, the framerate is high and stable, so I just lock to
>>>vsync, and everything moves beautifully smooth! The CPU usage for
>>>this thread is always below 10%.
>>>
>>>However, I also have another thread, that has to do some heavy
>>>work. This thread does tons of IO operations, and also makes the
>>>CPU sweat!
>>>
>>>There is no synchronization between the two threads, so they
>>>should be able to run independently. Still, I'm experienceing
>>>sudden spikes in the
>>>
>>>framerate, when the second thread is really hammering. What could
>>>be the
>>>
>>>reason for this? Is it possible to do something about it, to
>>>regain the continuous framerate? I'm really not interested in the
>>>performance of the second thread, I just want my first thread to
>>>run as smooth as possible! I've tried lowering the priority for
>>>the second thread, and it
>>>
>>>does help, but there are still some spikes. Is it possible that
>>>it's Windows itself doing some operations at higher priority,
>>>like memory management, IO stuff, and the likes?
>>>
>>>Thanks,
>>>
>>>
>>>Andras

Re: [GD-General] responsive threading

[Alen L. <ale...@cr...>]

If the higher priority thread never ever waits, windows go out of their way 
and give some time to the lower priority thread in that case. Search 
"priority inversion" in MSDN. Perhaps sleeping a bit once in a while in the 
rendering thread to give a slice to the processing thread, might help you 
keep the situation under control.

HTH,
Alen

----- Original Message ----- 
From: "Andras Balogh" <and...@gm...>
To: <gam...@li...>
Sent: Friday, July 29, 2005 21:22
Subject: Re: [GD-General] responsive threading


> I've tried setting the primary thread to time critical and the other 
> thread to idle (and I also disabled it's priority boost), and it does help 
> quite a bit, but I'm still seeing some small glitches. I'm not saying it's 
> bad, it's pretty good actually, and people are so used to bad framerates 
> nowadays that I'm sure they wouldn't complain a tiny bit. I do admit that 
> I'm a bit on the perfectionist side on this one :)
>
> I have tried setting the process priority class to real-time too, but in 
> that case my "idle" priority thread won't be really idle anymore, 
> actually, the hiccups get much worse. I guess I could run in a separate 
> process even, but that's really overkill.
>
>
> Andras
>
> Brian Hook wrote:
>> At the risk of asking the obvious, have you also set your primary thread 
>> to run at the highest priority (REAL_TIME or whatever it's called on 
>> Windows)?
>>
>> I run audio mixing in a separate thread and by setting things 
>> appropriately (and sleeping when necessary) I never get hiccups.
>>
>> Brian
>>
>> On Fri, 29 Jul 2005 14:35:21 -0600, Andras Balogh wrote:
>>
>>>I'm loading lots of "small" (avg. 1k x 1k) regions from lots of
>>>huge (5GB+) wavelet compressed images. I'm using a 3rd party
>>>library to do this (ECW), so I don't know the implementation
>>>details, but I could look at the code, if I knew what to look for..
>>>
>>>
>>>Andras
>>>
>>>
>>>Mat Noguchi (BUNGIE) wrote:
>>>
>>>>What else are you doing on the IO thread to make it eat up so
>>>>much CPU time?
>>>>
>>>>MSN
>>>>-----Original Message-----
>>>>From: gam...@li...
>>>>[mailto:gam...@li...] On
>>>>Behalf Of Andras Balogh Sent: Friday, July 29, 2005 10:44 AM To:
>>>>gam...@li... Subject: [GD-General]
>>>>responsive threading
>>>>
>>>>I'm developing a graphics application, that I want to be very
>>>>responsive, very smooth, all the time! The rendering is pretty
>>>>simple, the framerate is high and stable, so I just lock to
>>>>vsync, and everything moves beautifully smooth! The CPU usage for
>>>>this thread is always below 10%.
>>>>
>>>>However, I also have another thread, that has to do some heavy
>>>>work. This thread does tons of IO operations, and also makes the
>>>>CPU sweat!
>>>>
>>>>There is no synchronization between the two threads, so they
>>>>should be able to run independently. Still, I'm experienceing
>>>>sudden spikes in the
>>>>
>>>>framerate, when the second thread is really hammering. What could
>>>>be the
>>>>
>>>>reason for this? Is it possible to do something about it, to
>>>>regain the continuous framerate? I'm really not interested in the
>>>>performance of the second thread, I just want my first thread to
>>>>run as smooth as possible! I've tried lowering the priority for
>>>>the second thread, and it
>>>>
>>>>does help, but there are still some spikes. Is it possible that
>>>>it's Windows itself doing some operations at higher priority,
>>>>like memory management, IO stuff, and the likes?
>>>>
>>>>Thanks,
>>>>
>>>>
>>>>Andras
>
>
> -------------------------------------------------------
> 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=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] responsive threading

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

I do wait in the higher priority thread. Actually, this thread spends
90% of the frame time waiting (for vsync)! So the idle thread has
plenty of time, and despite the lower priority, it gets a lot more
CPU, than my primary thread!


Saturday, July 30, 2005, 6:40:15 AM, you wrote:

> If the higher priority thread never ever waits, windows go out of their way
> and give some time to the lower priority thread in that case. Search
> "priority inversion" in MSDN. Perhaps sleeping a bit once in a while in the
> rendering thread to give a slice to the processing thread, might help you
> keep the situation under control.

> HTH,
> Alen

> ----- Original Message ----- 
> From: "Andras Balogh" <and...@gm...>
> To: <gam...@li...>
> Sent: Friday, July 29, 2005 21:22
> Subject: Re: [GD-General] responsive threading


>> I've tried setting the primary thread to time critical and the other
>> thread to idle (and I also disabled it's priority boost), and it does help
>> quite a bit, but I'm still seeing some small glitches. I'm not saying it's
>> bad, it's pretty good actually, and people are so used to bad framerates
>> nowadays that I'm sure they wouldn't complain a tiny bit. I do admit that
>> I'm a bit on the perfectionist side on this one :)
>>
>> I have tried setting the process priority class to real-time too, but in
>> that case my "idle" priority thread won't be really idle anymore, 
>> actually, the hiccups get much worse. I guess I could run in a separate
>> process even, but that's really overkill.
>>
>>
>> Andras
>>
>> Brian Hook wrote:
>>> At the risk of asking the obvious, have you also set your primary thread
>>> to run at the highest priority (REAL_TIME or whatever it's called on
>>> Windows)?
>>>
>>> I run audio mixing in a separate thread and by setting things 
>>> appropriately (and sleeping when necessary) I never get hiccups.
>>>
>>> Brian
>>>
>>> On Fri, 29 Jul 2005 14:35:21 -0600, Andras Balogh wrote:
>>>
>>>>I'm loading lots of "small" (avg. 1k x 1k) regions from lots of
>>>>huge (5GB+) wavelet compressed images. I'm using a 3rd party
>>>>library to do this (ECW), so I don't know the implementation
>>>>details, but I could look at the code, if I knew what to look for..
>>>>
>>>>
>>>>Andras
>>>>
>>>>
>>>>Mat Noguchi (BUNGIE) wrote:
>>>>
>>>>>What else are you doing on the IO thread to make it eat up so
>>>>>much CPU time?
>>>>>
>>>>>MSN
>>>>>-----Original Message-----
>>>>>From: gam...@li...
>>>>>[mailto:gam...@li...] On
>>>>>Behalf Of Andras Balogh Sent: Friday, July 29, 2005 10:44 AM To:
>>>>>gam...@li... Subject: [GD-General]
>>>>>responsive threading
>>>>>
>>>>>I'm developing a graphics application, that I want to be very
>>>>>responsive, very smooth, all the time! The rendering is pretty
>>>>>simple, the framerate is high and stable, so I just lock to
>>>>>vsync, and everything moves beautifully smooth! The CPU usage for
>>>>>this thread is always below 10%.
>>>>>
>>>>>However, I also have another thread, that has to do some heavy
>>>>>work. This thread does tons of IO operations, and also makes the
>>>>>CPU sweat!
>>>>>
>>>>>There is no synchronization between the two threads, so they
>>>>>should be able to run independently. Still, I'm experienceing
>>>>>sudden spikes in the
>>>>>
>>>>>framerate, when the second thread is really hammering. What could
>>>>>be the
>>>>>
>>>>>reason for this? Is it possible to do something about it, to
>>>>>regain the continuous framerate? I'm really not interested in the
>>>>>performance of the second thread, I just want my first thread to
>>>>>run as smooth as possible! I've tried lowering the priority for
>>>>>the second thread, and it
>>>>>
>>>>>does help, but there are still some spikes. Is it possible that
>>>>>it's Windows itself doing some operations at higher priority,
>>>>>like memory management, IO stuff, and the likes?
>>>>>
>>>>>Thanks,
>>>>>
>>>>>
>>>>>Andras

Re: [GD-General] responsive threading

[Alen L. <ale...@cr...>]

Are you sure that waiting for vsync gives out time? This depends on driver 
and API used, but usually, it is just a busy waiting loop. IIRC, we had to 
jump through some nasty hoops to make our swaps actually yield time to our 
loading thread. YMMV.

Alen


----- Original Message ----- 
From: "Andras Balogh" <and...@gm...>
To: "Alen Ladavac" <gam...@li...>
Sent: Sunday, July 31, 2005 14:51
Subject: Re: [GD-General] responsive threading


>I do wait in the higher priority thread. Actually, this thread spends
> 90% of the frame time waiting (for vsync)! So the idle thread has
> plenty of time, and despite the lower priority, it gets a lot more
> CPU, than my primary thread!
>
>
> Saturday, July 30, 2005, 6:40:15 AM, you wrote:
>
>> If the higher priority thread never ever waits, windows go out of their 
>> way
>> and give some time to the lower priority thread in that case. Search
>> "priority inversion" in MSDN. Perhaps sleeping a bit once in a while in 
>> the
>> rendering thread to give a slice to the processing thread, might help you
>> keep the situation under control.
>
>> HTH,
>> Alen
>
>> ----- Original Message ----- 
>> From: "Andras Balogh" <and...@gm...>
>> To: <gam...@li...>
>> Sent: Friday, July 29, 2005 21:22
>> Subject: Re: [GD-General] responsive threading
>
>
>>> I've tried setting the primary thread to time critical and the other
>>> thread to idle (and I also disabled it's priority boost), and it does 
>>> help
>>> quite a bit, but I'm still seeing some small glitches. I'm not saying 
>>> it's
>>> bad, it's pretty good actually, and people are so used to bad framerates
>>> nowadays that I'm sure they wouldn't complain a tiny bit. I do admit 
>>> that
>>> I'm a bit on the perfectionist side on this one :)
>>>
>>> I have tried setting the process priority class to real-time too, but in
>>> that case my "idle" priority thread won't be really idle anymore,
>>> actually, the hiccups get much worse. I guess I could run in a separate
>>> process even, but that's really overkill.
>>>
>>>
>>> Andras
>>>
>>> Brian Hook wrote:
>>>> At the risk of asking the obvious, have you also set your primary 
>>>> thread
>>>> to run at the highest priority (REAL_TIME or whatever it's called on
>>>> Windows)?
>>>>
>>>> I run audio mixing in a separate thread and by setting things
>>>> appropriately (and sleeping when necessary) I never get hiccups.
>>>>
>>>> Brian
>>>>
>>>> On Fri, 29 Jul 2005 14:35:21 -0600, Andras Balogh wrote:
>>>>
>>>>>I'm loading lots of "small" (avg. 1k x 1k) regions from lots of
>>>>>huge (5GB+) wavelet compressed images. I'm using a 3rd party
>>>>>library to do this (ECW), so I don't know the implementation
>>>>>details, but I could look at the code, if I knew what to look for..
>>>>>
>>>>>
>>>>>Andras
>>>>>
>>>>>
>>>>>Mat Noguchi (BUNGIE) wrote:
>>>>>
>>>>>>What else are you doing on the IO thread to make it eat up so
>>>>>>much CPU time?
>>>>>>
>>>>>>MSN
>>>>>>-----Original Message-----
>>>>>>From: gam...@li...
>>>>>>[mailto:gam...@li...] On
>>>>>>Behalf Of Andras Balogh Sent: Friday, July 29, 2005 10:44 AM To:
>>>>>>gam...@li... Subject: [GD-General]
>>>>>>responsive threading
>>>>>>
>>>>>>I'm developing a graphics application, that I want to be very
>>>>>>responsive, very smooth, all the time! The rendering is pretty
>>>>>>simple, the framerate is high and stable, so I just lock to
>>>>>>vsync, and everything moves beautifully smooth! The CPU usage for
>>>>>>this thread is always below 10%.
>>>>>>
>>>>>>However, I also have another thread, that has to do some heavy
>>>>>>work. This thread does tons of IO operations, and also makes the
>>>>>>CPU sweat!
>>>>>>
>>>>>>There is no synchronization between the two threads, so they
>>>>>>should be able to run independently. Still, I'm experienceing
>>>>>>sudden spikes in the
>>>>>>
>>>>>>framerate, when the second thread is really hammering. What could
>>>>>>be the
>>>>>>
>>>>>>reason for this? Is it possible to do something about it, to
>>>>>>regain the continuous framerate? I'm really not interested in the
>>>>>>performance of the second thread, I just want my first thread to
>>>>>>run as smooth as possible! I've tried lowering the priority for
>>>>>>the second thread, and it
>>>>>>
>>>>>>does help, but there are still some spikes. Is it possible that
>>>>>>it's Windows itself doing some operations at higher priority,
>>>>>>like memory management, IO stuff, and the likes?
>>>>>>
>>>>>>Thanks,
>>>>>>
>>>>>>
>>>>>>Andras
>
>
>
> -------------------------------------------------------
> 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=7477&alloc_id=16492&op=click
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [GD-General] responsive threading

[Brian H. <ho...@bo...>]

On Sun, 31 Jul 2005 19:49:46 -0000, Alen Ladavac wrote:
> Are you sure that waiting for vsync gives out time? 

That's what I'm thinking as well -- Andras, maybe disable vsync and 
see how it performs first.  The problem right now is that you haven't 
really eliminated enough variables for people to work with.  Disabling 
vsync is one, and unfortunately the black box nature of the library 
you're using is another.

Brian

Re: [GD-General] responsive threading

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

Hmm, but when I don't call into that library, then the CPU usage for my 
rendering thread is below 10%! I would think that if I have a busy loop, 
then the CPU would be at 100%, no?

Anyway, I've tried disabling vsync, and surprisingly, there's not much 
difference (except from the tearing). I have no idea why, because now 
the CPU is really at 100% all the time... Although I have to admit that 
it's a bit hard to see the improvement/worsening, because this is not 
something I can measure, so it's totally subjective, and with the 
tearing on screen it's even harder to tell what's going on.

Just to repeat, these spikes are not too bad, only happens like every 
couple seconds, and only maybe for an eight of a second. I guess if my 
app would run at 10fps constant, you'd never even notice.

Hmm, now I've put in some extra sleeps, just for kicks, and it does feel 
a tiny bit more smooth. But again, it's very subjective :)

BTW: I don't think I've ever seen any app handling this amount of data 
without any hiccups (if you happen to know of one, then please let me 
know!), so I'm pretty pleased with the results already. Of course, if 
it's possible to do better, then I'd love to make it better! :P

As for the unknown variables, and black boxes, I'm afraid there'll 
always be some. The driver and Windows itself are just two examples. And 
as we will develop more and more complex applications, we will have to 
integrate more and more off the shelf solutions into our product. I 
think this is something we just have to learn to deal with. Hmm, this 
reminds me of a library I've seen recently, which, when encounters an 
error, just calls exit(-1)!! ==:-O

cheers,


Andras


Brian Hook wrote:
> On Sun, 31 Jul 2005 19:49:46 -0000, Alen Ladavac wrote:
> 
>>Are you sure that waiting for vsync gives out time? 
> 
> 
> That's what I'm thinking as well -- Andras, maybe disable vsync and 
> see how it performs first.  The problem right now is that you haven't 
> really eliminated enough variables for people to work with.  Disabling 
> vsync is one, and unfortunately the black box nature of the library 
> you're using is another.
> 
> Brian

Re: [GD-General] responsive threading

[Ivan-Assen I. <iva...@gm...>]

Andras, can you experiment with varying the processing thread's workload?=
=20
E.g. change it to computations only, or I/O only, e.g. feed it uncompressed=
=20
data etc.? That could give you an insight in what's causing it to receive=
=20
more CPU time.

Re: [GD-General] responsive threading

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

No, not really.. :(

I could write something myself, that hammers the CPU, the memory and the 
disk, together and separately, but I don't think I'll have a timeslice 
for that now. I'm in a busy loop. :)


Ivan-Assen Ivanov wrote:
> Andras, can you experiment with varying the processing thread's workload? 
> E.g. change it to computations only, or I/O only, e.g. feed it uncompressed 
> data etc.? That could give you an insight in what's causing it to receive 
> more CPU time.
>