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

Discussion in 'Planetary Annihilation General Discussion' started by cola_colin, October 10, 2014.

  1. squishypon3

    squishypon3 Post Master General

    Messages:
    7,971
    Likes Received:
    4,357
    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
    Last edited: October 22, 2014
  2. ooshr32

    ooshr32 Active Member

    Messages:
    749
    Likes Received:
    141
    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...
    squishypon3 likes this.
  3. tatsujb

    tatsujb Post Master General

    Messages:
    12,902
    Likes Received:
    5,385
    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
    ace63 likes this.
  4. squishypon3

    squishypon3 Post Master General

    Messages:
    7,971
    Likes Received:
    4,357
    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.
    ooshr32 likes this.
  5. ooshr32

    ooshr32 Active Member

    Messages:
    749
    Likes Received:
    141
    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. ;)
  6. stonberg

    stonberg Member

    Messages:
    81
    Likes Received:
    29
    Oh. That's...wow o_O
  7. cola_colin

    cola_colin Moderator Alumni

    Messages:
    12,074
    Likes Received:
    16,221
    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.
    dom314, tatsujb and trialq like this.
  8. Raevn

    Raevn Moderator Alumni

    Messages:
    4,226
    Likes Received:
    4,324
    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.
    Bsport, carn1x, ooshr32 and 1 other person like this.
  9. exterminans

    exterminans Post Master General

    Messages:
    1,881
    Likes Received:
    986
    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.
  10. cwarner7264

    cwarner7264 Moderator Alumni

    Messages:
    4,460
    Likes Received:
    5,390
    But... but surely you just tell it to do the thing somewhere else? I mean how hard could that possibly be?

    /s
    Last edited: October 22, 2014
    Raevn likes this.
  11. cola_colin

    cola_colin Moderator Alumni

    Messages:
    12,074
    Likes Received:
    16,221
    I wonder
  12. ooshr32

    ooshr32 Active Member

    Messages:
    749
    Likes Received:
    141
    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 o_O we wouldn't be having this conversation.
  13. exterminans

    exterminans Post Master General

    Messages:
    1,881
    Likes Received:
    986
    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.
  14. cdrkf

    cdrkf Post Master General

    Messages:
    5,721
    Likes Received:
    4,793
    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...
    tatsujb and ace63 like this.
  15. stonberg

    stonberg Member

    Messages:
    81
    Likes Received:
    29
    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.
    zilverink, ooshr32, vyolin and 2 others like this.
  16. ace63

    ace63 Post Master General

    Messages:
    1,067
    Likes Received:
    826
    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?
    zilverink, vyolin and tatsujb like this.
  17. tatsujb

    tatsujb Post Master General

    Messages:
    12,902
    Likes Received:
    5,385
    well worded.
  18. vyolin

    vyolin Well-Known Member

    Messages:
    631
    Likes Received:
    479
    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.
  19. thepilot

    thepilot Well-Known Member

    Messages:
    744
    Likes Received:
    347
    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.
    Last edited: October 22, 2014
    zilverink and tatsujb like this.
  20. cola_colin

    cola_colin Moderator Alumni

    Messages:
    12,074
    Likes Received:
    16,221
    Your whole post just explained how PA's base architecture is designed for it in the first place :p

Share This Page