Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Macfie on July 09, 2011, 04:13:10 pm

Title: Multi-threading
Post by: Macfie on July 09, 2011, 04:13:10 pm
Are there any plans to incorporate multi-threading into the game engine?  I'm finding that the capacity of the processor is limiting my ability to run the SCP with all the bells and whistles.
Title: Re: Multi-threading
Post by: Spoon on July 09, 2011, 04:19:26 pm
Are there any plans to incorporate multi-threading into the game engine?  I'm finding that the capacity of the processor is limiting my ability to run the SCP with all the bells and whistles.
To repeat what I've heard endlessly about this subject:
Not gonna happen, pretty much requires a rewrite of the whole engine
Title: Re: Multi-threading
Post by: Kolgena on July 09, 2011, 04:23:18 pm
2.4GHz on a C2D from my experience is more than enough to run this game maxed out. I am by far GPU limited at 1680x945 with a ATI 3650m HD. It's not like the game requires THAT much CPU horsepower.
Title: Re: Multi-threading
Post by: Macfie on July 09, 2011, 04:29:44 pm
I'm running about 2.34 Ghz and hit the peak output periodically while playing on 1440 x 900.  I really haven't had a problem with my GPU
Title: Re: Multi-threading
Post by: Kolgena on July 09, 2011, 04:40:36 pm
Hmm. You probably play much more strenuous mods on a real GPU. War in Heaven R1 is always GPU throttled for me.
Title: Re: Multi-threading
Post by: Valathil on July 09, 2011, 04:47:57 pm
Not only would it require a rewrite of the whole engine. It would also require to profile this ***** so perfectly accurate to find things that would we be able to run in parallel that it would be better to just rewrite the whole engine with multithreading in mind. So yeah you can either rewrite the whole engine or think about it REALLY hard and then rewrite the whole engine.
Title: Re: Multi-threading
Post by: Kolgena on July 09, 2011, 04:54:53 pm
Well... seeing as the core of the engine is already hopeless spaghetti code, why not?




Jk, don't kill me.
Title: Re: Multi-threading
Post by: Valathil on July 09, 2011, 06:43:08 pm
You start ok? i look over the code once your finished
Title: Re: Multi-threading
Post by: Zacam on July 10, 2011, 12:14:45 am

Well, on windows you enable processor affinity to run on more than 1 core (which is what FSO does by default)

However, mileage may vary and it's not a supported operation if you choose to under take it.

As already mentioned, we would need to have a lot more HLOMs (High-Lover Order Managers) in place that are thread safe and thread aware to co-ordinate before we could implement multi-threading. Which means re-writing a lot of stuff into being thread safe first so that it can even be managed in the first place.

That being said, there are still a few places where the engine can gain some enhancement without resorting to a multi-threading re-write project. While there may come a day when that becomes the final obstacle, we'll hopefully have the code base in a condition where the transition will take less effort than it would right now. Assuming of course that it ever becomes a constraining limitation on the performance of the engine, which at this point is still some what doubtful as there many places that still need improvement. (Collision detection and handling, Asteroid field management, just to name the biggest two).

There is also a significant question as to HOW we could approach going about adding multi-threading. For example, we can't really leverage OpenMP (which is related to Multi-Processing, not necessarily Multi-Threading but could still be something to cite as being able to give gains to the FSO Engine) because that excludes anybody that uses MSVC Express edition and that doesn't exactly help us any. Just as an example of being cautious about how to go about doing things.
Title: Re: Multi-threading
Post by: chief1983 on July 10, 2011, 02:42:13 am
Not to mention, there are still (supposedly) areas of the code that could be optimized to keep single-core performance sufficient for years.  Profiling needs to be done to identify those though.
Title: Re: Multi-threading
Post by: Fury on August 06, 2013, 12:42:00 pm
I apologize for resurrecting this old topic, but I wanted to have these old posts as they are still valid and my post is directly related.

As has been mentioned before, implementing multi-threading would require rewrite of the engine. But I just have to ask, were OpenMP and Pthreads ever considered as solutions to the problem?
http://en.wikipedia.org/wiki/OpenMP
http://en.wikipedia.org/wiki/POSIX_Threads
Both supports linux, OS X and Windows platforms and so does Visual Studio, GCC and likely all other relevant compilers.

Now, the question is whether either of those actually helps avoiding rewrite of the entire engine?

Chances are that I'm being stupid and those two were looked at and dismissed. But still, posting this anyway.
Title: Re: Multi-threading
Post by: The E on August 06, 2013, 12:52:03 pm
They are an option.

But, and I am SURE we've mentioned this before, figuring out which multithreading framework to use (if any) takes a back seat to figuring out how to use multithreading in the first place, how to make it work for us. That's the big holdup.
Title: Re: Multi-threading
Post by: Tomo on August 06, 2013, 02:59:14 pm
The framework doesn't matter, there's plenty of good ones.

The first thing is the simple question: Why?

Which tasks really can be done in parallel?
- Many things are reliant on the answer from other functions, and so 'multi-threading' them would just mean one core waiting on the other and might even make it slower overall.

Of those, which of those are big and slow enough for it to be worth bothering with?

Actually the most intensive ones already are done in parallel because the GPU is doing them.

To take a literal wild guess, quite likely the only two things that is likely to be worth even trying to spin off into another thread (or pile of) are the load/cache of data (so other things can continue while doing so), and calculating each frame's collisions.

Getting either of those wrong would be pretty nasty to the game, with hard-to-reproduce issues.
Title: Re: Multi-threading
Post by: The E on August 07, 2013, 02:29:27 am
Loading level data cannot be multithreaded (As you can't multithread disc access without sacrificing performance through overhead).

Collision detection (Well, physics as a whole, really) can be multithreaded, and would be the area we're looking at. We're already kinda-sorta offloading our audio processing into a separate thread as well through OpenAL. Our game logic (AI/Sexps/Scripting) isn't heavy enough to warrant going into multithread territory.
Title: Re: Multi-threading
Post by: Tomo on August 07, 2013, 03:30:01 pm
I didn't mean multi-threading the actual disk access. That generally doesn't help.

I meant spinning off disk access into its own thread, allowing the rest of the application to continue doing other stuff (where possible) instead of sitting there waiting for the disk to come back.

I recently did that to a large data-processing application (it processes a stack of XML files that are approx. 200MB when zipped) and found that it scrubbed about 30sec off a 1 min 45 sec loading time.
Most of the saving came from ensuring the loading processing didn't stall while waiting for the disk, as whenever "need file Y" occurs, processing earlier file X could continue while Y was being pulled off the disk.

However, it's a relatively small gain (an earlier optimisation knocked 45 minutes off!) and in the case of FSO, would only have any effect in cases where other processing can continue before the file's loaded - I suspect that's pretty much only cache generation.
Title: Re: Multi-threading
Post by: karajorma on August 08, 2013, 03:02:12 am
Well loading times could use some improvement, especially on debug. I actually had to stop coding for multiplayer on my old PC cause the time it took to actually load the mission was so long the other PC would time out.
Title: Re: Multi-threading
Post by: The E on August 08, 2013, 03:19:48 am
Then that's an area that we need to profile. I have no clue where the slowdown would be in that area (aside from stuff we cannot control, like disc response times and data rates etc).

At any rate, that would also be an area where major restructuring would be unavoidable.
Title: Re: Multi-threading
Post by: karajorma on August 08, 2013, 11:52:46 am
Bizarrely it's in the generation of icons. For some reason it was taking upwards of a minute in Diaspora builds I was using. Admittedly I had a very slow PC but still.....