Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Pilot Of The US on September 29, 2005, 12:45:11 am
-
I was wondering, does the SCP version of freespace 2 use both cpu's or "cores" (in the newest cpu's, i beleive) when run on a system that has them?
If it doesnt, what magnitude of work will the code require for this to be possible?
-
I'd be fundamentally astounded if the answer isn't No and More then will ever happen.
On the bright side, if you've got an nV 7800 series with that dual core, the latest drivers might help out some.
-
Well, you can run an antivirus program, Folding@Home, or SETI@Home in the background :D
-
I'm sure FS2 will support this someday, but right now all these Dualcore CPUs are fast enough for FS2_open with all features enabled anyway.
-
You can always make sure that FS2 is the only task running on one of the CPUs though :)
-
I just wanted to know, because this may really be something that may be undertaken one day....
muahahaha fso on a dual cpu pentium 3!!!
-
I kinda doubt that it will be supported any more than it is right now (some sound and input/output is multithreaded) since most of the game code just can't be made to be multithreaded safely without a ton of work, if it can be at all. Most of the big CPU hogs in the code will likely not be able to go multithreaded and speed gains from the smaller stuff probably won't be worth the effort.
Time is better spent on just optimizing the code more and making better use of high performance GPU features.
-
chaneing a large program from single threaded to multithreaded is slightly more involved than changeing a single hull oil tancker into a catamaran design. it's a bit harder than MULTITHREADED = true;
-
My X2 4400+ (at stock speeds its essentially a 3800+) in singlethreaded mode is more than sufficient to run FSO with all the CPU intensive features turned on. Multithreadedness (if thats even a word) is therefore not necessary at the moment. Sure it would be nice though......
-
Unless a program is designed from the ground up multithreaded, it's quite difficult to accomodate the structural changes required to make it that way.
And that's an understatement.
-
FSO doesn't seem to be very CPU dependant anyway, so I doubt there would be significant gains even if it was possible to make everything multithreaded.
-
I will admit I have consitered useing multi-threading for future effects, I think the when ever I implement shadows I may try a multi-threaded queue, every time a ship changes orientation enough it would get added to the queue and it's siloete would get recalculated.
-
That's was I was going to suggest next. Any new features that are added, should be made multi-threaded in the first place. Even if it doesnt seem to give much of a performance gain, it won't (i hope) effect the playability.
-
Multithreading is less efficient on systems that don't support it natively.
-
dammn, really? How much less efficent? would anybody really notice?
-
EG say you have two threads going, each reading from a different place in memory. The processor has to take the time to switch between tasks, including different memory or hard drive positions if the thread needs info from both. Kind of like trying to alternate between solving math problems and reading every 30 seconds or so, as opposed to just doing math and then doing the reading.
I imagine there are algorithms in place to try and switch at the most efficient spots possible, but it's just not going to be as efficient as solving tasks one by one in order.
With a dual core or CPU, the processor can assign a thread to each of the processors/cores and have them work on each separately. Using the earlier example, it's like if you had a twin who did the math while you did the reading.
-
Originally posted by Pilot Of The US
dammn, really? How much less efficent? would anybody really notice?
You say that like it would actually be possible/productive to put in to FS2. It isn't without a complete overhaul of, well, everything. And even then the benefit you'll get from it wouldn't be worth the extra overhead to most users.
-
Yeah, fs2_open is optimized for single-thread running. Meaning, in a lot of places pointers to memory locations are used instead of indexes. So, say ship 43 is destroyed by a piece of shrapnel; the memory with ship data is freed. But the rendering thread is still going with a pointer to the ship, and tries to access a piece of data about the ship, and crashes the program from an access violation error.
You'd probably have to go through all the major functions and either insert checks and such to make sure that things were finished by the other thread(s), and probably straight out rewrite a number of them.
-
you have that problem no matter how you access the memory
/me done lots of multithreading
-
AFAIK there are some consumer multiprocessor/dual core boards out there that have separate CPU cache for each processor.
But I might've just been having a really geeky wet dream. :p
-
Seperate CPU cache is really the practical difference between hyperthreading and multicore anyway. There are a few with integrated cache that have come out in the transitional phase, but the only way that it really makes sense to do it is to give each core its own cache.