Wow, didn't this thread die back in September? I guess I have no choice but to respond.
Wow, he just wasted about an hour of his life. Why in the world would you use all that power to run 1 game? That's stupid, especially when the game itself is already running at full speed? I thought the purpose of having "multicores" was to "multitask" better, right?
Besides, the less processing power a program requires, the more that is available to other programs, which means MORE multitasking 
MikeRoz, please read up on what multiple cores are all about, otherwise shut up! If you want to run FS2 with the most processing power, then buy a single core processor and overclock it like crazy, around the 5GHz mark; then run FS2 on it. Otherwise, the guys here are doing an amazing job on this project and I couldn't be more proud of them 
P.S: I know that the developers here are gonna come out with something that's gonna make FS2 even better, so I'm gonna have to increase my capacity for happiness ;D
Yeah but that's the point. Intel's latest chip offers eight logical cores, and
future chips are sure to offer
even more performance. Unless you participate in
Origami folding competitions, that extra power is just going to be sitting there, wasted. Yet we all know a simulation like FS2 needs all the processing power it can get, and that can easily be split off into multiple cores.
Just look at all the things going on in FS2. I mean, it's a feat that Volition was able to make it run on the computers of 1998 and 1999. Let's just start with a single fighter going flying through an "empty" map. You've got all the systems of the fighter that have to be simulated: weapons, propulsion, life support, shields, sensors, communications, etc. Though they all have to work together to some extent, their tasks are largely independent, making them the perfect candidates to be split off into threads.
And then there's the supposedly empty map. Should be easy to simulate, right? Wrong!
Even outer space isn't a perfect vacuum. There are several hydrogen atoms
per centimeter. This is zillions of atoms, flying every which way, interacting with each other, bouncing off your ship, at every given moment. Some day we may be able to assign a thread to each so that their processing is not all crammed into one line of execution, but we may not quite be there yet. In the meantime, there is still plenty the team can do with multiple cores. Like explaining where the Shivans came from.
Wow. Just wow. Well, just about the whole post is devoid of reasonable technical merit and accuracy.
The need to multithread new applications is undeniable, but the ability to cram new threads into an existing codebase and not screw the pooch is not something that is reasonable. To do a good multi-threaded game engine requires the choices to be made up front so the data structures can be organized in a fashion that doesn't require exotic constructs like virtual software IOMMUs. Proper data structure design is far more important than the code itself since almost all the less than linear increase per added core performance is due to data contention.
Alright, so I admit I was a bit hasty by introducing my whole start-n-threads-of-FS2-by-starting-execution-of-thread-x-at-position-x/n-in-the-code idea. I actually tried this by defining a bunch of function pointers to point to the desired areas of the code, and then spawning a pthread with each function pointer. To even my surprise, the game ran the first time. It even ran slightly faster. To my horror, instead of blowing up Capella in my playthrough of the retail campaign, the Shivan AI suddenly became transfixed by one random point in space and began to congregate all their ships there. And by all, I mean
all. The area soon collapsed into a supermassive black hole into which all the surrounding systems were sucked. It took forever, less due to performance issues and more due to relativistic effects.
Needless to say, there is a small but crippling concurency bug in the AI that prevents this method of multithreading that I have no interest in fixing. There's no time, not if we want to beat the
GL-117 team's next-generation effort to market. But don't worry, I've got a great idea they'll never see coming. You see, they only plan to take advantage of the processing power one machine has to offer. Which would be fine, if this were 1997. You see, however, multithreadedness is in the future, and
distributed computing is on the horizon. If we get there first, the world, as they say, will be ours.
My friends, I give you FSOS. That's FreeSpaceOperatingSystem. With hardware IOMMUs (not the clumsy software things you brought up earlier, Enki) even closer to becoming mainstream, virtualizing an OS is starting to carry less and less of a penalty. If we make FreeSpace into an OS, we can harness this advantage!
To explain, an
IOMMU is a device that arbitrates memory and peripherals so that each of any multiple OSes on a computer thinks it has complete and direct control of the hardware, at no performance penalty. In the future, we may harness this to run multiple copies of FSOS at the same time, all with little to no performance penalty, but we should first focus on getting one copy of FSOS stable working on multiple cores.
"But no!" enki is fuming, "You still haven't solved the problem of data contention!"
Did you really think I'd type all this without figuring out a solution to that too? The answer is simple. We reverse-engineer and use
GoogleFS. To a CPU, the hard disk is slow, and even its RAM is slow. But the Internet is fast! Just look at how fast Google's servers get results to your computer. This is because they use a file system that is designed from the ground up for redundancy, distributibility, and to be used concurrently by thousands of clients.
Of course, this will have the unfortunate side effect of requiring that the first few FSOS users have a cluster of GoogleFS machines attached to a local network to act as their filesystem. The good news is that subsequent users can use this space as quickly as though it were part of the cache on their CPU.
yup, FS2 on one core leaves the other 3 free for music or torrents or rendering or whatever else i feel like doing :-P
That is the beauty of FSOS
Once we reach critical mass (I define that here as one thread per every four hydrogen atoms in free space), you will have access to a game world so vast and dynamic, that you can take care of all your game needs inside the virtual world. Since it's the computers of the future that we're simulating here, any task you undertake on a simulated computer in FSOS would complete in a fraction of the time it would take to complete on your silly 21st century machine.
To summarize:
1. FreeSpace as a simulation is highly constricted by CPU power and lack of parallelism; just look at all the underlying details abstracted away.
2. Simulating the game world on a more fundamental level will lead to more interesting stories.
3. Since AMD
utterly failed at it, we are stuck having to implement reverse-hyperthreading, and as a software library at that.
4. GPUs can be used to simulate drawing implements in the virutal world, since they're so good at rendering things.
5. I would love to see how sound fares in the engine when we transition to this more realistic model.
