Jump to content
Sign in to follow this  
777simmer

Does PMDG777 use hyperthreading?

Recommended Posts

We all know FSX does not use hyperthreading.

 

Thus when overclocking, to reduce heat, I have hyperthreading off in the BIOS.

 

I was wondering if the more modern addons like the PMDG777 can use hyperthreading?

Edit: it is after all running outside of FSX!

 

In that case performance might be better with a slightly lower clock but hyperthreading on!


Rob Robson

Share this post


Link to post
Share on other sites

FSX can use HT to a somewhat lesser extent. So there might be some tradeoff/room for optimization with the HT thingy.

 

And, as you mentioned already, the PMDG dll's are dependant on how FSX runs its game, HT-wise ("game" like in "game" :P).

Share this post


Link to post
Share on other sites

Where did you hear that it runs outside of FSX? 

 

And no in my experience HT does't do jack for Performance.


David Zambrano, CFII, CPL, IGI

I know there's a lot of money in aviation because I put it there. 

BetaTeamD.png

Share this post


Link to post
Share on other sites

HT does not do work for FSX.

 

The task manager will show 8 cores working on a 4 core CPU.

But the data from the 4 HT cores is not processed by FSX cause it was not programmed for it. (according to my specialist source).

 

PMDG has confirmed that their products work outside of FSX.

 

Even in one of freezes thread they say that since their code runs outside of FSX, they can look into their programming and cant see anything wrong there.

So the problem lies inside the FSX code where they have no acces to.


Rob Robson

Share this post


Link to post
Share on other sites

 

 


Where did you hear that it runs outside of FSX? 

 

PMDG has been running processes outside of FSX for ages.  If you look around, there are more than a few references made by the team members about how they just never bothered to point it out as much (usually in regards to people pointing out that Majestic was being "pioneering" when running the Dash 8's processes externally).


Kyle Rodgers

Share this post


Link to post
Share on other sites

Well I Know an aircraft developer that has been running it's FBW,autopilot and FADEC code outside of FS for over 9 years.... Not PMDG


Rob Prest

 

Share this post


Link to post
Share on other sites

There are no "PMDG.exe's" that someone could assign cores (real or HT ones) to.

Ok I guess that kind of blows that idea out of the window then :-(

Although....just because we dont see an .exe.....does that mean PMDG does not programm for HT?

 

Maybe PMDG can look into that (if they haven't already)?

I mean anything that takes a load away from core 0 helps right!

Well I Know an aircraft developer that has been running it's FBW,autopilot and FADEC code outside of FS for over 9 years.... Not PMDG

 

I did not mean to turn this into a "who invented what" thread.

Please lets not.

 

Just want to know if PMDG777 benefits from Hyperthreading.

 

EDIT: I was still able to erase my sentence where I said that PMDG claims to have invented code working outside of FSX.....thats not what this is about.....I should not have mentioned it!


Rob Robson

Share this post


Link to post
Share on other sites

PMDG has been running processes outside of FSX for ages.  If you look around, there are more than a few references made by the team members about how they just never bothered to point it out as much (usually in regards to people pointing out that Majestic was being "pioneering" when running the Dash 8's processes externally).

I know I read something of the sort, but it had to do with control inputs. I was referring to some kind of .exe. 


David Zambrano, CFII, CPL, IGI

I know there's a lot of money in aviation because I put it there. 

BetaTeamD.png

Share this post


Link to post
Share on other sites

I think almost everything runs outside of FSX.

 

Fuel system and FBW system they confirmed.

 

Electrical, Air, Hydraulic, etc etc as well I bet.

Would be nice if we could offload that to HT cores no?


Rob Robson

Share this post


Link to post
Share on other sites

With regard to multi-core use, below is an excerpt from Phil Taylor's post on SP1.  FSX does address additional cores, but the returns are minimally tangible (ie: between two well tuned systems with different core counts).  Sorry for the wordy post, but my only link was to a cached version of the page:

 

Performance
Addressing persistent issues with FSX performance was the driving force behind SP1. How did we do that? With a lot of hard work! :) We had two goals: add multi-core support and address the most pressing performance hot spots. So we profiled FSX and we identified some hot spots; and we identified two candidates for multi-core work. That translated to the following work list:

General Performance Work

  1. Performed more work on the LOD system.
  2. Optimized the UI rendering to reduce overhead when the UI is visible.
  3. Front-end texture loader no longer loads loads full mips when it doesn't need to.
  4. Removed redundant elevation queries when scenery complexity is low.
  5. Avoid rasterizing water into the DEM for textures that are all land.
  6. Fixed redundant vertex issue with key Autogen BGLs.
  7. Updated XToMdl tool to leverage same vertex issue, resulting in model vertex reduction on the order of 25-40% for 3rd party developers.

D3D Performance Work

  1. Enabled skinning for more animated objects; which reduces Draw calls.
  2. Batched Autogen objects to reduce Draw calls.
  3. Optimized tree rendering to reduce SetTexture calls.
  4. Coalesced shader state to reduce uploads to the card.
  5. Fixed 3 FS8 AI aircraft in terms of Draw calls. This is the MD-80, Dash-8, and Cherokee. This is a >10x reduction. They are 25% of the worldwide air traffic DB so this can be significant.

Multi-core Performance Work

  1. Moved DEM loading to threads.
  2. Moved terrain texture synthesis to threads.
  3. Moved Autogen batch rebuilds to threads.

That's 15 different work items.  We had five engineers, and the work wasn't spread evenly, but you get the idea that everyone had a lot of work to do. Note, for the terrain texture synthesis the process itself is documented in Adams' Global Terrain Technology for Flight Sim paper, see the bit about the layers and texture synthesis.

How it went together
Now, don't think because we are calling it a "patch" that we are doing binary patches. We are not.

Yes, we use a delta-patching technology in the installer for scenery bgls and the like. Even there some files have changed enough that the delta-patcher cannot handle them and we have to have a "full file" in the patch. The bgl for the Japanese traffic data is an example. We reversed the traffic vectors for the entire country, and almost every byte changed. We tried to put it through the delta-patcher, but it keeled over and gave up, and errored out during setup.

We are rebuilding the binaries from scratch. That's not trying to patch the old binaries, it's replacing them with new files, many of which have quite a bit of new code. The multi-core work, for instance, went through the terrain code stack from top to bottom. That's one reason why SP1 took so long. The multi-core infrastructure is solid, will use up to 256 cores if available, and will continue to be used as we migrate systems to it when it makes sense. Terrain and Autogen are it for now; we'll be evaluating when to do more.

General Performance Work
The general performance work reduced the amount of work we try to do in various scenarios. I want to call out the redundant vertex issue; that's a key thing we fixed in the Autogen bgls (autogen.bgl, vegetation.bgl, and roofs.bgl) as well as in the SDK tool to pass the savings on to all third-party developers when they reauthor with the SP1 SDK.

D3D Performance Work
D3D API usage work was aimed at reducing our Draw and SetTexture API calls. So what are Draw and SetTexture calls? These are the D3D9 API calls that the engine issues to push textures and draw triangles down to the card, the bulk of the work in rendering. We were issuing way too many Draw and SetTexture calls; SP1 is a 35-40% reduction in both. Taking those optimizations is aimed at enabling the app to scale better on GPUs. We took some optimizations on shader state too, which is a nice win. And the 3 FS8 AI aircraft where just horrendous in RTM, so that's another nice fix.

Multi-core Performance Work
Intel is using FSX as one of their prime examples at IDF, so we had a lot of engineering time from one of their threading guys. Intel doesn't do that lightly. We used the time to good benefit.

During loading, we run the DEM loader on threads. You'll see good balanced usage across all cores, as well as about 1/3 faster load times on average.

During flight we spawn threads for Autogen batch rebuilds as well as the terrain texture synthesis. The terrain texture work tends to be a bit bursty; as an area gets generated the load reduces true. But as you fly forward, as you bank, and as the terrain is lighted ( once a minute ) threads are spawned. The terrain grid system is radial around the current viewpoint, and, depending on level of detail, radius can be up to 4.5 tiles in either direction, something like 64 tiles. So there is plenty of work to go around. Autogen is more constant, with a 2km extent being batched.

Even given the bursty nature of the core usage when flying, when there is load, its pretty balanced across the cores. And we got rid of as much of the stutters as we could by going to a lock-free synchronization style. It's solid work that we are deservedly proud of.

As far as practical limits on number of usable cores, currently SetThreadAffinityMask only allows explicit scheduling of threads on 32 cores ( the mask is a dword ) on Win32. So that's our effective limit on number of cores. But as soon as there is a way to explicitly schedule them, we can handle 256 cores.

Performance Final Word 
With all that said, the Draw and SetTexture API call reductions and Autogen size reductions are probably as important for FPS improvements; the multi-core work really shines for load balancing and reducing stutters and blurries. And both are critical for better scaling as CPUs and GPUs get better.

We think SP1 is going to deliver the goods for most users, and will reward users with better hardware the most. We expect that, except in the very, very low-end hardware, all users should see a 20% gain. Some scenarios will see 40%, and some will see a bit more. It's really going to depend on a lot of variables. We hope this enables users to either fly at the same settings with greater FPS, or to bump the sliders up 1 or 2 ticks and still get the same FPS you had.
 
It's going to take time to see if that holds true, but we had good results in our perf lab and with the beta testers.

Performance Note 1:
The vastly improved batching of Autogen was one of the major performance items in SP1 and helps to reach our target reduction of 35-40% for Draw and SetTexure calls. However, it does have an implication that, when coupled with a feature we lost from FS9, you should be aware of.

FSX does not "alpha-fade" Autogen in the distance. This makes for a discernable "pop" of Autogen objects. SP1 batches objects in a 2 km boundary. This, when coupled with the lack of "alpha-fade," does make the Autogen "pop" a little more obvious than in RTM. We think it's a fair tradeoff, though, for the performance gain.

For DX10 we will look at bringing the "alpha-fade" back.

Performance Note 2:
We changed our bucketing code in SP1, so if you use "Restore Defaults" from the UI, you may see different default settings. What did we do? Well, RTM only detected up to 512m of memory and used that as the "Ultra High" setting. With the 768m 8800 card out, there was no way to stratify that above the 512m 7950s. So we detect 640m of graphics memory and treat 640m and greater as "Ultra-High" .

There is an issue on Vista, where on some cards it can report a "shared" memory value larger than the physical value and that confuses our bucketing code. If you don't have a DX10 card and you are getting bucketed "Ultra-High" , change your settings down. We'll take a look at this again in DX10 to adjust the Vista bucketing

Tweaks
Tweaks, or special settings in various config files, are a time-honored Flight Simulator tradition and SP1 is no different.  Here are the new tweaks for SP1:

For the fsx.cfg config file:

There is a tweak to control scheduling of threads on cores.

It is not recommended to change these settings unless you have a performance reduction and/or maxed out CPU loads in the PerfMonitor. The tweak is

[JOBSCHEDULER]
AffinityMask=n

where

 

 n  num of cores scheduled   processor bit mask  1  = 1 core  0001  3  = 2 cores   0011  7  = 3 cores   0111  15  = 4 cores  1111

 

The processor bitmask shows you what cores will be enabled ( 1 ) and what cores will be disabled ( 0 ), primarily to allow you to see the pattern and be able to pick a bitmask for 8 and 16 cores or more when they are available.


Dan Dominik                                                                           

"I thought you said your dog does not bite....
                                                                That's not my dog."

Share this post


Link to post
Share on other sites

Windows uses Intel HyperThreading (HT) technology to improve performance across the system. Since most threads stop and wait for others at some point, the processor can be utilised to process other threads. The CPU can be set up to act like two separate processors (Logical Processors) . Windows programs are inherently multi threaded, most sleep all the time and so several threads can run on a core apparently simultaneously. Many of the threads of these programs have commonality using the same data structures and memory and so HT can enhance the performance. Plus, HT means double the processor count to 99% of the threading going on under the hood. FSX uses the Network Subsystem and this responds well to HT so it is usual to see better performance with HT enabled. Windows generally works better with HT on otherwise HT wouldn't exist. Conclusion: FSX uses HT.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
Share on other sites

@Sddjd

 

Tyx for that post...informative and interesting.

 

However, I think we are confusing multi threading and hyper threading.

 

What I am after is HYPER threading....not multi threading.

 

If I am not mistaken then Phil Taylor talks about multi threading.

I know FSX uses all my four REAL cores.

(Just not as effective as a modern game....but still, we will take every bit of help right!)

 

I also know it does NOT make use of my four hyper threading cores.

This is why I have hyperthreading turned off in the BIOS.

This reduces the temperature of the overclocked CPU and thereby allows for a little higher overclock.

 

This little higher overclock helps FSX because most of FSX runs on core 0 and some on the other cores.

So if core 0 is faster, then FSX runs faster/better.

(Note: with a 4 core CPU we have a core 0, 1, 2 and core 3)

 

And the less addons, like PMDG and OPUS weather, etc etc, do not use core 0, but instead use core 1,2 and 3 the better it is for FSX.

And better yet, if those addons would use the four HT cores that FSX cant use anyway, then yihaaaaa :-)

 

I am sure that the Win7 OS uses hyerthreading, but the question then is what helps more:

- useing a higher overclock on the four physical cores that FSX uses, and with HT disabled, or

- using a lower clock, which will effect FSX!, in order to have the Win7 OS make use of four additional HT cores?

(of course if we were talking HT off or on at the same clock, then yes by all means turn it on......but with an overclock it is either one of the above.......cant have your cake and eat it)

 

I was adviced (by an FSX and hardware specialist) that the first option is more benificial for FSX, so I have HT off with a higher clock.


Rob Robson

Share this post


Link to post
Share on other sites

 

 


However, I think we are confusing multi threading and hyper threading

 

You're right. Hyper-threading is an Intel concept.

 

In the days of single core processors (Pentium 4), Intel sought to get some advantage over AMD, and so invented this concept.

 

And to make the best of it, you had to compile your binaries using Intel compilers.

 

With 4+ core processors, best to turn "hype"r-threading off. That way you guarantee all work is performed on physical CPU cores rather than logical (fictive) ones.

Share this post


Link to post
Share on other sites

Windows programs are all multi-threaded and all run on a single processor. The system gives a time slice to each thread in turn, so it appears they all run at once, but in fact they all take turns to run on the processor. Each turn saves out the state of the current thread and switches in the last state of the next thread to continue processing. With a Hyperthreading core, the core acts like two logical processors and is more efficient than acting as single core with threads starting and stopping all the time. Looking at FSX running on a CPU with multiple HT cores shows that Windows places the threads across the cores, not the logical processors. The core still must accept other threads, but it can do that more efficiently with HT than if it was a single core. With HT turned off another thread will properly interrupt the current thread to get process time. Affinity Masks can only prevent cores from being used by a thread, they are still available to all processes in the system. To save heat build-up the intense processes must be spread over the CPU with AM, HT on or off may make a tiny difference depending on the layout of the chip, and could be hotter. In the “old days” motherboards with 4 CPUs may have had one pair with more efficient cooling, the intense threads, usually SQL Server would be forced on those with AM. Irrespective of how many cores FSX will use, the underlying system of concurrent disk and network activity benefits from HT on. Usually HT off is less efficient.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...