But anyway, beside that ... perhaps you need to read the part in the usage of this method that you linked to -- not sure how Aces could have used this approach give Windows 7 wasn't around when FSX shipped.  Also, note the comments ... low level calls like this often produce inconsistent behavior across hardware.

 

That is true. FSX was a Windows Vista showcase software so I guess some ACES folks worked closely with the Vista team during development of both products.

 

 

BTW, thanks for keeping it civil Rob, despite efforts from someone to crash the party. You're a true gent! 

http://stackoverflow.com/questions/1542213/how-to-find-the-number-of-cpu-cores-via-net-c

http://stackoverflow.com/questions/1542213/how-to-find-the-number-of-cpu-cores-via-net-c

 

Again, enumerating the number of physical processors != knowing if logical processor X is a hyper-threaded core or a "real" core.

Well, after all of this discussion, what's the current verdict?  Specifically, do we know what effect will enabling HT on my 3930K have on FSX 'performance', with performance defined as frame rate + texture update rate + freedom from stuttering?  And what is the correct AffinityMask value to support 6cores/12threads?

 

I tried HT enabled using AM value of 1364 and that caused massive blurries and it appeared very few cores were showing utilization--I think it was Cores0 + 1.  

 

So I'm back at my default AM=62, HT disabled.

1364 equates to 10101010100 in binary. What exactly is your logic for doing this? You think just be setting every other core to zero that you somehow get only one thread per physical core? Nothing is preventing the OS from putting threads from other processes on any of those cores, physical or otherwise. If you did nothing with affinity mask, the OS would manage which cores make the most sense for every app. That is the best course of action. And whether you have HT on or off makes no difference to FSX.

 

The OS only "doubles up" threads on a physical core is the need is there. If FSX only uses four cores and nothing else is taking  any significant CPU time, then the OS will run each FSX parallel thread on a physical core. Any muddling around with Affinity Mask falls under the category of fine tuning and it makes no sense to limit FSX and then let any other process' threads be managed by the OS.

What exactly is your logic for doing this? You think just be setting every other core to zero that you somehow get only one thread per physical core?

 

Here's my logic:  http://www.gatwick-fsg.org.uk/affinitymask.aspx?SubMenuItem=hardware

 

From the results obtained at that value I would agree the logic in the calculator is not equating to the optimal value for best performance.

 

 

 

That is the best course of action. And whether you have HT on or off makes no difference to FSX.

 

So all of the emphasis here for manually setting AM is based on false premises you are saying?  If I exclude AM in fsx.cfg, versus set a value of 62 for my proc w/o HT enabled, you are saying I will see the same CPU utilization in all cores, or perhaps the sum of all cores would be the same with or w/o manually setting AM?  

What I am saying is that back in the day, when everyone ran 32 bit Win XP, it might have made some sense to give an app like FSX an Affinity Mask. But with Win 7 and 8 , one is far better off to just let the OS worry about how it is going to partition out CPU resources. As to HT, on a quad or hexa core system, whether it is on or off will also have no bearing on how FSX runs. Now if P3d 2.0 is designed for a dual Xeon system, then the app could be coded to take advantage of up to let's say, 32 cores. In that case, there might be a small advantage to having HT turned on.

 

I am not directing this further comment to you, BTW. There seems to be some undercurrent here on AVSIM that with HT on, you now magically have double the number of cores, but all those cores are running at half the speed. This absolutely not how HT works. The purpose of HT is to give the OS more flexibility in assigning parallel tasks. While FSX is running, there are only very few other apps taking up only miniscule amounts of CPU time. FSX gets the full attention from the OS for all the CPU time that it needs. It may not max out 4 physical cores at 100%, only because a ) it may not need that much CPU time, b ) the parallelism in FSX is archaic or c ) the CPU is waiting for the GPU or the disk IO system to catch up.

 

 

What I am saying is that back in the day, when everyone ran 32 bit Win XP, it might have made some sense to give an app like FSX an Affinity Mask.

 

Have you done some careful testing to assess for HT on w/ an AM set, or HT on w/ Win 7 in command? It's one thing for something to make sense and quite another to have it be manifested.

Yes. First, look at my system specs for a context. I have run both FSX and P3d with HT on and HT off and there is no visual difference, no blurries, no difference in FPS.

 

Second, with HT off, I have tried various ways of applying the Affinity Mask to FSX. First, I used various AM combinations within FSX.cfg and observed the CPU usage with AIDA64. The AM parameter does indeed limit FSX to those specific cores, but it made no difference in performance. Second, I eliminated the AM setting from FSX.cfg and set affinities in Process Explorer (the MS task manager replacement, which among other things, allows one to set the AM for any and all running apps). Again, no difference observed in FPS. I also moved the few active apps (such OPUS and TrackIR) to other cores and that made no difference either. Lastly, I used FSXAssist (which is really the simplest way to not only assign cores to FSX but also to 3rd party add ons). There was no discernable change in FPS or visual quality.

 

FSX is an legacy app that barely takes advantage of parallel processing. If using AM works for you, then great. I don't really care if you agree with: what I'm saying, what Nick's "Bible" says, what FamilyMan wrote in this thread or even what Phil Taylor from ACES posted long ago about FSX.

 

The vast majority of these so-called "tweaks" for FSX have a placebo effect. What's worse, FSX seems so sensitive to changes in FSX.cfg, that even seemingly minor edits to this file can cause blurries, CTDs and degraded performance. 

If you think you are seeing a difference with LOD above 9.5 than I would suggest that you are only seeing a random in and out texture loading duw to memory swapping and sharring, you will have to do much further "testing" to prove it to yourself, like Boaz used.

 

This has been tested to death here on Avsim, in the dev forums when developing HIghres photoscenery, and yes you are spot on when it it comes to LOD and Texture res and distance, default FSX res is no were near the 9 and 13cm meter photoscenery that we can use in creating bgls, and high LOD is a must to enjoy it and the higher res you have the shorter the distance for the same LOD setting will result. But Im' sorry she will go no higher with any effect over 9.5, you just have to prove it to your self. And for Negative LOD bias to work you can't use "clamp" its the reverse, clamp is there to hold negative values that some games have used but do not mip well with aniso. Wich BTW has more to do with Mips than AA ever will, Think AA for edges, Aniso for Texture detail in the distance in simplified terms.

 

I think Martin Wright still has a test BGL you can down load or you can make your own with the SDK, it also helps to use some good mesh test area, we used one in the middle of the ocean with a multicolor based highres texture mapped and numbered in addition to custom mesh. If you search here or at FSdotcom for "test mesh" and test terrain BGL" from about 2007/8 that should work for convincing proof of your LOD settings.

 

If you want to get into it more,the original FSX RTM handled photoreal LOD much better than the SP1/2, also same can be said of NV drivers, drivers from just around that time period in 07 when NV still used completely angle independent aniso along with nice negative LOD bias.

 

Its mostly all gone now...all for the sake of the FPS race...

Second, I eliminated the AM setting from FSX.cfg and set affinities in Process Explorer (the MS task manager replacement, which among other things, allows one to set the AM for any and all running apps). Again, no difference observed in FPS.

I would expect this. Setting a processor affinity at the process-level rarely yields predictable or favorable results. It says nothing about which threads are allowed to run where; that determination is made by the kernel.

 

The one thing the AffinityMask setting in the config file has going for it is that it is a device of the application - not Windoze. It is possible (and likely) that FSX is able to assert more direct control over its destiny by binding *specific* threads (such as texture loading and rendering) to specific cores as governed by the mask. The presence of the FIBER_FRAME_TIME_FRACTION, by its name, also suggests the application of fibers in the design of the engine (fibers are "lightweight" or "psuedo" threads which implement co-operative multitasking and are managed and scheduled by the application not the OS). So I don't agree with your assertion that Aces was so back in legacy-land they were too naive to implement a parallelized design. Parallel application development may be coming to the forefront as Moore's law struggles to keep up, but it's certainly not new. Multi-threaded application development has been going on for a few decades. I think the Aces guys were a bit more saavy then what you give them credit for.

 

That said, tuning FSX is not as trivial as "shove this number into your config file" and witness a boost in frame rates. There are so many moving parts on this thing, if you don't have an understanding of what your bottle neck is (i.e. GPU horsepower, texture bandwidth, RAM, CPU clock speed, CPU architecture, cache speed, cache size, etc.) tuning your AffinityMask may indeed be a crap shoot as to whether or not you realize a benefit.

What you've hit upon us why graphically intensive apps utilize the GPU for parallelism. A high end nVidia GPU might have 1000+ CUDA cores. General purpose CPUs are just not as well suited for these kinds of apps.

 

 

The purpose of HT is to give the OS more flexibility in assigning parallel tasks.

Hi Jabloom, 

 

Close, but not fully accurate. HT was enabled to allow the CPU to process other threads when the thread on the primary core stalled, typically because of a cache miss and the ensuing memory latency. That latency could be dozens, if not hundreds of CPU cycles, and so instead of twiddling its thumbs, the CPU switched its focus to the task in the hyper-thread queue, and would use the core resources such as arithmetic units to execute. As the HT core "looked" like a regular core, the OS could schedule other tasks/threads to the HT core. Also note that the OS does not have anything to do with the switching - it is all done at the hardware level.

 

That being said, there are different ways of implementing HT. IBM does it best in their POWER processors, the newer SPARC implementations are also very good, and Intel is "not bad".

 

In the early days of hyper-threading, there were instances where hyper-threading was recommended to be off, most notably for SQL Server and other highly parallel applications. The reason was that a hyper-thread running on the same core as the primary thread could hold a lock on a resource (i.e., a row or table lock) that the primary thread needed, and they would stall each other contending for that resource.

 

I think a far bigger effect is the poorly implemented task scheduler in Windows. It allows tasks to ping-pong back and forth between cores, hyper-threaded or not, and the ensuing cache thrashing just slows things down. It used to be *really* bad back in the days of single core processors lashed together with front-side bus memory architectures, but is now reduced in effect because all the cores on the same die with a shared last-level cache. You can see this effect running a single threaded application that is heavily CPU-bound but had an I/O component, such as importing a bunch of data into a database. As shown by Task Manager, two cores will be running for this single-threaded application, neither of which are fully utilized. However, the SUM of the two loads will total 100%. What happens is that when Windows services the I/O interrupts, it schedules the task to resume processing on a free core, since the busy one is obviously busy. When the task on the running core is done and is ready to process/ingest the next data block, it finds itself scheduled for the other core. I view it as a combination of "are we there yet" with "mine, mine, mine" (think seagulls in Finding Nemo). The "are we there yet" is an idle core, bored, while the "mine, mine, mine" is that same core taking a queued thread from a another core (yes, I know: technically, the OS gives the queued task to the idle core). That is why I personally prefer HT off and use Affinity=14 - I just don't think the base ESP code is really capable of efficiently utilizing more than a couple of cores, despite being a "multi-threaded" application.

 

When I run FSX (now exclusively P3D) and have Task Manager on, I can easily see this effect: the primary core hosting the flight engine will show a consistent load, saturated or close to saturated, while the other cores are bobbing up and down. The problem is that they are all bobbing up and down in cadence, and demonstrate identical saw-tooth traces, indicating that they are processing the same work ("are we there yet?") and being gated by a common resource ("mine, mine, mine"). [side note: FSX used to hammer the primary core to 100% busy. I don't see that in P3D.] In a perfect world with a truly multi-threaded application, all cores would show consistent load, or at least not echo each others activity.

 

As for why a lot of people don't see a difference with HT on or off, the age-old axiom holds sway: All computers wait at the same speed. When Task Manager shows that saw-tooth pattern, we are waiting...

A man goes to the doctor because of a sore back. After extensive testing, the doctor explains that it is nothing more than sore muscles and that the best course of action is a hot bath.

 

The man goes home and runs the bath water. His wife sees this and says, "What are you doing? A hot bath is the worst thing for a sore back". She shuts off the water and runs an ice cold bath for her husband. The man finds immediate relief.

 

In a week the man returns to the doctor for a follow up exam. He tells the doctor than that he feels great and how the cold bath did wonders. He then says, "Doc, why did you tell me to take a hot bath?"

 

The doctor replies, "That's very interesting. MY wife said a hot bath would work."

A man goes deep into the dark south African jungle while on a safari and meets a man in a white lab coat and asks "what are you doing here? A safari is the worst place to sell me a new CPU" He opens his lab coat to show his wares, Haswell's, Ivy Bridge-E's you name it, so the man buys two and tucks them safely away in his backpack and rejoins the group.

 

The guide ask the man "why did you buy from him? he's known around these parts as ElnerdI the terrible".

The man stopped, turned around and looking him right in the eyes, said..

 

Live from NY its Saturday night!

 

Where are you and What just happened?