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

Well, the gameplay concept. But the engine does not take advantage of it so that leaves us with a wasted opportunity right there.
Not saying this can not remedied, I actually am of the opinion that it should be almost trivial.

I would not say using a client-server architecture is about a "gameplay concept". It's a technical decision that is the basis to have a potential to multithread in an "easier" way.

Yes, that's why I'm very surprised it's not the case. They have the idea of building a plane, but they built a car with wings instead.

Touché, let that one slip by... Still, only goes to show how maddening the absence of some proper multithreading architecture really is. All the pieces are in place - yet we have all those isolated pieces of the sim having to run all on the same one thread...

Well it certainly is the best starting condition to build a plane if you already have a car with wings
The only question is about time and money and that's a question we can only make rather wild speculations about.

are .....are you telling me implementing more multithreading now is fucked??

No. More like "it is hard work indeed, but the engine architects at Uber DID think of this many years ago already and PA is in the best possible situation to rewrite the sim in a multithreading fashion". It's still "not easy", but i.e. multithreading SupCom's sim would be much harder.

ok.

Dammit this conversation has reached a dead end. @jables help!

oh and please answer with a magic conch meme. It soothes our kittens and lemmings.

here's one as a sample:

To be clear pa already has quite a bit of multi threading in it, just not for the SIM itself. It isn't fair to say it has none though as currently we have:

Render- circa 3 threads
ui- loads of light threads (in practice 1 or 2 cores required in total)
SIM and path finding (?)- 1 thread
Client network and other stuff- 1 per connected client (?).

So that is 7 + n (where n is number of connected clients when running server), if playing offline or lan or hosting server and playing on the same machine.

That said, it's the SIM that is now the bottleneck, so applying additional threading (eg give path finding its own thread) is where we could see some big gains in server pref....

I've seen the server alone use more than 800% cpu in a 30 or so player game.
There is a lot multithreading. The sim is basically the exception.

Unfortunately the sim is the most critical part of the entire game performance wise...

I'll look into it. Don't have a good answer as of yet though.

Actually I am sure we would just be as "unhappy" if we had a perfect scaling sim, but a completely single threaded client that runs at 5 fps, no matter what hardware you throw at it We basically had such a client in alpha.
It's a thing of perception. Ofcourse the one thing that isn't there yet is the one thing that is MOST important.

Point is, for the time being Colas approach of assessing how to get the best performance out of the sim as it is right now, is the right one.

No point holding your breath waiting for Uber to ride in on a multi-threaded unicorn to save the day.

About the one sim per planet suggestions, while helpful, would only shift the problem, not solve it. Events on different planets still depend on each other (one game time) and thus thousands of units on one planet overloading that sim thread will slow the game down no matter how many other sim threads aren't fully loaded. Dividing the planet area would more or less solve this but then again, invading a single spot with thousands of orbital units (which overlap) would result in the same problem. What we need is a fundamental change in the sim core, which should have been implemented from the beginning (but what do I know maybe it has been, but is inactive, lets hope). But I welcome every possible improvement as large scale games are unplayable in late game right now.

It's a real shame, because with all the talk about lessons learned on SupCom, which was one of the main reasons I bought this game, it really seems like we have the same problem today (yeah server-client solved on part of the problem).

And:

Indeed .

That sounds so final. Just like people worried "we will never see offline play" or "we will never see a ladder" or whatever else.

Well, I was going for the "so final" effect . More seriously, a ladder is in some sense trivial to implement in comparison to multi-threading (MT) the sim, and offline play was in principle already implemented and functional when the game first released in alpha, it was just a repackaging for us mere mortals. MT the sim is so entirely different that I am happy if we get the one sim per planet and maybe per area on each planet as explained above. Can't really hope for more at this time, just too goddamn much work...

"Per area" on each planet would actually already solve pretty much everything. Yes you would still have some rare occasions of lag in extreme situations, but there are always "rare" occasions that just nobody notices, because they are rare. Reading into the ideas of "damn this software works so well, it's like magic" usually reveals that it just has been written to work well in the normal scenarios you are encountering and would die if you do "unusual" stuff.
I can't really imagine how "per area" would exactly work though. Managing what unit is in what area would be a pain and managing units pass from one area to another or walk on the border of 2 areas would be even a bigger pain.

There is also that "keep a copy of the data from the last step of the sim and let n threads in parallel update all entities based on this static copy and write the results somewhere else" thing. I've actually spent quite some time wondering where the issues with that concept may be, since it is not exactly ubiquitous so far and there has to be a reason for that. All I came up with is "that actually fits nice with how they somehow have to generate curves from the changes in the worldstate anyway". Just not sure about memory usage, but then again: Memory is cheap. Single thread performance is not.

It's possible for sure and you actually don't need to perfectly scale with some extreme scenarios that one can construct. If 99% of a big game runs at 100% sim speed and the last 1% at 10% you'll still have quite happy players, especially since the 1% stuff won't happen in most games.

The engine already knows about it. You can simplify it and assume everything is a perfect sphere, and it's just a two basic math operations involving sinus and cosinus.
But it's already probably done for pathing one way or another.

You don't have to. You compute the unit depending on his current position, if it goes on another location, it will be computed in another thread next tick.

If it walk on the border, it's easier on one side or another. Not a problem either.

But I'm just trying to get an idea of how it could be done, and I have a pretty fair idea of how it could work. But I know nothing about their pathing system,.... that may be completely imcompatible with this method. Also, it's just an idea, it's always easy, but if I had to do it, I would probably hit some wall (hopefully most of them would be breakable).

For exemple, I'm writing currently an algo that must compare a serie of position to see if there is another stuff in the area of these positions.
I'm building an octree for that, but as I'm camparing 10 millions of positions against 10 millions of stuff, it was really slow even with a near perfect parralelism (100% CPU occupation, about 20 min with a bi high end xeon). Moving the stuff to CUDA resolve this in 30 seconds on a 980GTX. And I can double that, still 30 seconds
I will hit some memory issue at some point, but I have a pretty good out-of-core method to solve it.

For another part, I've changed the multithreading about 6 times before getting it right (100% CPU, no crashes). But it was easy as it was in prototyping stage. Doing that on a fully done engine, I wouldn't even try it...

Most people think multithreading is the hardest thing to do, it's not easy, but really not the hardest either. Video game programmers are fairly new to the world of multithreading, that's probably why they are coping with basic problems.
The most important thing is to make a layout/prototype of the multithreading solution (they are so many way of doing it), and once proved good with simple problems that fit your program, build the engine around it. Not the other way around.

Again, I have a personal experience with that : I wrote a single threaded program, well, it's still single threaded : I fail to multithread it correctly.
But weirdly enough, I wrote a very similar program, but that one was written with multithreading in mind, and I had zero problem writing it..
It's possible to rewrite the first one to fit the layout of the second, but I would need to rewrite basically everything.