Hello,
I forgot to mention that
I am paging dxt5 compressed ive files converted from OpenFlight.
Since the performance is
so bad at times, and it seems like it is because of heavy I/O operations, is it
possible that Windows is using blocking I/O operations when reading files?
This would explain why the threads don't take their scheduled times. Does
anybody know if there is a way to specify non-blocking I/O. Any
suggestions? I'm no expert on the istream C++ class. Is anybody
else?
Thanks.
Zach
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Burns
Sent: Friday, August 18, 2006 16:57
To: osg users
Subject: Re: [osg-users] Paging performance on Windows
I'm happy to hear your approach on this problem. The reason I ask why, is that my constant experience with OS's from microsoft is that they consistently perform at sub optimal levels. This is after 16 years of testing. My position is not "religious", it is simply an expectation I have come to accept based on technical experiences.
If you can accept that Windows will not load a file as fast as a UNIX based file system (which is my constant conclusion), but are constrained to continue to build on Windows, then you can start to tune your application, not with the goal of trying to match Linux performance, but with the goal of getting the best performance you can from a Windows system. This will probably mean that you will need to pay more attention to the size of tile blocks that are being paged at any given time. Consider that developers of games that appear to perform well on Windows have probably gone through this painful process already.
The other experience I have under Windows is that of poor thread management performance. UNIX has been an OS that was designed from the ground up to multi-task and has decades of refinements for schedulers. I tend to trust them more in these environments.
One of the behaviors I've come to recognize as a significant difference between Linux/UNIX and Windows based systems is that of I/O. Windows will literally freeze when heavy I/O is occuring, until it is done. This is not so (as much, at least) with Linux/UNIX systems. Even in a threaded environment, when you should have cooperation between separate threads, if I/O decides to take over the system, including the blocking of thread and process schedulers, then there is literally nothing you can do. You have to force the cooperation by limiting your I/O operations to minimize the time spent during data transfers.
I think that if you take a stance which does not accept the limitations of Windows as a real-time system you will limit your options. If you accept it then you can work around it.
-don
On 8/18/06, Zach
Deedler <[EMAIL PROTECTED]> wrote:
Hi Don,
Why am I unwilling to accept that it is a limitation in the OS?
1) The paging thread is virtually taking over the processor for periods of
multiple seconds.
2) I know games can page data on a Windows OS with out this problem.
Just from my investigations in graphing processor time for the threads. I
can see the paging thread virtually taking over the processor for multiple
seconds. From the graphs, I know that the main thread still gets some time
during those seconds. I know that if the paging thread was told to sleep
for awhile then the hitching problem would not look so bad. When no
hitching is occuring, the paging thread takes no more than 30% of the proc.
Somehow the paging thread is given almost full control of the processor for
a period of multiple seconds. Even if an atomic operation on Windows took 1
full second, I should be able to code around this to get better performance
(sleep on the thread that needs one second). Given the fact that I'm using
a dual-core processor should also help.
If reading one file is an atomic action in Windows, then I am willing to
accept this issue is an OS issue. Otherwise, someone will have to prove it
to me. I'm not saying that Linux won't outperform Windows with disk access,
and I am by no means promoting Windows over Linux. I'm just trying to get
better performance out of my paged database on a Windows system. I am
confident this can be done if I can narrow down the operations that are
taking soo long without the main thread noticing and accounting for it.
>From: "Don Burns" < [EMAIL PROTECTED]>
>Reply-To: osg users <osg-users@openscenegraph.net>
>To: "osg users" < osg-users@openscenegraph.net>
>Subject: Re: [osg-users] Paging performance on Windows
>Date: Thu, 17 Aug 2006 10:33:17 -0700
>
>On 8/16/06, Zach Deedler < [EMAIL PROTECTED]> wrote:
>>
>>
>>5) Given TRIAL4, seems like a #ifdef WIN32 problem, or limitation
>>in the
>>OS
>>(I'm still unwilling to accept this)
>
>
>
>why ?
>_______________________________________________
>osg-users mailing list
>osg-users@openscenegraph.net
> http://openscenegraph.net/mailman/listinfo/osg-users
>http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
osg-users@openscenegraph.net
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
