[chief1983]

Wait what?  The problem isn't any sort of incompatibility, it's about taking advantage of them.  By it's nature it's probably only utilizing one core for just about everything it does while running, leaving the other one sitting idle.  It's a single threaded app, the thread attaches to one core and stays there.  So it's not that anything is broken, it's that it could allow the game to make better use of the now-commonly available resources.

[Stormkeeper]

Yea, it'll run fine on multicores, but it doesn't do multi threading, which is using different cores for different processes, for example, using one core to handle collision detection and another to render. This way, it reduces stress on your primary core, and allows programs to run smother. However, few programs have multi-threading.

[chief1983]

Yeah, basically all that it would make sense for is an app that is going to utilize every bit of cpu it can get for a long time.  So things like render farms, games, physics sims, etc.  Not your typical day to day computer stuff.  The only use they get is that the OS should be affiliating different programs with different cores, keeping the load balanced whenever you're doing a lot of things at once.

[Stormkeeper]

Or games with 25km X 25km maps with hundreds of units crawling around it trying to lay the smack down on the only two piloted walkers in the whole game.

[MikeRoz]

Mutexes involving atomic X86 instructions are ridiculously slow! Spin-locks are faster, but still too slow! Clearly the only answer is to split this engine into a half-dozen threads, and let God sort out the race conditions!

In all seriousness, I would be extremely surprised to find FS2 CPU-limited on anything but the fastest graphics cards. Srsly. If you want your multi-core CPU to give you more warmth while you play, encode videos at the same time or something.

[WMCoolmon]

I could see dividing the playing field up into zones where ships don't really act with each other and doing those threads simultaneously.

But then you would have the problem of ships crossing over zones, or AI responding to events in other zones (Which wouldn't be so bad, since AI doesn't have to respond instantaneously and it could be globally managed every five frames or so), or scripting/SEXPs that reference events in zones. The problem is that your ship handles could become invalidated in the middle of a SEXP or script, so even if you checked for it starting out (even in the code) there's no telling that the pointer will be good later without rewriting _everything_ to go through some sort of sync system conducted at the end of each frame.

Or something. Just pontificating for the hell of it here.

[foolfromhell]

FYI, I have a dual core (an Intel and an AMD) and I have never had any issues with running FSO with both cores.

I also just built an AMD Quad Core for a friend of mine who's running XP 64bit with 8gb of ram, and that machine is also running FSO just fine. We've even had plenty of lan multi-player games.

Dude... That isnt what we are talking about.

FSOpen only uses ONE core at a time. Some games like Supreme Commander, Oblivion (To an extent), WoW, and others can use both cores. For example, load half the game using one core and load the other half using the other core.

Makes the game a LOT more efficient, but a pain in the ass to recode the entire game. Hell, it's a pain in the ass to code the game from scratch to use multi-threading.

[FUBAR-BDHR]

The Pentium Pro had SMP support, but it was not dual core.  It was also their first pure 32bit (and i686, the Pentium/MMX was i586) cpu I believe, designed for the NT operating system.  SMP is much older than dual core, and there were SMP systems in consumer hands around that time, because the Celeron was found to be capable of being run in SMP configurations, with a little motherboard hackery.  The Abit BP6 was famous because of this, it enabled power gamers to buy two Celerons for less than one Pentium 3 and get better performance.  So, while dual core was barely a dream to a few scientists, SMP was definitely around, and being taken into consideration by many programmers.  But it's difficult to take advantage of all those cores, threading an application properly takes a lot of work, and needs to be planned from the start more than likely.

[off topic]
I was going by a Novell support article.  The Pentium D uses the same multi processing system as the Pentium Pro did so Netware 6 will run on it but will not run on a Core2.  Never ran windows on a Pentium Pro.  [/off topic]

Still none of this really answers the question of why some people have trouble running on a system with multiple cores until they manually set affinity to one core and others don't. 

[chief1983]

Ah I'd forgotten about that issue.  Yeah I don't have a clue there.

[Zacam]

I know for AMD procs there is a multi-core optimizer that essentially load-balances the activities that would normally max out 1 core to split across 2, 3 or 4. While I get the logistics of the benefits to multi-threading FSO, care has to be given to the fact of scalability. Some single-cores can multi-thread but not as well as multi-cores, and if the two are not conditioned properly, you will loose out on any one that hasn't yet obtained the hardware. There still has to be "Retail" compatibility for FSPort for those who cannot run FSO with or without HT&L capabilities, are we to cast them out? And just because something is present to take advantage of, doesn't necessarily mean that it is the best idea to do so. If the issue is not with compatability, then it obviously is not broken, and there are a lot more features than just this coming down the line. At some point, they will inevitably merge.

While it does frustrate me to no end the amount of concessions against progress for sake of compatibility, it has to be even more frustrating to the coders. They want to create and share, and no one should be left behind. That makes for hard decisions and often recriminations when it doesn't go well. So tot that end, I trust the coders to do what they will do, because I know they will do it to the best that they can with an eye towards seeing that as many people as possible can share in it.

[karajorma]

The issue isn't compatibility. The issue (as we've told you several times) is that you have to re-write the entire engine for it to work. Let me give an example of an everyday event run as a single thread and then as a multi-threaded one.

Suppose you want to go to the shops and buy a pint of milk. You walk to the shop. You see the shop is open. The shopkeeper is a little annoyed cause he was about to close. You walk in the shop. You see if there is any milk. There's one carton left. You pick up the milk just before someone else does. They look a little annoyed when they see there is no milk. You pay for the milk. You walk home. Simple. Now let's try multi-threaded.

First you walk to the shop. You go to walk in the shop. You check if the shop is open. It is. Meanwhile in another thread the shopkeeper checks if there is anyone in the store. There is no one in the store. The shopkeeper starts closing the store. You walk in. In the first thread you are now in the store. The shopkeeper at the same time is closing the store. You look for milk. While you entered the store another person also turned up running in a different thread. They also want milk. Both of you check if there is milk. Both of you see one carton of milk left. You both pick it up. You get there first. You laugh as the guy walks past you, calls the shopkeeper over and tries to pay for a carton of milk he doesn't have. You stop laughing when the storekeeper throws a fit as can't get the scanner to read the non-existent bar code and refuses to serve you until he's dealt with the other customer. So you all stand in the shop with the lights off and the doors closed forever.


There are ways to prevent what happened in that example from happening of course. You say that certain tasks can only be performed by one person at a time. But the point is that FS2 doesn't do those checks at the moment. Since only one thread ran at a time checking if the store was open was enough. The shopkeeper wouldn't be checking if it was time to close at the same time, the game would handle you seeing the shop is open, walking into the shop and then have the shopkeeper do his check.

But FS2 doesn't do those checks. It never needed to do them. And the number and complexity required to do them all means that we might as well re-make the entire game. As you can also probably see if we forget a single check there is a chance of locking up the game under certain conditions. That might happen often or only on very rare (and therefore hard to fix) occasions. Furthermore as you may have realised doing all the extra checking takes time. Multi-threading isn't always automatically good. All the checking can take so long that the resulting program is actually slower than the single-threaded task.

It is possible that there may be tasks in the game sufficiently distanced from everything else that we can shunt them into another thread. But the majority of the engine can't be.

[griffon67]

normally your computer uses the 2 core (or 4) when launching FSO. and it uses the 2 cores ,but not the same way as multi threaded program do (see post above for why).
the truth is, put your game at maximum details, run it normally you'll have a certain amount of FPS (let's say 50), then use the task manager to set affinity to one core only, in most of the cases you'll see your FPS dropping (almost divided by 2, 30-40 for me). So, unless core affinity does slow the game, I guess the OS manage the 2 core to use them adequately with single core application. That means, no need to develop a multi core support for FSO since it wouldn't benefit the game at all.
many old games runs with the same system (that's why I guess it's OS related, or even hardware related)

[meego]

Remember FreeSpace2 worked fine with a Pentium 200. I don't know much about the inner workings of FS:SCP, but my guess is the CPU-dependent part (AI, physics, scripts) mustn't have grown much from the original code in terms of processing requirements. Even if it grew by a x2 factor, which would be a lot, most single cores being at least 1Ghz, we'd still be in the clear by far.

Correct me if I'm wrong but it really seems multithreading would serve no purpose at this point.

[griffon67]

when I look rom average distance 3-4 capital HTL ships I have 20-30 FPS while when I'm looking at nothing I have 60FPS,
if my computer was that powerfull for this game, wouldn't there be no loss of FPS ?

(maybe I'm wrong, I'm not omnipotent)

[jr2]

Most of that depends on your Graphics card.  Go buy the latest graphics card and try that again... 

[griffon67]

with a geforce 8600GS I have more power than with the graphics cards I had when freespace 2 was released.....

[colecampbell666]

most single cores being at least 2.5 Ghz

Fixed. And single cores aren't produced anymore.

with a geforce 8600GS I have more power than with the graphics cards I had when freespace 2 was released.....

Not to be rude, but no ****. That is a monster compared to a TNT2 (my first). (look at this chart)

[meego]

Fixed. And single cores aren't produced anymore.

Weren't some dual-core low freq Celeron produced?

[googling] Yep. http://en.wikipedia.org/wiki/Intel_Celeron#Celeron_Dual-Core_.28Core.29

Anyway, 1.6Ghz sounds enough.

[colecampbell666]

Those are dual cores. Single-cores now (or a short while ago) were all more that 2 Ghz. A lot of older duals (especially for laptops) are less that 2, or even less than 1.

[meego]

Ok. I think we agree on the resulting point that every multicore CPU ever released can run FS:SCP just fine, even with only one active core, hence the lack of need for multithreading.

Edit: btw what dual-core cpus are <1Ghz? I can't seem to remember of seeing one.