.

I just completed KEWR-KDEN flight with PMDG 777. Good news no OOM.  AM settings was 43648,

Observation:

 

1- Total CPU indication  was lower then previous flights. Average was around 25%.

 

2-I noticed , during the  flight   bottle necks appeared.  Addition to these bottlenecks I realized when REX Info bar appears, bottle necks increases rapidly, After the weather injections completed bottle necks reduces..

 

Tomorrow I fly with AM=Settings 21824.

 

I have one question.

Really,  What am I expecting with AM Settings, flight should be smoother , no bottle necks. scenery  crisp/focus? Or is that wishful thinking.... .

.

I just completed KEWR-KDEN flight with PMDG 777. Good news no OOM.  AM settings was 43648,

Observation:

 

1- Total CPU indication  was lower then previous flights. Average was around 25%.

 

2-I noticed , during the  flight   bottle necks appeared.  Addition to these bottlenecks I realized when REX Info bar appears, bottle necks increases rapidly, After the weather injections completed bottle necks reduces..

 

Tomorrow I fly with AM=Settings 21824.

 

I have one question.

Really,  What am I expecting with AM Settings, flight should be smoother , no bottle necks. scenery  crisp/focus? Or is that wishful thinking.... .

 

I strongly suggest that you make sure you understand what the affinity mask is doing and then decide for yourself what settings you need to try. If you have a Windows PC the calculator can be set to "Programmer" view where you have radio buttons that allow you to switch between binary and decimal. Use a similar method to what I have shown you to decide what physical and hyperthreaded cores you would like used / disabled this will give you the binary value put this in the binary mode of the calculator and then select decimal mode for the value you need to enter as your affinity mask. You can use the reverse process to see exactly what a recommended affinity mask is doing for example this is the AM of 43648

 

 

You can see that this mask limits FSX to 5 hyperthreaded cores. Personally I would not have tried this setting as I would prefer to use actual physical cores over virtual ones as they will not have any overheads and I remain unconvinced that less is more i.e. that you should be limiting FSX to 5 cores. I am therefore not entirely surprised that this setting gives disappointing results. 

 

Having said this I fully agree with SteveW that because each user has different requirements in terms of FSX settings, add-ons, hardware performance etc the only way to know what the best mask is for you is by a process of elimination. Due to the large number of cores you have available the process for you will be longer but you should end up making the best use of your CPU and a smoother SIM as a result.

Remember that an AM can only mask off LPs for use by an app, those LPs and the LPs the app subsequently uses can still be used by other processes. There is no difference in the performance between LPs on an HT core, since they are the same core, only the result of assessing the core usage changes and can result in new tasks targeted to other cores.

 

1- Total CPU indication  was lower then previous flights. Average was around 25%.

Forget Total, look at individual cores.

Here the increased synchronizations slow down the sim, the main thread on LP03 is not performing so well in the lower half of the image:

 

 

With 6 core HT=On I would go for 5 threads, 1364 or 2728. with the 8 core HT=On, 43648 etc. I've got an addon with an AM=3 on LPs 0, and 1.

 

Playing devils advocate, you have 15% CPU utilisation vs 40% utilisation. All other things being equal if allowing more cores means the CPU is able to do more work surely the result would be a smoother SIM experience? There would be a certain amount of system overheads in managing the workload between additional cores but this would not explain a full 25% increase in CPU use demonstrated. Certainly the processor running the main SIM engine looks like it is not working as hard with the additional 8 threads available and this could potentially mean a drop in FPS, on the other hand it could be that as the other cores are taking more of the workload the main SIM processor has less to do. Without a before & after FPS count and anecdotal evidence as to any difference in how the SIM performs / smoothness in rendering in both settings it is difficult to draw any firm conclusions.

Playing devils advocate, you have 15% CPU utilisation vs blah blah.

 

You don't need to read too much into that, the graphs show what is generally happening - that is the point. So the best thing to do is test it for yourself, keeping in mind the handy tip that it is. (Besides, that's only down to when I took the shot, some time after pausing the sim.)

 

...this would not explain a full 25% increase in CPU use demonstrated...

You're not understanding it - that's due to the time delay before I captured the shot. Best try it yourself.

Just be aware Duck that some of the specific info Steve is giving Asanal is for a different type of processor than you have.  You have a 4Core/8Thread CPU.

 

Rick S.

 

Yup. Thanks

The point I was making with the graphs above shows in the top half the main thread is serviced by four secondary threads, while in the lower graph, there are eight threads servicing the main thread.

 

The upper graph was taken some time after pausing the sim, which can be seen by the drop off from the service threads mid-way. The utilisation shown bears no relationship to the values when the sim was running and should not be allowed to interfere with the subject.

 

In the top half, the main thread (top right) is serviced by four threads that each have a core to themselves, the main thread looks fairly stable maxing out on the core to itself.

 

In the lower half eight threads run on four cores. Each pair of threads competing for use of the core, the core is being forced to task-switch constantly between them. The main thread is destabilised by an excessive amount of synchronisations with the secondary threads.

 

It is wrong to think of a core in HT mode as a physical and a virtual core, they are in fact two Logical processors each with the same capacity.

It is wrong to think of a core in HT mode as a physical and a virtual core, they are in fact two Logical processors each with the same capacity.

 

From the very first article I came across - "HyperThreading is a feature introduced by Intel, and is exclusive to Intel processors. It splits a real CPU (a core) into 2. One is the real core, called the physical core. The other is just a secondary core, called the logical core. This logical core can't do much, but it does provide a little increased parallism. It is far from being a real core. In fact, it offers 10-20% (est., likely less) the performance of a real physical core. That's right, barely any computing power. Its purpose was simply to increase parallelism in a world dominated by I/O bound (non-CPU intensive) processes (actually threads, but we won't split hairs here). When a CPU intensive (CPU bound) thread is switched to one of these cores, its performance will substantially degrade."

 

When I tested this myself I came to the conclusion that virtual cores do not offer the same performance as physical ones but can still offer a boost for the graphics rendering threads.

...When a CPU intensive (CPU bound) thread is switched to one of these cores

That's where you're going wrong, there's nothing like that going on. An HT core is a core with an enhanced method of switching, and is made to look like two actual cores. You seem to have taken a loose description too literally.

 

This logical core can't do much

Let's say we have two threads and one processor, each thread would be given a period of time to run. The first will run for that period, then when it's time to allow the second thread to run, the situation is saved away, and the next thread loaded up and run for a period.

 

Very basically, the HT enabled core effectively improves that, and has the additional circuitry to emulate two Logical processors on that core in a way that beats two threads on one ordinary processor.

That's where you're going wrong......

 

The information quoted was from an external source offered as evidence that virtual cores do not offer the same performance as the physical cores that host them.

Two equal threads, and the core is in HT mode, the two "Logical processors" would be able to only half match a real core, since as stated earlier they are contending for the use of that core. They get the same performance, the explanation you post is misleading.

 

...In the image it shows "Cores" and "Logical processors", and that's what they are.

I think I've said all I need to. As long as folks understand what the affinity mask does,how to create their own custom masks and convert suggested masks from decimal to binary to understand what impact they will have, then that's me happy. Folks can then experiment with the number of cores they use and test performance on physical and virtual cores, and draw their own conclusions. 

test performance on physical and virtual cores

Hold on, you wanted to play "Devils Advocate", so you're not off the hook yet.

 

This kind of sounds like you are saying with or without HT enabled, but you are in fact suggesting the HT threads on LP0 get more throughput than the threads on LP1, when in fact each runs on one and the same core. It would also help if you used the proper nomenclature. There are 4 cores and 8 LPs, not 4 cores and 4 VPs.

 

If you check through my posts, I quickly mentioned an "addon" with an AM=3 (11), utilising LPs 0 and 1, on core 0. We can easily write multi-threaded applications that can target their resources, to truly test out our understanding.

If you check through my posts, I quickly mentioned an "addon" with an AM=3 (11), utilising LPs 0 and 1, on core 0. We can easily write multi-threaded applications that can target their resources, to truly test out our understanding.

 

If you could write something that could be benchmarked bypassing the first couple of cores to rule out any OS processes and selectively run on the next 2 LPs in turn that would be really useful. So in FSX the masks that would be used for the benchmark would be 16 (010000), 32 (100000).

I can't seem to copy the link now, but if you Google "how fsx works and how performance is affected by different hardware explained", you will find an excellent article in the forums by a chap called Lars...the research is a few years old but still very relevant...