I'm waiting with bated breath for the new cloud drawing LR mentioned in a past blog post. Glitchy clouds still show up often and they've admitted that past bandaid patches have been frustratingly inadequate but necessary to allow other features to be released. If the final clouds match the quality of the recent atmospheric lighting improvements, it's going to be even more spectacular than it has been.

The asterisk in OP thread title is that the home PC isn't even being fully utilized right now with this sim. Folks scream about "why doesn't my CPU run at 100%!?!?!" without realizing that what is being done already on little more than 1-2 cores, is stunning. Multithreaded XP will truly sing when that capability finally arrives.

4 hours ago, blingthinger said:

Multithreaded XP will truly sing when that capability finally arrives

No to divert the topic, and this is no doubt true, not just of XP, multithreaded anything should rocket along. Long, long time since I taught mainframe systems but I remember multiprocessing was done with some fair sophistication in the IBM systems software, very simple routines with specially architected instructions for efficiency. And it still took a massive amount of overhead, probably losing nearly one whole CPU's worth of capability in a six or eight way box. Absolutely no idea (or real interest now) how this is done in the PC realm, but with all the processing capability available it must eventually be do-able. Should be fun!

4 hours ago, blingthinger said:

Multithreaded XP will truly sing when that capability finally arrives

I find that funny. Watching the last update for ms, it was mentioned they reduced multit threading as it was one of the items causing the performance hits. we wait to see.

hehehe. I expect the beta testing period to last a while on that one. But once it's properly tuned, yeah, it should be pretty slick. Finding the right balance across all these various multi core configurations that we have at home (hyperthreading vs. x3d ccd vs. P and E cores, all with varying compute speeds)....LR might take a while to figure out how to juggle all that.

It is possible to do too much threading and end up making it worse. I'd say that's a good example of going too far by threading too many of the things.

 

4 hours ago, andy1252 said:

losing nearly one whole CPU's worth of capability

Oh that's interesting. I'd think we'd probably call that a "main thread" now. Or was that just the OS kernel thinking, way back when? Much less overhead these days. That or maybe that the percentage time required to increment a semaphore is just so much smaller than what it used to be? Don't worry. Doing all that really well still requires lots of fancy hardware in a modern compute cluster (fast interconnects, cooling, etc). Home pc is comparatively easy.

Edited October 15, 2025Oct 15 by blingthinger

5 hours ago, mjrhealth said:

I find that funny. Watching the last update for ms, it was mentioned they reduced multit threading as it was one of the items causing the performance hits. we wait to see.

I saw that you posted this earlier and thought your statement was wrong initially. I went back and rewatched that section of the dev stream and you are right. He basically said trying to spread over too many cores is overall more expensive and uses more resources. Even though it initially resulted in faster frames, in the end it is more expensive on the system.

My understanding of what he said:

In 2024 they made everything multithreaded spread across multiple cores (CFD, weather, surface simulation, etc.). It was multithreaded but the SIM still had to wait for the other cores to finish before it could move on to finish the frame. With the latest sim update 4, they moved some simulations back onto a single core but not the main thread. SU4 made things asynchronous, so the main thread isn't blocked waiting for the work on the other cores to be completed. This resulted in better performance.

Basically, a reminder that multi-threading/multi-cores is a not miracle solution. Simply putting more things on more cores could result in overall less performance. Sometimes less cores equal better.

Edited October 15, 2025Oct 15 by brinx

7 minutes ago, brinx said:

He basically said trying to spread over too many cores is overall more expensive

This is something that most users do not see. It takes quite a bit of "overhead" to organize and supervise the distribution of work onto many cores. This is not unlike having multiple offices in multiple countries working on the same project (like a computer game). There is a point of diminishing returns, if you have two offices, work will go almost twice as fast...but if you have 1000 offices, chances are that just getting them all organized is taking so much effort that the gain is simply not worth it, anymore.

Same in computers, if one core does job A and the second core does job B, but core A spends a lot of time asking "hey, are you done with job B yet?" and the other core has to stop for an instant and reply "no, not quite yet, hold on for a bit longer"...multicore is not easy and not a magic bullet for everything.

1 hour ago, blingthinger said:

Oh that's interesting. I'd think we'd probably call that a "main thread" now. Or was that just the OS kernel thinking, way back when?

From memory, there was a machine (architected) instruction called "compare and swap" (CS) which examined a 4 byte storage field called a lockword. Lots of lockwords, each representing a specific OS management function. Whenever one of those functions ran, the first thing it did was to try and put the CPUid it was running on into the lockword. The CS instr compared the lockword contents with a register value (of zeros) and if true, placed its own CPUid in that register and continued. If the register was non-zero, it would be because that same code was already running on another CPUid and so had put that CPUid in there already. So the second instance of the function could not proceed (but also now knew where it was already running). 

If the lockword was already held by another CPU, the OS function could not proceed, so the "choice" was either go and do something else or loop ("spin") on the comparison until the lock became free. I don't remember the details of the specific locks, but I think there were something like about 40 of them, and only a couple were the "go and do something else" (actually called "suspend locks"), most of them were spin locks. And that's where the overhead came from - in what would have been considered a large multi-CPU mainframe (and the biggest ever made before CMOS engines kicked in contained eight CPs) as you got above four CPs the spin-loop overhead went up dramatically.

As I type this, more comes back to me! There were also mechanisms built in to the OS to automatically detect "excessive spin loop" conditions. You weren't supposed to hold a spin lock for long and doing so implied a problem in the function holding the lock. There was another function in the OS called the Recovery Termination Manager and one of the first things it did if invoked (via the "abend" or "callrtm" service) was check for locks held by the spinning CPU and free them.

Wow, I haven't thought about any of that stuff for years, probably decades. Amazing what's lurking under the dust at the back of the brain, ain't it?

5 minutes ago, andy1252 said:

most of them were spin locks. And that's where the overhead came from - in what would have been considered a large multi-CPU mainframe (and the biggest ever made before CMOS engines kicked in contained eight CPs) as you got above four CPs the spin-loop overhead went up dramatically.

Spin locks are still a thing today. Onus is on the app dev to both sync things nicely and make sure they don't swamp the system with compute jobs.

In the case of a real time gfx engine you certainly don't want to swamp out your main thread! I wonder if that's another thing asobo was guilty of. These days you can also set affinity to leave a single core open for the main process but most apps don't do that. More wise to let the OS handle it. Users can do it manually though.

 

13 minutes ago, andy1252 said:

You weren't supposed to hold a spin lock for long and doing so implied a problem in the function holding the lock.

Modern kernels are preemptable which prevents a single thread from hogging/blocking the single OS main thread or I/O.

How much of this waiting back then was a result of slow "motherboard" data bus? Did these compute units each have a local memory cache?

 

9 minutes ago, blingthinger said:

Modern kernels are preemptable which prevents a single thread from hogging/blocking the single OS main thread or I/O.

How much of this waiting back then was a result of slow "motherboard" data bus? Did these compute units each have a local memory cache?

Getting to the end of my own memory buffers here! I'm talking about IBM's s370 machines onwards, and their MVS and subsequent zOS operating systems. From around 1972 to around 1994 we're talking pre-CMOS machines, all big old ECL bi-polar circuits and eventually water cooled. There were a couple of "attached processor" s360 machines in the '60s but that wasn't strictly the same sort of architecture. 

MVS (and its precursor and subsequent systems) always was a preemptable, interrupt driven system, and was actually incredibly efficient for the time. I worked as an operator on machines with 512k (yes - Kb, not Mb and nobody had even heard of Gb back then) main store supporting more than a thousand remote users simultaneously. OK, text terminals only and not necessarily sparkling response times, but functional and running 24/7.

By the time I was teaching this stuff we are talking 1980s and 1990s, and these older ECL machines were approaching their peak. And hitting their barriers. But they always did have local memory caching, both CP local and dedicated shared memory, and the internal busses also grew in capability over the generations but were never a bottleneck at any point. These systems were massively over-engineered, and generally would run endlessly without any downtime. Yes, you'd occasionally get one fall over and die of apparently unknown causes, but it was an incredibly rare event and would result in engineers being flown in from all sorts of places to deal with it.

Long since lost touch with that world, even the last ten or more years before I retired I'd gotten out of all that (bought and ran a couple of second-hand book shops - much more civilised) but I enjoyed it at the time, even if the technology seems like ancient history now. (if you want to gawp at something really ancient and Star Trek'ish, google "Ferranti Orion" and see if you can find a pic of its console. My first ever job after leaving school was as an operator on one of those)

I'll leave it all there rather than derail this thread any further, but feel free to PM me if you want to talk more old mainframe stuff. 

1 hour ago, Litjan said:

This is not unlike having multiple offices in multiple countries working on the same project (like a computer game). There is a point of diminishing returns, if you have two offices, work will go almost twice as fast...but if you have 1000 offices, chances are that just getting them all organized is taking so much effort that the gain is simply not worth it, anymore.

If you think it’s hard to get multiple offices to work on a project, just try to get multiple departments! 🤣

anyhow, good analogy👍

I wouldn't expect multithreaded XP to use more than 4 cores. One for the main thread that does the management and ATC, another for the user flight model, a third for the weather and a fourth for something related to AI or ground traffic. As usual, all leftover cores are used for scenery loading. That configuration should fit snugly on low end hardware as I think anything less than quad cores or dual cores with HT/SMT is pretty much extinct in the XP12 userbase by now.

2 minutes ago, Bjoern said:

I wouldn't expect multithreaded XP to use more than 4 cores. One for the main thread that does the management and ATC, another for the user flight model, a third for the weather and a fourth for something related to AI or ground traffic. As usual, all leftover cores are used for scenery loading. That configuration should fit snugly on low end hardware as I think anything less than quad cores or dual cores with HT/SMT is pretty much extinct in the XP12 userbase by now.

Xp pretty much uses all the cores for texture loading, and Ai are spread across cores.

8 hours ago, Bjoern said:

user flight model

Processing scenery drawing costs so much more than the flight model.

6 hours ago, blingthinger said:

Processing scenery drawing costs so much more than the flight model.

yeah. this.

The really big wins in performance come from not repeatedly calculating things that give the same answer each time and take a long time to calculate, caching results then just looking them up is generally far faster than calculating them.

Main role multicore/threading comes in is calculating them before they are needed, and recalculating them before the changes are needed, there is a good few opportunities to improve there (can see them in the various profiling tools), but it is no easy task, and very prone to break things.

The easy way to think of it, is multicore doesn't let you calculate things faster, but it does let you calculate a lot more things at the same speed.