– Put in a big texture-paged photoscenery pack…more cores the merrier.

– Crank up forests to tree hugger and airport detail to "insane"…first vs. second core becomes a big deal.

– Watch fps as you go over the DSF boundary…the third core becomes a big deal.

– Depending on your vid driver that 4th one might be nice too.

My point is this: if an application is bound by its pure ability to talk to the video card sequentially, a core isn't going to help. And X-Plane is getting close to that.

If those other games benefit from a second core, we can only conclude that when running in single-core mode, non-render-loop work is being done on the first core. This is exactly the case for X-Plane.

My original point was that there isn't much low hanging fruit on the main thread. Dirk is absolutely correct that parallelizing multiple physics simulations is a win – he's right, and it's something we've already started the architectural work on (a while ago).

But if you look at X-Plane's main loop, it's mostly sequential drawing, with a little bit of flight model (unless you have the AI planes on).

The big win in future multi-core will be using those multiple cores to further pre-process the rendering load to maximize the job the first core can do in splatting out triangles. This is already what we do for forests. (Compare v8 to v9 forests to see!)

Those who know how to use "Shark" might note that the 3-d clouds chew up some fps and speculate as to whether that can go to a thread. The answer is perhaps, but the 3-d clouds are also an algorithm dying for GPU optimization..I think we need to pick a more GPU-friendly approach first, then decide how multi-core cleans up the rest.

(As a developer, I consider multi-core to be a more flexible technology than shaders, so my suspicion is that it will be easier to find a way to thread what works on the GPU, not to find a way to use the GPU for a threaded algorithm.)

http://www.tomshardware.com/reviews/multi-core-cpu,2280-10.html

All games show a significant (near 50%) jump from single to dual core and many show a noticeable gain going from two to three cores.

The Unreal3 engine (and games based on it) also shows a significant improvement even when going from three to four cores. As do many other modern engines.

You just can't keep adding more and more work for a single core while the performance of each core in future 6 and 8-core CPUs will remain roughly the same as today (clearly evident in the public roadmaps of both Intel and AMD). That's like driving at 150mph straight towards a concrete wall.

As mentioned before, improving pure fps with multiple cores is nearly impossible for architectural reasons.

People who just spend lots of money on a quad-core CPU don't want to see CPU usage at just 25% while the sim struggles to maintain a flyable framerate. Even if it only resulted in a 20% performance boost, seeing close to 100% CPU usage would still be reassuring. At least you know your computer is "trying" to maintain a flyable framerate – the remaining three cores aren't just twiddling their proverbial thumbs.

Single-threaded performance won't improve much over the coming years. The future is 8-core, hyperthreading CPUs (16 threads) even on the desktop. Therefore, performance improvements in X-Plane will eventually stagnate. There's only so much you can do in terms of optimizing the code. Why not do both? Write highly optimized, multi threaded code. One doesn't have to exclude the other.

I have a couple of questions / suggestions that are not fit for the comments here – could you drop me an email to continue this, please? First at Last dot org

That is true – I do not know your qualifications – you could be an expert in the field. I only know that you don't have access to X-plane's source…so you may be very qualified to solve X-Plane's problems, but may not have a lot of situational awareness as to X-Plane's internal development road map.

(Of course, this isn't actually true…we did have one user who is also a developer run Shark on the shipping binary and correctly point out that we had let memory allocation code run in the main flight loop. His analysis was completely correct despite not having source access!)

Anon: I do not agree with what you have posted here, but I will save it for another blog post because it is both a complex and somewhat unrelated discussion. (That is, the lack of multi-core in x-plane isn't about wanting to run on on e core, it's about not having had time so far to FINISH the threading of the AI planes* and modern GPUs not playing with threaded renderers very well.) I do agree that we can't be too concerned about old hardware – I will post tomorrow why we can't actually get much leverage from dropping hardware.

* We have already done some work to thread the AI planes – it was in either 863 or 900. But since it isn't 100% done, you get zero threading benefit. 🙁

Interesting discussion! I just have to pin my word down as I fell there are a -huge- amount of users who feel just the way I feel. That is, that I feel you are a bit too concerned about the fact that XP has to be possible to run on a 2001 year machine. This really halts the development although you could add options to turn this and that off. You see, the whole mentality around the programming gets influenced and in the end one makes the same conclusion as before; to not make -too- revolutionizing features etc. This is really what XP users are expecting nowadays. I don't think that many are running XP on 800 mhz PIII's with 256 mb ram. And if they are, well, how fun is it to run the sim with basically -everything- turned off or at "low"? That would just make XP look like 1997 games.

This may have been confusing to read but in the end I just want to encourage you to take some new fresh initiatives and make the sim at least require HW that is from say '05. Sim enthusiasts as myself are running with good HW already. Speaking of myself I am running the sim with a i7 920, 6 gb ram and a 285 GF card. My friends are running XP with at least dual cores and other hardware that is like maximum 2 years old.

Anyway, thanks for the development and good job you are putting into XP! It's really appreciated!

Yes, "multi threading" in itself is indeed a weird request in that it talks not about a feature but a programming technique.

not to belabor the point – you don't know who I am and what I do for a living. I understand the issues of multi threaded programming (and getting the best possible performance out of multi core systems) better than you might assume.

I am happy to hear that the X-Plane developer team is striving to take better advantage of the available cores. I'll admit that looking at both the 9.30 betas and 9.22 I am rather disappointment with the success of those attempts so far. My suggestions were based on my understanding of which tasks can be implemented independently from the core of the software (yes, it's really hard to use multiple threads for the rendering – see my first comment). So putting things that are inherently independent (like the ATC or the weather engine or AI planes) on separate cores to relieve the main thread and at the same time increase the realism of the simulator seemed like a good idea.

If there are reasons in the X-Plane design that make that impossible then I think there might be something odd going on here that needs to be addressed, eventually.

Anyway, I love the software, I wish it would do some things better or differently, but I'm in no position to comment on the code, not having seen it (there's a reason why I'm mostly an open source person…)

Dirk, you have either misunderstood my writing, or I wrote something compeletely different from what I meant to write.

My point is NOT that X-Plane should avoid parallelization, avoid multi-core, or assume that single cores will get faster. That would be silly!

My point IS that the decision as to when and how to apply multi-core technology cannot be made without understanding the internal data structures and algorithms of the product, and thus it is not something that a casual user can meaningfully comment on.

(I have received emails from other game developers discussing techniques for parallel rendeirng, and those have been fruitful discussions. But this blog post is in response to seeing multi-core lumped up with user-level features.)

In other words, without the code, you're just shooting blind…some suggestions will turn out to be good for multi-core, some will turn out to not be good (and sometimes for obvious reasons, sometimes for surprising reasons).

The cause of my rant is that I _agree_ with you. Multi-core is where hw is going. Thus suggesting we use it is like suggesting that we use RAM or a GPU…we consider the full hardware capabilities in EVERY feature we do.

Please do not mistake my side point (a better algorithm is preferable to using a second core) with a statement that we should not fully use the hardware. I believe efficiency improvements are better than using more hardware because it's a solution that is wide spread and saves the hardware for yet another improvement. But I am not trying to avoid using the hardware.

The actual reality of X-Plane is just about opposite what you describe in your comment…a steady increase in the number of cores incrementally with each new patch, and steady improvements in the decoupling of those threads for better multi-threaded usage.

If we don't use as many cores as you would like us to, I can only argue that making X-Plane multi-core isn't easy or obvious. Threaded programming is not simple programming, and it's made worse by the state of the OpenGL API (WRT threading). But the trend in X-Plane's implementation over the last few years is: use more cores, use them more efficiently.

(By efficiently here I mean: the code that can run on other cores needs to run independently so we don't idle the cores more than necessary when there is pending work to be done.)

Right now we use multiple cores for:
– Loading new DSF tiles.
– Changing the coordinate system.*
– Building 3-d scenery from the DSF (this includes airports, forests, roads, facades, planting objects, etc.).
– Loading textures.*
– Recording QuickTime movies.
– Supporting G1000 hardware in the pro versions.
* These tasks are not bound to a finite number of cores.

That list isn't nearly as complete as it could be…and most of the tasks should someday be in the * category and aren't. But with ever patch the list gets a bit better.