If I don't restrict P3D from using it, it will max out core 0, causing more stutters than usual.

Doing this allows it to stretch its legs on the other cores instead as Windows and other apps prefer to use core 0.

 

 

I have to disagree with both points. LM has said that all that happens if you prevent P3d from using core 0 as its main thread, it will just use a different core and max that one out to 100%. Further, the task scheduler in Win 7 and especially Win 8 decides what apps get to use which cores (assuming that none have an AM set explicitly). Core 0 is rarely more heavily used by the OS and apps (except P3d) than any other core. That behavior went out with Windows XP. Besides, if one has any non-sim related apps using even one percent of system resources, then the system is probably either too slow to run the sim properly or there is a lot of non-sim related junk running in the background.

When talking about cores in an HT=Off system, an AM is only really used if you have many cores and want to partition the CPU for the app. But in an HT=On system we have two logical processors per core. An AM is often used to mask off one logical processor of the first core, so that as the app creates the next major thread the task scheduler moves it along by one LP and so now it resides on the next physical core, rather than the next logical processor of the first core. We don't need an AM with FSX-SE since it handles threads itself and avoids starting two main threads on competing logical processors.

I have it on, with my i7 4790K - I use it for other software that has high end graphics editing, doesn't have any adverse effects in P3Dv2.5 or FSX

On an HT=On system, it's possible to lose out quite drastically with FSX or P3D if we don't use an AM. FSX-SE owners look away. We want to ensure uninterrupted use of a core that may become shared since it is two logical processors of the same core. So in the graph below where we mask off one LP (shown in the top half), we have greater performance by around 10%.

 

It's usually best to leave HT=On since the app utilises many resources of the PC and spawns dozens of threads. The greater efficiency of switching many threads on an HT enabled system eventually pans out in our favour.

 

But with an AM we can only mask off some part of the CPU, so we actually reduce our available hardware. However, with an HT enabled system and some applications, it's best to use an AM simply to mask LP0 or LP1 to help the second thread along on its way to run up on the first LP of the next core.

 

In the example below (6 core HT=On, 12LP) in the top half I've partitioned the CPU so that P3D main thread starts on LP6, and masked LP7 to move the second starting thread along to LP8. In the bottom half no AM or AM=0.

 

Clearly in the top half LP6 is shared on core 3 with LP7 which is doing nothing, but in the lower half, LP1 shared with LP0 on core 0 is running a task which reduces LP0 available throughput by around 10%, and that wants to be given full bandwidth. The top half shows LP6 at full bandwidth:

 

Believe you me, Steve is an authority on this topic and has assisted me greatly with AM settings..

On my side the following worked quite smooth:

 

HT=on

P3D without affinity mask

other tasks use all cores, except LP0/1

 

So I tried to give P3D room to breathe with the main thread using the physical core 1.

 

After reading Steve's suggestions I would set P3D's AM to exclude LP1 which hopefully makes it even better.

 

Best case would be if we can even select the core for P3D's main thread, but that's not possible AFAIK :unsure:

Best case would be if we can even select the core for P3D's main thread, but that's not possible AFAIK :unsure:

That's what I did above. In the top half of the image, the main thread starts on core 3, LP6. LP7 is masked. With a 4 core 8 LP, use something like AM=254=(11,11,11,10) which simply masks LP0, if the first thread is on LP1, the next thread the sim starts will be placed on LP2 - the next core.

 

For example, since the main thread won't be fully operative during startup, if it's on an unmasked CPU, the task scheduler may put the first thread on LP0 core 0, and follow with the next thread on LP1 core 0, occupying the same core. This is shown in the lower half of the image above, look at LP0 core 0 (top left lower half) is maxed by the main thread, but the second thread running on LP1 (first in from left, shows "AM=0" at 8-10%) uses over 8% of the bandwidth of core 0.

...In the top half of the image, LP7 is the least used LP on the chip, and the other LP on the core is maxed with the main P3D thread uninterrupted. If you look toward the last third of the trace a tiny blip of a few % arises. There's a peak in the trace right across the chip whereby I've scheduled in a sudden task, the main P3D thread is unaffected. The traces show that more or less the only app running is P3D, over 40 threads are started with the resources used by the sim.