If we don't limit the number of threads the sim starts-up, then our available VAS will be eaten, several megabytes per thread, and even more when we run a 32bit thread on WOW64.

Enabling HT on an 8 core CPU gives 16 LPs (logical processors), without an AM there would be too many threads, and since these have to synchronize with the main thread there will be more stopping and synching data with the main thread.

Also when we enable HT we must know that the Jobscheduler will allocate each thread the next available LP. On an HT enabled system, and no AM, the first two Sim threads will start up on LP0 and LP1, both on core 0. SO with HT enabled we must also mask one of the first LPs.

With HT disabled we need only limit the number of cores and with a 4 core CPU we need do nothing.


With HT enabled, a large part of circuitry comes into operation to make two threads swapped on a core not run with the penalty of stopping, reloading registers, and restarting alternate threads. So up to half the time the CPU does this is saved. That's why the CPU get's hotter, it's doing more work funnily enough.

With HT enabled the PC performance overall is increased, but with certain designs of multi-threaded software like FSX and P3D, we need to help the Jobscheduler by masking one LP of the first core encountered, and limiting the total number of main threads.

Adding an AM reduces the number of available LPs to the system threads invoked by the main sim threads running. The sim spawns upward of 40 threads and these run in the affinity of the application.

Simply put, with HT enabled the sim performance will suffer without an AM since it will share the first available core with a second main thread, hence we mask one of the first LPs. Also with or without HT enabled, if we have too many LPs we'll run into the problem of VAS lost and too much synching with the main thread.

When pushing an overclock we can save heat with HT disabled, and we can gain a few more fps since the main thread will run faster, but we will lose some overall performance in the PC since the I/O and networking is highly threaded.

 

Steve, could it be that Windows 10 has some different logic regarding threads? I somehow observed on my machine (i7 3770 running at 4.5GHz) that deleting the AffinityMask entry in my FSX.cfg actually results in a slightly smoother gameplay compared to the old AffinityMask=254 entry from my W7 setup. Might be placebo though, but so far I did not experience any drawback by using no AM in my FSX, and this is all with HT on...

Adding an AM reduces the number of available LPs to the system threads invoked by the main sim threads running. The sim spawns upward of 40 threads and these run in the affinity of the application.

 

Is the number of spawned threads influenced by the number of LPs seen by FSX/P3D? In other words, conditions being the same, will it spawn less threads if the available number of LPs (via HT off or via AffinityMask) is reduced?

@J van E

 

If I designed the gui, Ctrl v would still work to paste, its what people expect, design GUI around expectations, what folks are used TO. That's how I make my living and that's what sells.

Funny that Ctrl-C and Ctrl-V work just fine for me:

 

"If I designed the gui, Ctrl v would still work to paste, its what people expect..."

Copy/pasting a link is likewise working just fine...

 

http://www.avsim.com/topic/476776-500mb-vas-reduction-and-increase-fps-by-22-in-v3-need-some-testers/page-2

It's a well-known IE11 issue, I tried Edge once (once was enough) and if memory serves me right it inherited this "feature".

 

Other browsers work fine. MS lost me as a browser customer for now.

 

Kind regards, Michael

 MS lost me as a browser customer for now.

 

Kind regards, Michael

 

I hate IE about as much as it is possible to hate anything technology related.    Have been using chrome since day dot.

I get all sorts of wonky performance and stutters with the Q400 in v3, where as smooth as silk in v2.5.

 

Only stutters with the Q400 are when viewing from "Spot" view ... don't use that view and used "Locked Spot", otherwise performance is excellent in the Q400.  But I did some additional testing in PMDG 737 and 777 last night at FB's KSFO HD and performance was excellent (but performance has always been pretty good on my system) ... it's the VAS improvement that really has me surprised and I can consistently reproduce the HT ON and HT OFF VAS differences.

 

CPU core work load distribution is now almost equal with core 0 doing a little more but not peaking at 90-100% like it would with HT ON.  So I tend to agree there is definitely something to managing one's HT setting and/or Affinity Mask.  I need to do more VAS testing with HT ON and setting Affinity to just the 8 physical cores.

 

Steve's logic seems sound, but the 450-500MB VAS saving I see with 8 vs. 16 cores still seems much higher than I thought it should be even with more concurrent threads ... it's almost as if some threads hit a deadlock and hence hold onto resources and/or never release the resources.

 

I had done plenty of AF and HT ON/OFF testing back in V2.x days when my primary CPU was my 3960X (not my current 5960X) and I didn't really notice any performance difference nor any VAS difference.  So when I tested these settings again with my 5960X in V3, I expected similar results as v2.5 and 3960X ... so it was a big unexpected surprise for me to see the VAS difference - so unexpected that I ran the test 3 more times (no OC, 4.3Ghz, and 4.6Ghz).

 

Anyway, Saul and I have inquired with LM and Adam has indicated they will investigate but I would hazard a "guess" it's NOT a priority for them as the issue does seem to only surface in very specific hardware/OS environments and does have a work around.

 

But I appreciate folks reporting their results.

 

Cheers, Rob.

Is the number of spawned threads influenced by the number of LPs seen by FSX/P3D? In other words, conditions being the same, will it spawn less threads if the available number of LPs (via HT off or via AffinityMask) is reduced?

Yes.

Yes.

 

So, if I understood correctly your previous post, you seem to suggest that the optimal number of physical cores that FSX/P3D should use, is 4.

Having it use only 1 or 2 physical cores, or having it use 8 physical cores (supposing HT is off) leads to worse performance in terms of smoothness etc. Did I understand correctly?

Rob, i think it is important to know at this point if this is applicable in 2.5 as well;

knowing this factor could help isolate this mystery boost source,

 

Stil shooting in the dark here, but one thing that comes to mind at this point is;

when HT is on you’re also sharing your cpu cache between cores;

when HT is off cache is not shared and is dedicated fully to a single core,

So, if I understood correctly your previous post, you seem to suggest that the optimal number of physical cores that FSX/P3D should use, is 4.

Having it use only 1 or 2 physical cores, or having it use 8 physical cores (supposing HT is off) leads to worse performance in terms of smoothness etc. Did I understand correctly?

Three LPs would be a good starting point, a fourth would just add another data collection thread.

If we don't limit the number of threads the sim starts-up, then our available VAS will be eaten, several megabytes per thread, and even more when we run a 32bit thread on WOW64.

 

Enabling HT on an 8 core CPU gives 16 LPs (logical processors), without an AM there would be too many threads, and since these have to synchronize with the main thread there will be more stopping and synching data with the main thread.

 

Also when we enable HT we must know that the Jobscheduler will allocate each thread the next available LP. On an HT enabled system, and no AM, the first two Sim threads will start up on LP0 and LP1, both on core 0. SO with HT enabled we must also mask one of the first LPs.

 

With HT disabled we need only limit the number of cores and with a 4 core CPU we need do nothing.

 

 

With HT enabled, a large part of circuitry comes into operation to make two threads swapped on a core not run with the penalty of stopping, reloading registers, and restarting alternate threads. So up to half the time the CPU does this is saved. That's why the CPU get's hotter, it's doing more work funnily enough.

 

With HT enabled the PC performance overall is increased, but with certain designs of multi-threaded software like FSX and P3D, we need to help the Jobscheduler by masking one LP of the first core encountered, and limiting the total number of main threads.

 

Adding an AM reduces the number of available LPs to the system threads invoked by the main sim threads running. The sim spawns upward of 40 threads and these run in the affinity of the application.

 

Simply put, with HT enabled the sim performance will suffer without an AM since it will share the first available core with a second main thread, hence we mask one of the first LPs. Also with or without HT enabled, if we have too many LPs we'll run into the problem of VAS lost and too much synching with the main thread.

 

When pushing an overclock we can save heat with HT disabled, and we can gain a few more fps since the main thread will run faster, but we will lose some overall performance in the PC since the I/O and networking is highly threaded.

 

 

 

Appreciate the post Steve. Very detailed, on topic and informative.

 

Regards,

- Hasan

if i draw a conclusion correctly from what Steve stated,

then... if Rob limits his HT to 4 cores he should see the same gains (if not more) as with HT off on his system?

Rob, i think it is important to know at this point if this is applicable in 2.5 as well;

knowing this factor could help isolate this mystery boost source,

 

Stil shooting in the dark here, but one thing that comes to mind at this point is;

when HT is on you’re also sharing your cpu cache between cores;

when HT is off cache is not shared and is dedicated fully to a single core,

It's the same for 2.5.

 

The problem is that running HT enabled without an applicable AM is going to mar the performance.

 

Below, in the the upper half I've demonstrated an applicable AM so that LP6 does not share the core, keeping all that lovely cache to itself.

 

The lower half shows no AM where LPs 0 and 1 (core 0 on the top left) share the core with the main sim thread and another sim thread losing 8% fps performance.

 

 

Performance and stutters with the Q400 in v3

 

This has been a problem with this specific aircraft not Prepar3d