Mal wieder: Aufrüsten für den FS9: Dual Core oder nicht?

Beim Flusi nicht, denn Martin hatte so einen auch zum Testen da ...

Gerhard

[fs2002-friend]

Leute Leute, wo kriegt ihr diese neuen Sachen nur immer wieder her

Hat das Motherboard die CPU unterstützt?

Hm, muss ich ihn fragen, darauf hab ich nicht geachtet (weil ich mich inzwischen mit 5 fps auf meinem Rechner herumschlagen muss - bei allen Reglern max. Mitte im FS X), aber er ist nicht mehr da ... und ich geh jetzt auch endlich
Auf der Homepage vom WCM gibt es dazu sicherlich immer wieder was zu lesen, ich glaub, er hat sowieso auch Tabellen raufgestellt von Tests für den WCM. Der Test für uns mit dem Flusi lief ja nur nebenher mit.

Schönen Abend!
Gerhard

[Stefan Söllner]

Original geschrieben von fs2002-friend
Leute Leute, wo kriegt ihr diese neuen Sachen nur immer wieder her

Hat das Motherboard die CPU unterstützt?

Ein 965/975X Chipsatz auf dem Mainboard und ein Bios Update sollte reichen, damit die Kentsfield CPUs laufen.

Auf dem Mac Pro läuft ein Austausch von (Intel) Dual Dual-Cores zu Dual Quad-Cores auch.

[Kai-Uwe Weiß]

hallo Dieter,

besagtes Asrock-Bord hat einen AGP-Slot.

mfg Kai

[dunix]

Genauso ist es, das ASROCK 775I65G R2.0 hat einen AGP Slot (allerdings nur für AGP Karten bis zu 1,6 V!!!) und unterstützt den INTEL Core 2 Duo E6600 zusammen mit DDR400 RAMs. Werde mir die Komponenten kaufen und dann berichten, wie das Ergebnis ist.

Frank

[ramteid]

einfach mal lesen...:

http://blogs.msdn.com/tdragger/default.aspx

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.