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

Dark_Ansem

Back in 2002 NWN showed already that it could consider multithreading as a viable possibility for performance. With this re-release and the promise of getting a 64bit exe, why shouldn't it be possible for better and more multithreading to happen for this re-release?

cacodaemon

Does it really need it? You don't need much of a PC to run this game.

voidofopinion

cacodaemon said:

Does it really need it? You don't need much of a PC to run this game.

The serve client on the other hand...

Dark_Ansem

cacodaemon said:

Does it really need it? You don't need much of a PC to run this game.

Maybe you don't need it NOW. But again, it could be more resource-intesive with prettier VFX, light effects and, more importantly, heavy scripting.

cacodaemon

Dark_Ansem said:

cacodaemon said:

Does it really need it? You don't need much of a PC to run this game.

Maybe you don't need it NOW. But again, it could be more resource-intesive with prettier VFX, light effects and, more importantly, heavy scripting.

If I don't need it now maybe that explains why it shouldn't be a priority. Not saying it isn't a good idea, everybody likes the idea of better performance...but focus is probably better spent in other areas.

voidofopinion

cacodaemon said:

Dark_Ansem said:

cacodaemon said:

Does it really need it? You don't need much of a PC to run this game.

Maybe you don't need it NOW. But again, it could be more resource-intesive with prettier VFX, light effects and, more importantly, heavy scripting.

If I don't need it now maybe that explains why it shouldn't be a priority. Not saying it isn't a good idea, everybody likes the idea of better performance...but focus is probably better spent in other areas.

"640K ought to be enough for anybody." - Bill Gates

Dark_Ansem

voidofopinion said:

cacodaemon said:

Dark_Ansem said:

cacodaemon said:

Does it really need it? You don't need much of a PC to run this game.

Maybe you don't need it NOW. But again, it could be more resource-intesive with prettier VFX, light effects and, more importantly, heavy scripting.

If I don't need it now maybe that explains why it shouldn't be a priority. Not saying it isn't a good idea, everybody likes the idea of better performance...but focus is probably better spent in other areas.

"640K ought to be enough for anybody." - Bill Gates

couldn't have put it better myself.

TarotRedhand

If there were a Trello board item for this I'd vote for it (and don't embarrass me by saying "why there is and it's right here..." .

TR

JuliusBorisov

Ask and it will be given to you

https://trello.com/c/I3VnBseh/130-multithreading-support

TarotRedhand

I said don't embarrass me...

TR

DrHappyAngry

voidofopinion said:

"640K ought to be enough for anybody." - Bill Gates

He didn't actually say that. Nobody can cite the original source. Wired debunked it back in '97 https://www.wired.com/1997/01/did-gates-really-say-640k-is-enough-for-anyone/

I'm curious about something, and I think only somebody familiar with the code would be able to answer it. Maybe @JuliusBorisov could answer? Would multi-threading actually help? Like can the AI and server deal with running as more than one thread? Would it actually show a benefit, say allowing more players to be on a server, or for massive battles with hundreds of AI controlled combatants? Just wondering before I vote for precious developer resources to be used on something.

voidofopinion

DrHappyAngry said:

voidofopinion said:

"640K ought to be enough for anybody." - Bill Gates

He didn't actually say that. Nobody can cite the original source. Wired debunked it back in '97 https://www.wired.com/1997/01/did-gates-really-say-640k-is-enough-for-anyone/

It really doesn't matter if it was taken out of context or if he even said it at all.

Much like many popular "quotes" actively used today It has become allegorical and serves its purpose regardless.

NWN being single threaded is a bottleneck the community has no ability to mod around it.

"Judge me by my intent. Not my shotgun." - Ghandi

DrHappyAngry

I'm not disagreeing that multithreading is something the community can't work around, I'm just asking would it actually be beneficial? A lot of programs still to this day don't thread out well or require a huge amount of refactoring things to make multi-threading happen without crapping themselves. If it's a massive undertaking for a 5% boost to performance in some edge cases, I might rather vote for something else. If it results in us being able to have massive battles of with hundreds of AI creatures or scales up the server to handle more connected clients, awesome, I'm all for it.

Sherincall

Dark_Ansem said:

cacodaemon said:

Does it really need it? You don't need much of a PC to run this game.

Maybe you don't need it NOW. But again, it could be more resource-intesive with prettier VFX, light effects and, more importantly, heavy scripting.

Scripting cannot be parallelized in any way that would end up with a net benefit. On the other hand, it is almost never a bottleneck either - if it is, you've bigger problems.

AI updates and pathfinding are bottlenecks on the server, and this can be split onto different threads, mostly. This will benefit big PWs some.

On the singleplayer side, splitting the client and the server (in SP you run both) onto separate threads wouldn't too hard, but the benefit here is questionable. For most SP modules, the bottleneck is the graphics, and the server that the SP runs is orders of magnitude simpler than a PW. This would likely only help if people want to run an unoptimized PW in singleplayer - in which case, they can just run it in local multiplayer.

Graphics cannot be parallelized (with the exception of some weird hacks in the shadow engine), and you will not get better FPS with prettier VFX or more lights. If this is a perf hog, it should be approached in a different way.


The 64bit+multithreading is constantly requested, but it will not do any of the things you think it will do. You should be requesting features (i.e. "make the game run faster") rather than implementations. Multithreading as a feature on its own is useless.

Dark_Ansem

Well, we know we are getting a 64bit exe and the game already featured some of it.

Sherincall

64bit has some benefits (obvious ones being that Apple will stop supporting 32bit apps), but don't expect the game to be faster because of it. None of the critical paths I've seen are heavy on register use, so the larger register file will not be utilized. As for extra memory... I've never known NWN to hit the 2GB mark, let alone the 3GB limit.

In fact, it is perfectly possible the 64bit program will be _slower_ than the 32bit one, due to more data needing to be transfered in some cases. This won't be noticeable if it happens, but neither will be any speedup from the 64bit.

FinneousPJ

Sherincall said:

In fact, it is perfectly possible the 64bit program will be _slower_ than the 32bit one, due to more data needing to be transfered in some cases. This won't be noticeable if it happens, but neither will be any speedup from the 64bit.

Interesting. Do you have sources?

Dark_Ansem

Would it help however in case of packs such as the PRC?

GreenWarlock

@FinneousPJ A 64-bit build of identical software simply has to move more bits around, as some data (e.g., pointers) are now twice as large. There is no magical speed-up coming from elsewhere, and if we are not benefitting from being able to store more data in RAM, then the simple act of copying data from memory is going to lead to a slight slow-down. This is not only the act of moving more bits across the memory buffer, but also memory caches, notably in the CPU itself, now holding less data (as the data is bigger).

Whether the actual impact itself will be observable is unknown without hard measurements. We may get some 'magical speedups' simply compiling with a more modern compiler that has a better optimizer, although the same would be true for 32-bit code as well. The slow-down, if any, would be best observed measuring against a 32-bit build with the same compiler.

So in practice, I doubt we will see much actual impact on performance going to 64-bits on software of this era, although it is fun to speculate.

TarotRedhand

I voted for this change simply with an eye to the future. It is true that the current set-up of the game may well not show any improvements. Having the possibility that there might be at some point in the future though swung it for me. The same for 64 bit. For example it may turn out that a cure for the infamous "spawn-in stutter" may necessitate the use of more memory than 32 bit allows (doubtful but never say never). Or there could be other scenarios that arise because of BD's vision for this game. Who knows?

TR

FinneousPJ

GreenWarlock said:

@FinneousPJ A 64-bit build of identical software simply has to move more bits around, as some data (e.g., pointers) are now twice as large. There is no magical speed-up coming from elsewhere, and if we are not benefitting from being able to store more data in RAM, then the simple act of copying data from memory is going to lead to a slight slow-down. This is not only the act of moving more bits across the memory buffer, but also memory caches, notably in the CPU itself, now holding less data (as the data is bigger).

Whether the actual impact itself will be observable is unknown without hard measurements. We may get some 'magical speedups' simply compiling with a more modern compiler that has a better optimizer, although the same would be true for 32-bit code as well. The slow-down, if any, would be best observed measuring against a 32-bit build with the same compiler.

So in practice, I doubt we will see much actual impact on performance going to 64-bits on software of this era, although it is fun to speculate.

Yeah the address is twice as large but is not the address bus also twice as large in hardware, moving twice as many bits on the hw level

GreenWarlock

It is the same bus when compiling for 32-bit or 64-bit, so you can move two 32-bit pointer or one 64-bit pointer for the same cost. And as I said, likely the more significant effect will be larger data filling the cache lines of your CPU, so you will get more cache misses, requiring a fetch of data from slower memory.

Probably the biggest issue is that game code is notoriously full of very specific performance hacks, and all of those hacks will be optimized for 32-bit data layouts. On the other hand, if they are designed to make most efficient use of cache memory on the CPU, modern caches dwarf those of the era when the infinity engine was created, which is why I doubt the effect will be observable in practice.

FinneousPJ

GreenWarlock said:

It is the same bus when compiling for 32-bit or 64-bit, so you can move two 32-bit pointer or one 64-bit pointer for the same cost.

I am not an expert in desktop CPUs but I know this is not automatically or necessarily the case

Sherincall

A bit of confusion here, lemme try to clear it up. @GreenWarlock is mostly correct in terms of what the slowdown is - pointers (and some other data) are now larger, which means you can fit less of them in cache. @FinneousPJ is correct that the 64bit program can transfer 64bits atomically, so it is the same number of bus cycles. i.e. "it's not the same bus". It is the same bus, but 32bit programs only use half of it.

There is no magical speed-up coming from elsewhere, and if we are not benefitting from being able to store more data in RAM, then the simple act of copying data from memory is going to lead to a slight slow-down.

There is a "magical speed-up" coming from the fact that you have twice as many registers at your disposal. When you use variables in a program, they are kept in registers. When you run out of available registers, some least used stuff is moved to memory. Compilers are really good at this shuffling, but having more registers is almost always better as you have less to move to memory.
Additionally, 64bit ABI is a bit more optimized than the x86 ones. This means that every time you call a function, you might end up saving a cycle or three.

To sum up, 64bit pros:
- More virtual memory available
- More registers available
- Faster parameter passing when calling functions

64bit cons:
- Larger pointers means less cache usage
- Larger binary code size.

It is perfectly possible to write a program that hits all the cons and none of the pros (I can make you one if you're really interested). Usually though, all of it is so minuscule you'll never notice.

By the way, there is also something called x32, which is a 64bit program with 32bit pointers. It's not very widespread though.

Source: I do this crap for a living.


@TarotRedhand I don't quite follow? Are you saying you want multithreading added in case it might become useful in the future? Adding more threads is literally a single line - in fact NWN already runs over 20 threads for network, sound, and so on. There's no point in creating threads you've no use for. I mean, they can always just mine cryptocurrency on the unused cores, but that's hardly what anyone had in mind.

FinneousPJ

Parasitic mining in commercial game code would be an innovation I guess...

JuliusBorisov

DrHappyAngry said:

voidofopinion said:

"640K ought to be enough for anybody." - Bill Gates

He didn't actually say that. Nobody can cite the original source. Wired debunked it back in '97 https://www.wired.com/1997/01/did-gates-really-say-640k-is-enough-for-anyone/

I'm curious about something, and I think only somebody familiar with the code would be able to answer it. Maybe @JuliusBorisov could answer? Would multi-threading actually help? Like can the AI and server deal with running as more than one thread? Would it actually show a benefit, say allowing more players to be on a server, or for massive battles with hundreds of AI controlled combatants? Just wondering before I vote for precious developer resources to be used on something.

That is a kind of question for a livestream

FreshLemonBun

I doubt you want asynchronous scripts for npc behavior introducing race conditions, path finding on the other hand....

https://software.intel.com/en-us/articles/the-secrets-of-parallel-pathfinding-on-modern-computer-hardware

DrHappyAngry

JuliusBorisov said:

That is a kind of question for a livestream

Problem is I'm always working then. Hopefully somebody else can bring up the question of "What benefits would multithreading bring for NWN?" during the next live stream.

GreenWarlock

@FreshLemonBun nice reference, thanks. Interesting to note that article is almost 8 years old, wonder how much the state of the art has advanced since then?

*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.

seronx

What type of multi-threading(multi-tasking/multi-processing) style are we talking about?

Process? (mostly symmetrical)
Thread? (mostly cluster - type 1 asymmetrical)
Threadlet? (mostly grid - type 2 asymmetrical)

Dark_Ansem

Out of curiosity, I've noticed game performance drop significantly during Hordes of the Underdark (Eye Tyrant bridge VFX, specifically). Wouldn't multithreading help in that regard?