Forum Home
Press F1
Thread ID: 72248	2006-09-05 18:28:00	CPU disagreement	JJJJJ (528)	Press F1

Post ID	Timestamp	Content	User
482838	2006-09-06 03:23:00	Hey JJJJJ pm me if you wanna give a poor starving student your dual core cpu, it would be a great help for my graphics programs! :p I'll give you my AMD 2600 + in return :rolleyes:	bizzack (7739)
482839	2006-09-06 05:16:00	The Last Word on Dual Core Well, my last word, anyway. It seems there's quite a bit of anxiety on the FS boards about whether or not FSX will "take advantage of" multi-core CPUs. I've tried to provide some explanation but it's quickly drowned out by the waves of claims, opinions and speculation. So I thought I'd try one last time to explain the real deal. After this, I'm done. First off, let's just all own up to the fact that multi-core CPUs technology is no silver-bullet magic voodoo that automatically gives you twice (or four times) the performance of a single-core CPU on all applications. Despite the hopes on many 20th century authors and futurists we do not yet have "thinking" computers that can look at an application, figure out what the programmer meant for it to do, and automatically optimize it to make it work faster. The programmers gotta do the work. And that work ain't easy for a game where you need to spit convincing images to the screen dozens of times each second. So what, really, needs to be done? Simply put the programmer needs to divide up computational tasks in such a way that the operating system can "farm out" the work to multiple CPUs. In computer parlance these are known as "threads". The notion of so-called "multithreaded" applications is nothing new since multiple CPU PCs have been around for quite some time. It's only recently, with the advent of multi-core CPUs bringing multi-CPU computing to the masses, that the topic has garnered much interest from gamers. What makes programming a multithreaded application, especially a game, difficult is the interdependecies between tasks. For example, take AI aircraft in FS. I can't count the number of times I've read "why can't FS just use the second CPU for AI traffic?" Well, what's involved in rendering AI? For one thing the AI occasionally need to know "am I on the ground?" For that, some process has to be able to figure out where the ground is--i.e., the terrain system. There's one interdependency right there. Another interdependcy is the AI's use of ATC. ATC needs to track the AI planes as well as the user's aircraft. And the list goes on and on. The net result is that, no matter how many threads a program creates in an attempt to "take advantage" of multiple CPUs, at some point the work on one thread is going to have to stop and wait for something else, likely on another thread, to happen. This is especially true for a game where the application needs to update the screen. Server-applications that can treat requests independently from one another are less affected. Suppose, for example, that AI rendering was delegated to a thread that was dependent on the terrain system on yet another thead to provide it with infomation. What happens when it comes time to render the AI's position? Do you wait indefintely for the terrain system? If you wait too long you'll see a stutter. Do you simply not render the AI but rendering everything else? Not unless you want the AI to appear and disappear and jump around the screen. Hopefully you can see that a multithreaded game like FSX consists of a numerous start, wait, and complete sequences. The big problem here is that when you get too many of these then nothing gets done because everything is waiting on everything else. So where can you use multiple threads? You use it where the interdepencies are loose and indeterminate wait times aren't readily noticable. In FSX we use multiple thread for texture decompression and certain types of file I/O. Consider terrain textures that must be loaded and decompressed as you fly along. Normally new textures are needed for the area at the edge of the visual scene. Using low-resolution versions for the initial display and then loading higher resolutions in the background works because texture swapping in the distance is not very noticable. In other words, it doesn't a matter if a texture is available immediately or several frames after it's requested because you likely won't notice the delay. The good news is that these threads can be "farmed out" by the OS scheduler to multiple CPUs or cores. The bad news is that requests are made with varying frequency so the overall CPU utilization will also vary. In other words, those of you running the FSX demo and looking for 100% utilization on all your cores can just stop--you're not going to see it. You'll see a lot of utilization when you first load a flight (and we force requests to complete) and less as you fly along. As we continue to evolve the code base we'll continue to look for areas where thread offloading makes sense but changes in the area can have unexpected results so it will take time to decide what works best. And, oh, when you find a game that does use all that horsepower all the time, please let me know. This is from one of the MS guys who is working on FSX. Trevor :)	Trev (427)
482840	2006-09-06 05:32:00	Sooner or later some smart game developer is going to realise that they could make an enormous improvement to the performance of any computer when their game is running . All that would be needed is a small stub to shut down the OS, then load and run the game programme . As well as the problems of multithreading mentioned in that article quoted by Trev, the game developers have to cope with the fact that the OS is trying to do things too . So a game thread might be waiting for an OS thread to complete . Games are realtime applications . Realtime stuff has always been best handled as the only programme running . That way, you can be sure that any timing or synchronisation problems are your own fault . :D I doubt if my hypothetical game developer would work for Microsoft . (Or not for long after this realisation) ;)	Graham L (2)
482841	2006-09-06 06:45:00	Sooner or later some smart game developer is going to realise that they could make an enormous improvement to the performance of any computer when their game is running . All that would be needed is a small stub to shut down the OS, then load and run the game programme . As well as the problems of multithreading mentioned in that article quoted by Trev, the game developers have to cope with the fact that the OS is trying to do things too . So a game thread might be waiting for an OS thread to complete . Games are realtime applications . Realtime stuff has always been best handled as the only programme running . That way, you can be sure that any timing or synchronisation problems are your own fault . :D I doubt if my hypothetical game developer would work for Microsoft . (Or not for long after this realisation) ;) The operating system is necessary . From this comment you clearly have no idea exactly how much it is doing under the scenes and exactly how much of that is necessary to get that pretty image on your screen . The small overhead is well worth the price . Games are not hard realtime applications . They must be able to produce frames at a frequency of about 30Hz to appear realistic . Games will suffer if the computer is under significant load, but will get 95%+ of the CPU power otherwise . An operating system with a decent scheduler will allow for programs that require high computational power and will ensure that they get it . Getting back to the point, the game threads never have to synchronize with OS threads . This is simply because the threads don't communicate directly and can work separately without any issues . The hassles come when threads need to access shared information . When two threads try to access a resource at once, the second has to wait until the first is finished . If a programmer allows two threads simultaneous access to a resource and one changes it problems can occur . Threads are often very difficult to debug .	TGoddard (7263)
482842	2006-09-06 07:11:00	No thread can run unless there's a CPU available to run it . The OS uses a CPU when it does something . An OS "with a decent scheduler . . . " will ensure that a task gets CPU time when it needs it . This is Windows . Windows will ensure that Windows gets CPU time when it wants it . Yes, threads are always hard to debug . That's because they are realtime things, and it's usually impossible to ever exactly reproduce the conditions . That's why realtime applications run best on a "no-OS" or minimal OS machines . You have enough trouble with your own code, without the problems produced by the armies of MS coders . What does the OS provide to a game? A file system . It's easy enough to handle files . The video display . It's not imposible to reproduce the calls to the video manufacturer's video driver . Access to a keyboard, or a mouse . Big deal . What does the OS take? Memory . Lots and lots of memory . Lots of CPU time . On a range of machines from PCs to fairly large mainframes, maintaining the OS clock took about 2% of the CPU time . I've measured that . That's a very small part of the inessentials that an OS considers essential . I once wrote a programme to be run before starting a RT programme on a PDP-11 . Start: BIC #100, @#177560 END Start That turned off the clock interrupt of the OS . We needed that time . The games might need to provide only 30 or so frames/sec . But it takes a hell of a lot of computation to do that . With 95% of the CPU, that's 95% of the time left after the monitoring and other "invisible" bits of the OS have taken what they need . No modern OS is a "small overhead" . Look at the speed of the CPU on a dedicated games console, compared with the required speed of a PC CPU running the same game at the same "to the user" speed . There's the effect of OSs .	Graham L (2)
1 2