Archived

This topic is now archived and is closed to further replies.

TacomaSailor

FSX & Multi?Threading - QUAD cores - Is there DATA??

Recommended Posts

The statement, concerning the solution to blurries, was made on another thread: "Try flying at 300knots at tree top level on your dual, then toss in a quad and do the same test. You will see the quad loads textures much better, perhaps twice as fast. For a guy flying at 30k a dual is probably fine, but for a guy like me who flies low and fast, a quad is the only way to go."I responded "Can you please show us the CPU utilization per processor and per FSX thread while "flying at 300knots at tree top level " on a quad core machine. A copy of the output from something like ProcessExplorer or xperf would certainly settle the question about the ability of FSX to schedule four threads SIMULTANEOUSLY. I would like to see processor activity sampled at a slow rate (once per 5 seconds) but measured over a minute or so. A slow sample rate will not skew the results due to sampling driving a core and a long sample period will demonstrate the ability to keep four processors running on a regular basis for a significant period. I am interested in your results because I am thinking of upgrading my processor and need some MEASURED data to compare fast clocks to multiple processors. Multiple processors are of little value if FSX can not schedule threads to them on a regular and significant basis. My system is an E6600/4GB / 8800GTS(175.19) /RAID0 dedicated to FSX / RAID0 dedicated to Vista32/SP1 / FSX/Accel/SP2 Real life data would be very helpful."Here is my first attempt at demonstrating what we need to determine the utility and efficacy of multi-core processors when running FSX:I started FSX and placed a King Air 350 on the 34 runway at KTIW. I took off and flew the plane for 820 seconds toward and over Seattle and then SE toward Mount Ranier. My altitude (after gearup) varied from 1000 to 10,000 and the speed varied from 140 to 280 knots. Almost all options were set to Max, and I was using DX10 Preview and GEX. I used xperf to trace CPU usage by thread in FSX. I started the xperf EasyDiag trace after the KingAir was running and situated for takeoff. I stopped xperf trace after 820 seconds while at 10,000 feet and 210 knots. During the test my framerate varied between 22 and 35 FPS. I used the VC, 2-D cockpit, and a lot of outside views where I did 360 degree pans to show lots of scenery. The xperf analyzer provided the following data: The fsx.exe thread used 88.82 % of the available CPU cycles for ONE (1) of the two processors in my E6600. The api.dll thread used 61.08% of the available CPU cycles for ONE (1) of the two processors. Other threads and their percentage of ONE processor usage are: Nvwgf2um.dll 4.92% Dsound.dll 1.86% . The other 17 threads used by FSX used a total of 1.35% of a single processor. That means that during the 820 second test session the main FSX thread was running only about 89% of the time and a second thread was running only about 69% of the time. If you multiple those two probabilities together you can see that FSX was using CPU cycles on TWO processors only 61% of the time. The audiodg.exe process used 4.64% of ONE processor. Here is what Larry Ostermann says:

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Good start. Now go to the Avsim library and get the FSX benchmarker flight. FSX > Utilities then search "benchmark." Run that. "Settings kinda high" will Not do it. 1st, shut off DX10 and then provide your precise settings. We'll see how that goes first.This drill requires that an observer accept that simply increased CPU activity accurately represents better scenery loading performance. There will be no visual representations available.

Share this post


Link to post
Share on other sites

I went from an E6850 to a QX9650. I can tell you from first hand experience that a quad core makes a big difference on texture loading (consistently sharp and clear textures) although overall framerates between the two processors are comparable.You can beleive me or choose not to. My time is very limited these days and I'm not gonna be wasting it on benchmarking.

Share this post


Link to post
Share on other sites

Here's a quick look at that benchmark run. The first hump is the flight load. That was the other function that was optimized for multicores. Sim stuff really loads quick. The second hump is downtown Seattle coming into view.The third hump is KBFIand the fourth is KSEA. Don't know what else might prove the case. Took a look at that command function. I'll pass on that one, thanks!http://forums.avsim.net/user_files/190775.jpg

Share this post


Link to post
Share on other sites

I will do as you request with the FSX benchmark - I have an extensive set of tests run while using the benchmark to determine the benefit of overclocking my E6600. (It currently is very stable at 3.24 GHz)However- I think you are missing the point of what I am trying to test. I am not trying to test or demonstrate the advantage of using a QUAD core processor - although that would be nice to know. I'll be glad to research that question in the future. I am only asking the question "Can FSX/Acceration/SP2 consistently schedule more than two CONCURRENT threads for SIMULTANEOUS execution?" To demonstrate that we need a millisecond by millisecond CONCURRENT trace of the thread dispatch status (name & status) on each processor. Is it actually the case that at a given moment four separate threads are running on four separate processors? I have been professionally working the mutlithread/multi-processor issue from a OS scheduler perspective for over 30 years. I am just trying to gain more specific data about the ability of my favorite game to exploit recent and expensive AMD/Intel processor technology. I am definitely not trying to argue the case one way or another - I just want data at a very fine level of detail. It would be nice if everyone used the FSXMark07 benchmark but it is not absolutely necessary for just the demonstration of multithreaded concurrent execution within the FSX process. We do not need repeatable data - we just need a highly stressed QUAD processor running the appropriate trace. If the analysis of the trace shows concurrent execution of more than two FSX threads then we have an answer. QUESTION? - Why should I shut off DX10?

Share this post


Link to post
Share on other sites

Sorry, I don't understand what any of that meant, other than to recognize an investigation's premise to setup a technical argument designed to definitively define that any multi-core difference in FS must (or not) be occurring. That's more of a discussion that might be more effectively considered by the MS devs. I'm sure MS would be extremely interested, but equally disheartened to hear about the results. After all, they really tried their best. We simple simmers can only See the results.Good luck with that 'millisecond by millisecond CONCURRENT trace of the thread dispatch status' analysis (I just called it "Humps"). Let us know how it goes.

Share this post


Link to post
Share on other sites

I'd be interested to know the upshot of all of this. But can I suggest that you may be in danger of taking a wrong turn here? Your analysis seems to assume that the difference between 89% and 100% use of Core 1 (and 69% and 100% use of Core 2) represents "spare" capacity. What use, you reasonably ask, would it be to add a third and fourth core when Core 1 has 11% spare and Core 2 has 31% spare?The trouble is that your question assumes that all the other tasks required by FSX (and other applications) could sensibly be achieved when Cores 1 and 2 were otherwise "idle" (ie, during the 11% and 31% "gaps"). I do not think you can safely make that assumption. The whole point of multi-threaded applications is that things which would otherwise have to be done sequentially can be done simultaneously. So in FSX, the advantage of multiple cores is that more texture can be loaded WHILE (eg) Core 1 is doing its other stuff. Take away Core 2 (and Core 3 etc) and Core 1 still does its other stuff: but the work done by Cores 2, 3 etc either does not get done at all, or gets done on Core 1 at a less than optimum point in the cycle - contributing, no doubt, to stutters.I've just gone through similar thought processes as you. I've got 2 dual-core 5160 Xeons at 3GHz and I've never had any trouble with "blurries". My problem has been getting consistently high FPS during bad weather approaches into major airports in the Level-D 767 and PMDG 747X using the VC, which is how I like to practise my landings. Based on the fact that I'm usually happy to stare at and out of my VC without zooming around all over the place to get pretty external views, I thought I would trade a little texture loading performance in exchange for some higher FPS. The experience of landing with 30FPS is - to my mind - completely unlike the experience of landing with 20FPS: especially, for example, in a strong cross-wind. So I've ended up ordering an inexpensive but (hopefully) fast overclockable dual core PC to replace my existing setup until we know what Nehalem will deliver. My expectation is that the law of diminishing returns applies so that although no doubt I will be sorry to say goodbye to cores 3 and 4, core 2 will still bring me a large chunk of the advantages of multi-threaded texture loading. There is some support for this in the conclusion reached by (I think it was) MCP ALT RESET that the optimum number of cores for FSX is 3.Anyway, I'll be interested to trade notes.Tim

Share this post


Link to post
Share on other sites

>I am only asking the question "Can FSX/Acceration/SP2>consistently schedule more than two CONCURRENT threads for>SIMULTANEOUS execution?" Tests I have run using the inbuilt resource monitor in Vista 64 in the past show that FSX can at times use approaching 100% of the available processing power of a quad core. An example output chart of this process (all at the same clock speed) follows:http://forums.avsim.net/user_files/190832.jpg>To demonstrate that we need a millisecond by millisecond>CONCURRENT trace of the thread dispatch status (name & status)>on each processor. Using the process as detailed above, you can see you don't need to do this. If resource monitor shows FSX using between 50 and 75% of the total core count of a quad core processor, then it must be launching and running at least three concurrent threads at times to do this. Similarly, if it gets above 75% usage, then all four cores are firing for FSX at least some of the time.FWIW, I don't reckon there is that big an improvement going from dual to quad core as I have done. You can see from blips on the chart above that while quad core gets the texture loading out of the way much quicker than a dual core, the dual core never actually gets behind in this task. FPS is about the same too. The single core CPU is working flat out the whole time, so it's likely dropping some texture loading tasks.In short, I recommend sticking with your E6600 and its pretty descent overclock.Gary

Share this post


Link to post
Share on other sites

However, must a software thread run on only one core? Does Core = Thread? What if there really are only 2 threads going, but being distributed between multiple cores? Additional cores still help, but in this case they are only working on 2 software threads. At that point though, it gets a bit academic, cuz additional cores still help . . . and the software question then (still) a bit beyond us!

Share this post


Link to post
Share on other sites

>What if there really are only 2 threads going,>but being distributed between multiple cores? You are suggesting parallelism here and therefore, by definition, other threads would have to spawn for this to occur.>At that point though, it gets a bit academic, cuz additional>cores still help . . . and the software question then (still)>a bit beyond us!As you say, it is all academic. In laymans terms, two cores are definitely better than one for FSX, but the law of diminishing returns strikes hard as soon as you go over this two core threshold.Gary

Share this post


Link to post
Share on other sites

Threads = Cores sounds very "common sense"-ish. Guard against That at every opportunity. We know that we know that? I know that - I - don't know that (moving on from academic to to Socratic).

Share this post


Link to post
Share on other sites