Skip to content

Request: Multithreading support. Can't believe so few mentioned it yet.

2»

Comments

  • SherincallSherincall Member Posts: 387
    You cannot split the graphics rendering to different threads in any meaningful way. Performance increases on that end happen when you reorganize your rendering to give the GPU useful things to do while you're preparing the next batch.

    NWN graphics do a lot of things the wrong way, so your GPU is sitting idle most of the time while the CPU sends work to it in tiniest little pieces. Then when the CPU is done, the GPU processes them all. There have been significant improvements in this regard with EE, but it still has a long way to go to catch up with the best practices.

    *Edit* for example, C++ did not get standard support for concurrency/parallelism until 2011, a full year after the article, and parallel algorithms were added only a month or two ago when the new standard was published.

    I don't understand what this is suggesting, but whether concurrency is part of the language standard is irrelevant for most cases. It's not like you couldn't do the same thing previously, all they standardized was the name, and added a few OS specific abstractions. Anyone actually caring about performance wouldn't use this anyway, and would just use the native OS service directly.
    Dark_Ansemvoidofopinion
  • voidofopinionvoidofopinion Member, Moderator Posts: 1,248
    @Sherincall

    What about NW Server?

    That's the only thing I have ever thought could benefit from being able to use more threads and more cores to better support larger worlds with larger player counts with any appreciable benefit... But I will freely admit I am making an assumption in that regard.

    Any light shed upon that subject would be greatly appreciated.

    :)
    dTd
  • FreshLemonBunFreshLemonBun Member Posts: 909
    I'm not a programmer and don't know all the details but it probably depends mostly on these rules.

    https://en.wikipedia.org/wiki/Amdahl's_law
    https://en.wikipedia.org/wiki/Gustafson's_law

    A problem has to be comprised of independent steps or it must be possible to structure a problem as independent parts. That is to achieve any benefit they don't depend on any other steps. Forget 1+10*5 for a moment, counting numbers 1 to 10 in parallel would be 1+2, ..., 9+10 as 5 independent steps. Do you have something you think meets that criteria? Possibly only things like pathfinding I imagine.

    An example is running scripts on different threads I imagine could make scripting asynchronous which introduces race conditions and creates new threads on the forum asking why scripts aren't working properly.

    https://en.wikipedia.org/wiki/Race_condition

    I'm not a programmer so I don't know all the specifics of the technology or what new C standards do or don't allow or any of that stuff, but my intuition tells me that few game things can be structured as independent parts.

    On the other hand you can probably run multiple servers on different threads, each handling it's own work load with some cross-server communication through databases and NWNX. That would probably use the gustafson one, I'm not entirely sure, but it seems you would increase the overall workload (larger world = multiple connected worlds) so total speed of processed data increases.

    Correct me if I'm wrong.
    voidofopinionPlok
  • Taro94Taro94 Member Posts: 125
    edited January 2018
    Why is it impossible for scripts to run in parallel?
    Correct me if I'm wrong, but couldn't heartbeat scripts be concurrent? They can't be synchronized with events in any meaningful way, I think, so moving their execution to another core could grant some net benefit, no?

    Edit: Ok, nevermind. You'd need some mutexes or monitors not to break anything. Seems like a bad idea overall.
    Post edited by Taro94 on
  • SherincallSherincall Member Posts: 387
    There's a few things which can be parallel, but the benefits are questionable and getting there isn't trivial. On the server-side, there's more room for improvement that the client, but you're probably much better off just running multiple servers like @FreshLemonBun says. We're even planning a feature in NWNX that will let players communicate across servers seamlessly.

    If you really wanted to parallelise a single server instance as much as possible, I'd guess you'd fork off pathfinding and AI update to multiple threads. Which isn't really as simple, as AI update triggers a lot of events, both in NWScript and in the server core. So instead of directly running whichever event you trigger, you'd have to push them to a queue, and then the main thread processes them in order.

    I can't imagine what the perf benefit here is, but a wild guess would be around 20%. Overall, really doesn't seem worth it - if you're running a huge PW that is hitting limits, you're probably better off spinning another nwserver instance.

    Oh, and by the way, do test the EE server first before complaining about perf; it improved compared to 1.69
    voidofopinionthirdmouseProont
  • FreshLemonBunFreshLemonBun Member Posts: 909
    Here's the thing...

    So would it be possible that you have a single stand alone server program which you can launch, just like now. Only with the exception that instead of having one option to select a module instead you have multiple, so the stand alone server can host multiple module files together. A single module selected twice would be two instances of the same module. Every module could use it's own process or a specific core or whatever the details would look like. Then the stand alone server program synchronizes all of the concurrent modules in various ways like fusing player list, system messages, long range chat options like /tell and /dm, and also post the total player count as a single server to the server list. Each would have to maintain it's own local variables but maybe could share some form of global variables too. When your character moves from one server to another there is no noticeable difference, your chat log remains as it was in the other modules, and your applied effects and other temporary data all carries over.

    I think that might be a beneficial change to the server side that could be moved to the core program instead of relying on NWNX and advanced knowledge to sync things up. Since it would essentially be an invisible change to players it would seem like the server functionality has improved.
  • LiarethLiareth Member Posts: 74
    For most use cases, there's little benefit in multi-threading anything on NWN. On the client, anything that could be multi-threaded lies within the game update logic, which doesn't run in any meaningful way in multiplayer and accounts for only a small portion of time spent per frame in singleplayer. On the server, we've made significant performance optimisations that means the server runs smoothly and acceptably even under heavy player load. Sure, some things could be parallelised - path finding and area updates are two big ones - but if the server already runs well enough, what's the point in spending time working on that instead of features that everyone can enjoy?
    Proontricoyung
  • ShadowMShadowM Member Posts: 573
    Liareth said:

    For most use cases, there's little benefit in multi-threading anything on NWN. On the client, anything that could be multi-threaded lies within the game update logic, which doesn't run in any meaningful way in multiplayer and accounts for only a small portion of time spent per frame in singleplayer. On the server, we've made significant performance optimisations that means the server runs smoothly and acceptably even under heavy player load. Sure, some things could be parallelised - path finding and area updates are two big ones - but if the server already runs well enough, what's the point in spending time working on that instead of features that everyone can enjoy?

    Sorry if this seem kinda hijack, but what is being done to improve the path finding? Is there some optimization on server side coming? Would it be better if client took over pc path finding and let server handle NPC path finding? Like Treant said it pretty ugly still with the path finding, so some more improvements would be nice.
  • Dark_AnsemDark_Ansem Member Posts: 992
    We are getting 64 bit exe. I am assuming this means actual MT and improved PF
    Proont
  • GreenWarlockGreenWarlock Member Posts: 1,354
    64-bit is almost entirely unrelated to MT, and the programming efforts would be completely distinct. MT is a MUCH harder problem to solve than the size of a few numbers and pointers.

    The only way 64-bit would improve path finding is to allow consumption of vastly more resources using the same current algorithms, more a minimal improvement at a large time-to-compute expense. I doubt that will be happening either - you improve path finding with better algorithms, not by requiring >4Gb data space to perform each PF computation.

    In short, I believe your assumptions are in error, and hope you do not use bad assumptions to later claim Beamdog let you down. It would be fair to say, even now, that they are not prioritizing your own concerns though. I don't think any assumptions are required for that.
    Sylvus_Moonbow
  • Dark_AnsemDark_Ansem Member Posts: 992

    64-bit is almost entirely unrelated to MT, and the programming efforts would be completely distinct. MT is a MUCH harder problem to solve than the size of a few numbers and pointers.

    The only way 64-bit would improve path finding is to allow consumption of vastly more resources using the same current algorithms, more a minimal improvement at a large time-to-compute expense. I doubt that will be happening either - you improve path finding with better algorithms, not by requiring >4Gb data space to perform each PF computation.

    In short, I believe your assumptions are in error, and hope you do not use bad assumptions to later claim Beamdog let you down. It would be fair to say, even now, that they are not prioritizing your own concerns though. I don't think any assumptions are required for that.

    All fine and OK until that last sentence that pretty much allowed you to make an arse out of yourself. Did I ever claim that they are prioritizing my concerns?
    GreenWarlock
  • GreenWarlockGreenWarlock Member Posts: 1,354
    Sorry, and I agree with you about the last sentence. Couldn't quite find the words to say what I intended, as was too tired to realize I should not post when the words aren''t coming - as the usual result is to say something offensive that was not intended. Sorry again, and thanks for seeing through to the rest of the post regardless!
    DerpCity
  • Dark_AnsemDark_Ansem Member Posts: 992

    Sorry, and I agree with you about the last sentence. Couldn't quite find the words to say what I intended, as was too tired to realize I should not post when the words aren''t coming - as the usual result is to say something offensive that was not intended. Sorry again, and thanks for seeing through to the rest of the post regardless!

    I still think that my priorities are quite nice tho.
    GreenWarlock
  • GreenWarlockGreenWarlock Member Posts: 1,354
    Fair enough, and I half-agree ;)

    I believe adding threading support to a game engine as old and complex as the infinity engine would be an incredibly expensive undertaking, and lead to years of hard to reproduce bug reports, and generally a lower quality game experience - just my own experiences trying to add concurrency to systems not design for it up front, over many years. I don't think BG is suffering bottlenecks to performance that merit that risk at this point.

    Improved path finding is always a good goal though, and I cede that some localized parallelism (rather than full MT support) could be very helpful here.
  • Dark_AnsemDark_Ansem Member Posts: 992
    Isn't NWN Aurora, rather than Infinity?
    Proont
  • GreenWarlockGreenWarlock Member Posts: 1,354
    Oops, and I just noticed that this popped up in what I thought was a BG forum, rather than NWN, so the engine may not be as crusty as I thought for adding MT, and the performance benefits would be more noticeable than in the BG environment. Sorry for the extra noise.
    dTd
  • dTddTd Member Posts: 182
    edited July 2018
    What about process threading, leave a pw server running for a year, that's one years worth of wear on that single core? And, basically would two equivalent speed processors, one having a single core and one having four cores, the single core has more cpu power for a single process thread?

    I believe back in the day, it's the reason I chose a single core processor for 32b linux, Skyrim on the other hand forced me to move to a multicore processor which dramatically increased performance.
  • Dark_AnsemDark_Ansem Member Posts: 992

    Oops, and I just noticed that this popped up in what I thought was a BG forum, rather than NWN, so the engine may not be as crusty as I thought for adding MT, and the performance benefits would be more noticeable than in the BG environment. Sorry for the extra noise.

    LMAO maybe you should have stayed in bed yesterday?
    GreenWarlock
  • SherincallSherincall Member Posts: 387
    dTd said:

    What about process threading, leave a pw server running for a year, that's one years worth of wear on that single core?

    That is not how it works. Even assuming wear and tear on processors works like that (not quite), if you have multiple cores it is basically random chance on which core your task will execute, often jumping several times a second.
    dTd said:

    And, basically would two equivalent speed processors, one having a single core and one having four cores, the single core has more cpu power for a single process thread?

    This also doesn't quite work like that, anymore. First off, you'll be hard pressed to find a single core CPU anymore (those 1 core servers you rent are VMs). However, if you have a full modern physical CPU (no VMs) that has multiple cores, they usually have an option to "supercharge" a single one if the others are idle.

    Best think of it in terms of heat/cooling - the faster a core spins, the hotter it runs. If you have 4 cores running at 100%, they are generating 4X heat. If only one is running at 100%, it's doing 1X. In which case, it is possible (various HW components permitting) to dynamically overclock that core to e.g. 200% for 4X. Again, not quite, as several other things factor in there, but close enough.

  • dTddTd Member Posts: 182
    edited July 2018



    This also doesn't quite work like that, anymore. First off, you'll be hard pressed to find a single core CPU anymore (those 1 core servers you rent are VMs). However, if you have a full modern physical CPU (no VMs) that has multiple cores, they usually have an option to "supercharge" a single one if the others are idle.

    But it used too right, I bought an athlon 64 single core rather than the double core because at the time nothing was multithreaded and most people running 32b linux felt that was proper. If that was all wrong well can't change what I did now. Oh and I don't rent lol :)

  • SherincallSherincall Member Posts: 387
    Yeah, back then the core logic took a significant portion of the die, so dual cores had worse single core performance. It was a good call at the time.
  • pscythepscythe Member Posts: 116
    Would MT help mitigate TMIs in NWscripts?
  • SherincallSherincall Member Posts: 387
    TMIs are there for a reason. If your scripts are running for too long, they could be broken (e.g. an endless loop), so the game terminates them. Sometimes, you have a script that really does need to do a ton of things, which is why the TMI limit is customizable in the ini. You can set it to something really high, but then you better be damn sure that all your scripts work in all situations, or a bug will bring down the server.


    MT will not help in any way with nwscript performance. The only way it can help the server is to offload the pathfinding, so areas littered with placeables that block movement don't cause issues.
    The impact will be more noticeable in singleplayer as the server and client side can be split - but you can try this yourself by hosting your module locally in multiplayer with the dedicated server and joining that. The only improvement is the convenience of not having to set that up.
    pscytheProontvoidofopinion
Sign In or Register to comment.