Threaded FM – Probably Not

We were looking at running the flight model on a separate core from the rendering engine.  The idea is that the less work must be done in series with that main rendering thread, the higher the total frame-rate.  But now it looks like it’s not worth it.  Here’s my logic:

• The rendering engine now runs best on at least two cores, because all loading is done on a second core.  So unless you have a 4+ core machine, X-Plane is utilizing close to all of your hardware already.
• The flight model isn’t very expensive – and the faster the machine, the less percent of time the flight model takes (because it does not become more expensive with higher rendering settings).
• Therefore I must conclude: threading the flight model would only help framerate on hardware that doesn’t need the help – modern 4+ core machines.

So why not code it?  (Even if the improvement in framerate would be pretty low, it would be more than zero.)  Well, besides the opportunity cost of not coding something more useful, there’s one thing that makes a threaded flight model very expensive: plugins.

Plugins can run during various parts of the rendering engine, and they can write data into the flight model.  I bounced a number of ways of coping with this off of Sandy, Andy, and others, and I don’t see a good way to do it.  Basically every scheme includes some combination of a huge performance hit if a plugin writes data from render time, a lot of complexity, or both.

So the simplest thing to do is to not try to thread the FM against the rendering engine, and instead continue to use more cores to improve the rendering engine.

This doesn’t apply to running more than one FM at the same time (e.g. AI planes and the main plane at the same time).  It’s the question of the FM vs. the rendering engine that I think now is not worth the benefit.