http://www.anandtech.com/tradeshows/showdoc.aspx?i=2868I'd say this pretty much sums it up as to why we don't have multi-thread support in FSX. Nothing new as we all knew the reasons anyway, but nice to see them validated. Valve is at the front of the pack in innovation and to sum it up in their own words:While it is listed as a challenge, one of the points made by Valve is that computer games are typically designed to make maximum use of your system. "You're doing a disservice to the customer if you're not using all of the CPU power."The short summary is that creating efficient and powerful multithreaded code is extremely difficult, and there's a very real possibility that developers will need to throw away a lot of their existing code base.Cool article and still holding out hope that some kind of frame rate improvement with the DX10 patch can be achieved.Dave

Sorry, but your assertion of "no" multithreading in FSX just isn't accurate. There IS multithread support in FSX which will utilize about 20% of a second CPU. This has been confirmed numerous times by members of the ACES Team. But they didn't have time to redo the entire FSX code, which is why multithreading in FSX isn't as extensive as it will probably be in the future. As your quote from the Anandtech article states, "creating efficient and powerful multithreaded code is extremely difficult." Senior members of the ACES Team have also posted in this forum that additional support for multithreading may be included in the Vista patch. But they are making no concrete promises, considering that hyperthreading is only one of several issues that are being dealt with. I'd rather have the ACES programmers take whatever time is necessary to do a good job of implementing multithreading, than to release something that causes more problems than it solves. Clearly this isn't a trivial problem for ANY group of programmers to resolve.

it is important to bear in mind the 20 + year legacy of the flight sim franchise and the code base.Speculation that a great deal of the code can not simply be "hooked up" to additional processors is an importance point to keep in mind.

Thanks for the topic start,I've found that if I turn off "CPU0" in my affinity choices, that FSX actually is smoother, with higher frame-rates. I can't figure out what benefit I'm getting with the current use of "multi-threads" in FSX.I love the sim, and hope ACES can continue to improve upon it. This quote below is from John Dvorak, from PC Mag, and it puts the issue into context as well from an OS perspective....we might be looking at a decade before effective multi-threading is standard at the OS level--"If Microsoft wants to keep improving its OS, there is only one hope: to somehow develop an OS to coordinate and control the multiple cores within the CPU.In other words, make a universal parallel-processing OS

The following article is also relevant.http://msdn.microsoft.com/msdnmag/issues/0...MP/default.aspxIt relates to multi-threading with code examples for straight-forward matrix processing which is particularly suited to this.Figure 9 is particularly interesting because it shows there is a downside to multi-threading. In the example chosen, at low numbers of iterations the processing speed actually falls to less than 10% of the single-thread speed, peaking at about 170% at high numbers of iterations. The reason is the overhead involved in running multiple threads.Based on my experience of writing aircraft simulations and my limited experience of writing multi-theaded code, I believe that it will be necessary to re-write all of the existing FS code to use multi-threading effectively.

And given the great reluctance of MS to do this (as documented by ACES team members) where does that leave the future of flight simming on the PC?Bruceb

I imagine that the future of FS will depend on commercial aspects. If Microsoft believes that the extra cost of re-writing FS will be recovered through sales revenue then it may re-write it: if it doesn't, it won't.

Like others have hinted at, the problem is really that many applications just don't lend themselves to multi-threading or parallel processing. There is an inherent overhead in splitting a program into seperate threads or processing units, and to keep things synchronized you end up having to keep specific threads in wait states (which just wastes processing cycles) or come up with complex event based systems which have far more overhead than running it on a single thread!Yep, it is annoying to see your HT proc running at 60% overall, with 100% on one processing stream, and 20% on the other (and that is how it runs on my system) but overall it probably really is more efficient that way!

The FSX Extension Project was started in 2004 where no Dual-Core systems are expected on the Market and Multithteading was only a very young and not well supported baby w/o Performance Benefits. So no wonder that FSX cannot benefit to much from Multicore-Architectures.But there is a second more important Reason. For Multithtead- or Multicore - Support you'll need to refactor (reengineer) your whole SW-Design to a parallel oriented Architecture. This was mostly not done for the FSX, most work was done only for extending the still existing Code. So FSX remains in most of it's SW-Structures a Singlethread - System that is designed and optimized to execute multiple cyclic repeated Functions (Physics, D3-models, Scenery, Weather, Traffic etc...) in a strong single-task oriented Architecture. Only some smaller Tasks for preloading Textures and Scenery data are paralelized yet.FS-XI may benefit a little more (I assume round about +20%) from Mutiprocessor Systems but the "natural" Brake for the total Refarctoring expected by most of us will be the limited Project Budget, the limited Schedule and - not last - the limited Parallel-System and Oldd-System Knowledge of the involved SW-Designers.So don't expect too much - also for the next Release.A little hint for common too high HW-Expections on HW-Architectures with many Cores that will follow in the next years:A System with only 8 Cores may need the Performance or more than 3 Cores to synchronize the Work of the parallel executed Tasks for only one well and strikt parallel desigend Application. A System with more than 25 Cores may need much more than 50% of its summarized possible Performance to synchronize all actual parallel executed Tasks. If you have only parallel updated SW-Designs - as again to expect for FS-XI - then you may not be able to reach a summarized Performance of 40% from a Quad-Core System in 2008.Always Happy Landings Heinz-Werner[Programmers never die, they just GOSUB]

The multi-core brigade are a weird mob.They've paid the premium price for a multi-core CPU, and are then disappointed that FSX doesn't 'r0x0rz'.This is akin to buying a big expensive 4WD off-roader and then wondering why you still can't get round a road track quicker than a sports car with less kWh...I work with dedicated MT software - 3DS Max8. Even though it is programmed for MT, it still only gains the full effect when rendering; which ISN'T when I am sitting in front of the PC! It just means that when I leave my machine to render overnight it will be finished by 6am instead of 10am, so I can get the image to the client by 9am (I still tell them it will be ready by 10am though - trade secret!).FSX simply doesn't scale to MT, even if ACES rewrote the software. The reason is the tasks aren't 'bucketable' - there aren't many tasks in FS that don't effect every other task. Maybe AI planes IF you could put up with stuttering of the AI - they might appear to 'warp' from once place to another if the cores get out of sync (and they will - one core will still have to do OS / file tasks, the other won't).For those who bought multi-core CPUs - I saved the money I would have spent on an AMD X2 and bought a cheaper AMD 64 single core for my games machine. Why? Single core performance per clock is better on a single core CPU, and cheaper per clock too - the saved money was put towards a better GPU! (I still spent the cash though! :-P )What WILL (hopefully) have an influence on FSX (or maybe FSX+1) is DX10's addition of code supporting GP-GPUs or 'physics processors'. Currently support for these systems is akin to the early days of 3DFX vs Glide vs Riva vs whoever else. DX10 will hopefully unify code for physics coprocessing. Aegia already have a physics accelerator out, and Nvidia is developing the General Purpose GPU (GPGPU) concept. This could have a real effect on FS(n), much as GPUs had a huge effect on the transition between FS95 - FS2000. The off-loading of physics functions to a GPGPU allows the software gain significant speed without multi-threading, as it lets the CPU add a few more cycles of AI planes, autogen, texture fetches while the GPGPU does the lift/drag/thrust/weight calcs functions. Note that this is NOT the same thing as MT, as there is no overall CPU control overhead required. You can't do this on a parallel core as there is no in-step control over the other core - you need to run extra code to do that.Example - offloaded physics calcs on the GPGPU take, say 16 ticks per frame to generate. The CPU checks back after 16 ticks and BING! there's the new aircraft state. But that is ALL the GPGPU is doing - it only every takes 16 ticks, the CPU can be assured that once a certain step is reached, the aircraft state data WILL be available. This is exactly what modern GPUs do.On the other hand, a multi-core machine offloads the same data to a parallel CPU. This may take, for a start, 200 ticks to calc the new state, as the CPU doesn't have built-in physics functions. Nonetheless, this is still quick; BUT when the master CPU checks back to get the aircraft state, the 2nd CPU is only up to tick 198, because some other function did 2 ticks worth of answering your email, or checking to see if it needed to run a screensaver, or something. So your main CPU has to wait a whole program cycle to check aircraft state again - so your aircraft state took 398 ticks instead of 200. Instant 50% overhead. It may not always do this though - sometimes it will be quicker, sometimes slower, but this all means the master CPU must delay at some point to wait for data. With timing (in this case a frame-by-frame app) being critical, a parallel CPU is always going to lose any theoretical performance gains.*THAT is where the 'magic' of multi-core systems comes unstuck. This kind of mismatch is of no consequence for CGI rendering, as there is no need for the CPUs to even talk to each other, let alone run in lockstep - they just chew at different ends of the task until none remains.Real-time sims require lockstep functions - if the aircraft state calc is a bit late, the whole program has to halt while it catches up, lowering frame rates. Or it can just keep running and you get stutters.In summary - multi-cores might look fancy-schmancy in your sig file, but are only useful for letting you answer email or encode video while flying. The real performance will come from physics processors and GPGPUs, which will hopefully start appearing once DX10 has settled in. My guess is 12 months from now we'll see some exciting and affordable hardware, at about the time DX10.1 or DX10c appears! :-)* Read up on how various system designs work - in particular multi-cored or distributed-net systems like Linux. Did you know Linux is NOT classed as a 'real-time' OS? Which is why it isn't a good platform for graphics and timing-intensive games (without some heavy customisation, anyway). The people who keep saying they need a Cray for FSX should read this, especially as Crays are a bit old and slow these days. They were pretty slick in the 80's though. Also, try running FSX in a WINE client on a teraflop-terabyte distrubuted-net supercomputer with 512 cores (you do have access to one don't you?) - I'll bet you my 7800GTX that won't get FPS better than about 4! :-D

If Your understanding of this multi core and mutli threaded apps is as good as your perception of others motive behind why they gripe about FSX and Multi Cores, I am better off trusting that Anadtech article Dave posted in his first post.;)Manny

Multi threading is not new- enterprise apps have been doing it for years- SQL, Oracle and many other apps.It's relatively new to gaming, but Falcon 4 Allied Force does support multi threading fairly well, and runs amazingly on a Quad core CPU (check www.simhq.com for more info)

Yeah that's pretty much my point is that yes it can be done. It was just decided for whatever reason(s) that it would not be done for FSX. There's always hope for FSXI.

Thanks for your very extensive Answer and your first Statement "...They've paid the premium price for a multi-core CPU, and are then disappointed that FSX doesn't 'r0x0rz'..." was exactly what should be the Extract for the initial Poster. But I still read in his last posting that he hopes (more than I) for FS-XI and also that he is optimistic pro-Multicore oriented for other more parallel desiged "Games".I've high Experience for long Years with redundant paralllel architectures (Safety related redundant System Design) and also with Realtime OS on single- and multi-core systems.But I learned also much from your very intresting Posting. I only would disagree in a very small Point. You wrote "...Real-time sims require lockstep functions - if the aircraft state calc is a bit late, the whole program has to halt while it catches up, lowering frame rates..."Yes, Lockstep Functions are necessary but no, the whole program is not allowed to halt while it catches up (or better said minimum not allowed in a realtime-Architecture). What effectife will happen on a RTOS (and also probably on a "only" OS) is that the "hole program" or better said the "main task" has to continue with reprocessing the still calculated (and now outdated) results from the previous Lockstep. This will then also give the Effect you still described in the Example that the "aircraft state calc" Result will stutter for a while because it has again to process the Data from the previous cycle while the pararllel running aircraft state calc task still will process the continued data for the next Lockstep. So in worst case your Aircraft may "stop" for at Lockstep cycle while the rest of the Simulator including AI, Weather movements etc. will continue with constant high Framerate.Regards Heinz-Werner

>Like others have hinted at, the problem is really that many>applications just don't lend themselves to multi-threading or>parallel processing. I beg to differ. FS lands very well with multi-threading code and parallel processing.>There is an inherent overhead in>splitting a program into seperate threads or processing units,>and to keep things synchronized you end up having to keep>specific threads in wait states (which just wastes processing>cycles) or come up with complex event based systems which have>far more overhead than running it on a single thread!>Again. This in general is true, but not with FS. I can say this particular situation (MS Flight Simulator). Every aircraft (AI & Player) can be controlled by their own thread. For ATC, if you want to get fancy, each frequrency can be run by a seperate thread. Rendering is one big thread. All these threads have next to nothing common data (share data), except the rendering thread will use the aircraft position data to correctly place the aircrafts at the scene, and the data is READ ONLY for the rendering engine, which means only very limited synchonization is needed between the rendering thread and the aircraft threads. On top of that, synchonization is between the rendering thread and EACH aircraft thread, NO synchonization needed between the aircraft threads. Like the rendering thread, the ATC thread only need READ ONLY access to aircraft position data. Also minimum synchonization required. ATC commands to AI aircrafts can be transmitted to the aircraft vis a messaging scheme. The AI aircraft threads DO NOT have to respond immediately. (do real pilots respond to ATC in miniseconds?). Regarding the weather thread. It only has READ ONLY data for the aircraft threads and the rendering thread, and they don't have to locked while being updated.