Setting up a community dedicated-monster-of-a-server

Actually multi-threading would help scalability a loooot.. Just look at Supcom, it's NOT multi-threaded; because of this the game can STILL come to a stand still... seven years after it released.

Edit: Accidentally forgot to put a not there! XD

Of course it'd help. I don't think anyone is debating that. I'm certainly not.
What I said is it's a hell of a lot of risky work for a problem that might largely go away with the inevitable increase in computing performance.

Funny you should use SupCom, I've seen nothing to suggest it's any more multi-threaded than PA, it's still highly dependant on single-core performance. If it is it'd be a major feat given the sim is deterministic.

Oh and guess what, SupCom ran awfully on release, but as hardware improved...

tut tut tut tut tut!
nonsense.


currently this makes all the difference in the world. It's an investment that'll last forever and currently sets the game apart from "unsellable", "unusable".

I know I'm stretching it to extremes but there's a good reason I'd rather be playing FAF right now: one of the two lags less.

And I came here in the first place in a attempt to escape lag! .....jokes on me

That's... What? That's what I said!

Oh wait, no it's not... Whoops I meant to say it WASN'T multi-threaded. The example was to say that Supcom can still go to a stand still today because it wasn't multi-threaded.

Sorry about that, I know Supcom ran terribly when it released, totally agree, just forgot to put a not there... Whoops.

At least PA lag doesn't result in to a virtual lynching of whichever player is deemed to be at fault. We can all hate on Uber together.

Oh. That's...wow

I wonder about that. I can see that rewriting the whole thing to perfectly scale with 100+ cores is not payable. But I've seen a LOT of people complain about sim performance and it's probably one of the main reasons why I've never really played more than 1vs1 in PA, with a few exceptions ofc. I didn't play teamgames in FA very much as well, but I did play them there. Not in PA. Late game orbital fights at 30% sim speed are just no fun at all.
There are definitely a bunch of "simple" multithreading optimizations, like one sim thread per planet, that can be done for PA. Waiting for hardware to catch up is also a rather questionable issue. Future hardware will not be that much faster per core, future hardware will just have more cores.

Will the cost of the significant development time to implement and test this actually result in an increased number of sales to offset that cost and then make a profit? That's not a clear-cut answer, so while it would be awesome to do it, it's not nonsense to claim that there isn't a business case for it, especially since we aren't in a position to gauge just how much work is involved. Multi-threading a sim thread is not a trivial task.

Actually, thanks to libraries like OpenMP, even dynamic parallelization of inline loops is actually quite simple with significant gains. That "offloading workload to other threads manually" as it was done in the client works as well, of course, but any type of "manual" threading means that you have to make significant changes to the underlying architecture. Processing planets in parallel is a good example, plus it won't scale as well as you would expect.

But... but surely you just tell it to do the thing somewhere else? I mean how hard could that possibly be?

/s

I wonder

Multi-threading for anything but the small subset of problems that it naturally fits is probably the biggest problem in computer science right now. If it was as simple as splitting this or that or implementing a library we wouldn't be having this conversation.

http://bisqwit.iki.fi/story/howto/openmp/
IMHO good overview on OpemMP.

It's not exactly the C++14 approach to parallelism, but it works quite well as it allows you to annotate critical sections, shared and local variables in existing code with simple pragmas. Yes, it's still prone to errors and all mistakes related to multithreading, but at least it's much simpler and better suited for parallelization of short segments than with any other approach I know of.

There is a very effective Mt version of the spring engine that delivers in some cases a 5x performance boost in large games. This is on one map too... To be clear it can and has been done.

As for financial incentive... Making the core engine as scalable as possible has to be a good idea if uber intend to use it 'as a platform' moving forward. HR was trying to do just that, so had that succeeded that would probably have justified the cost then and there. Hopefully future games on the pa engine are still possible...

Hmm? Do you think that single threading is the best fit for the larger subset of problems? Nope, by far the larger subset of problems are best solved by multi-threaded solutions. I can't actually remember ever writing a single threaded application or driver other then "Hello World". If you tried applying a single threaded approach to the vast majority of problems, you'd end up with inefficient software which would fall far short of requirements or performance expectations. In many cases, you simply could not implement a solution without using threads.

IBM provided multi-threading support back in the late 60's. It's been an integral and essential part of software development for nigh on 50 years.

Avoiding multi-threading "because it's hard" is not a valid reason to do so. That's why you design and get your concurrency model right before you start writing code. IMO this conversation is happening due to Uber's design decision which I am at a complete loss to understand. However, I can say with a fair degree of certainty that modifying the existing application to be multi-threaded will be a non-trivial exercise.

Maybe a developer can chime in and talk about this? The problem that the server is not properly multithreaded basically stands against this game's whole premise of huge armies and ton of players.
I can understand that there is a ton of technical problems involved, but shouldn't the engine have been developed with this in mind from day one on?

@jables Could you get us some information on this?

well worded.

How about one thread per planet and a threadpool for interplanetary space? Since the planetary and the interplanetary space is rather neatly separated (sim-wise) that should require little synchronisation, thus little programmatical effort. Little in monster-quotes, that is.
But it would seem to me an obvious venue for parallelisation, and might be just delicious for servers with a high core count.
Mind you, this is all from a very naive point of view, but I still find the lack of interplanetary interaction to a boon in this context, and one to be exploited at that.

Supcom is peer to peer. Meaning that all machine must have the same sim no matters what. I can understand that multithreading that is hard (but it was done in Spring and some other engines prototypes).

One common way to do it is close to what I'm doing regularly with render engine : You split the sim in several blocks (like a checker), and send every block to a thread. If a block is affected by a concurrent block, you compute that extra unit/projectile. That means that the non-constant parts of the sim will need to lie twice in memory (the frozen initial state for each entity -so if needed the extra unit can be computed the exact same way-, and the computed result done in each thread), but it's not really a huge drawback these days. Also it's really the variables (a few vectors and floats for position/orientation/health) and not all the sim (unit stats,...).
And with some smart use of caches/out-of-core techniques, I doubt it would be an issue at all.

Also, as the PA client/server architecture means that you don't have to bother having the same result every single time, as long as it's "close enough". (so the execution order of the threads, doesn't matter at all).
Meaning that if you take the same units, the same orders, the final outcome doesn't matter as the server is the only one that need to know it.

If PA engine was able to do multithread per planet, doing multithread per area of planets is not a lot more difficult (I'm not saying it's easy to do in the first place).
But as it's not designed to do it in the first place, it's unlikely that will change in the future (as said before, changing the whole code to do it now... Probably faster to start from scratch). PA as a platform for future large-scale RTS is already quite dead.

Your whole post just explained how PA's base architecture is designed for it in the first place