Pillars of Eternity II - Performance Fix Mod

This thread certainly took an unpredictable turn. How refreshing :)

I didn't start this argument. You have Stingray to thank for that. I really shouldn't have fallen for the troll's bait though. He tells me I'm incompetent and don't know how SMT works then when I explain in enough detail, I'm on "on a rant."

Whatever, enjoy your community here and I'd appreciate it if you guys don't post links to my work in the future.
 
Joined
Jul 16, 2018
Messages
7
I didn't start this argument. You have Stingray to thank for that. I really shouldn't have fallen for the troll's bait though. He tells me I'm incompetent and don't know how SMT works then when I explain in enough detail, I'm on "on a rant."

Whatever, enjoy your community here and I'd appreciate it if you guys don't post links to my work in the future.

You sound like you need a vacation from your sensitivity :)

I don't have the first clue what this is about - except something about multiple threads and Unity.

I was just pointing out that the thread was not predictable.

No need to get upset - and I don't think this "community" is your typical hivemind.

We have room for all kinds - and I should know!

Oh, and if you don't want your work to be official - don't make it available on the Internet. That kinda goes without saying, I should think.
 
Ok. I can believe that Unity is poorly implemented. Btw I've done thread programming in java and while java itself is (relatively) slow it has been ok with queues of 20 or 40 threads - but again these are properly implemented to block until work is required. Most of my recent work has been in C++ (though I did write a threaded java program back in 2012) as a side project for my regular work. Anyway it is what it is - if your structure is bad enough things will run slow. And yes your explanation about not using proper blocking could easily be the root of all evil here. I think if I ever try to write a game I'll work with godot because at least I would be able to properly profile it and examine what is happening. Btw for the record I do most of my software development on linux.

C# in generally is horribly slow. This game crosses C++ and C# boundaries frequently because the real engine underneath all the C# fluff is written in a different language. So you get all the joy of having one language marshal memory layout from one ABI to the other over and over any time you do anything non-trivial.

Unity's been working that way for a long time though, so it's not as efficient as it could be, but it's also not the end of the world.

However, one thing Unity does that very few other engines do, is run its message loop for Win32 on a separate thread from the one that handles the D3D11 swapchain. This is the reason Unity cannot safely enable Fullscreen Exclusive mode by default. You can force it on, but it's likely you will deadlock if you Alt+Tab out because DXGI doesn't particularly like what Unity does.

As if that weren't bad enough, the message pump in some of these games is known to make calls to Sleep (…) rather than MsgWaitFor…. (…). When that alone does not deadlock your software, it will cause window events to pile up and then you sometimes get a flood of messages that have to be handled before the next frame is drawn and you can't meet that deadline -- so you hitch.

Unity is already doing really unsafe things with its threads before you go and add way more of them than the software can keep running. It's why the swapchain thread just up and dies for several frames unless you cut down the number of workers.

These things just don't ever stop with Unity. About the only thing I've found with Unity that doesn't need fixing is its input management. Unreal is terrible at that but good at just about everything else.
 
Joined
Oct 20, 2006
Messages
7,758
Location
usa - no longer boston
Everything is relative :)

A lot of MMO (well a couple) are written in python which is also relatively slow; heck even C is relative slow in some cases - i mean just think about how fast our systems would run if we got rid of that bloody OS and context switching and we programmed the hardware directly like in the old days. Yea strictly speaking C doesn't require an OS but it helps. Then again embedded systems for the most part avoid the overhead of context switching....

Java "relatively" slow? ;)

That was fun, thanks.
 
Joined
Oct 20, 2006
Messages
7,758
Location
usa - no longer boston
Could be worse we could be talking about Ice-Cream instead of threads in a thread on performance :)

Of course a lot of you would probably prefer ice-cream to this crap on threads.

Why is everyone taking my comment as some kind of criticism?

I know.... It's the Sith Lord thing, isn't it? ;)
 
Everything is relative :)

A lot of MMO (well a couple) are written in python which is also relatively slow; heck even C is relative slow in some cases - i mean just think about how fast our systems would run if we got rid of that bloody OS and context switching and we programmed the hardware directly like in the old days.

Well, even Assembler can be slow if you suck at it ;)

But, I've yet to see anything resembling a game that was written in Java - that was also "fast".
 
There are some decent games in Java - they aren't necessarily real time like doom but they were decent. Well decent is a matter of opinion. minecraft was written in java; i'm not sure if it is decent but it sure made the developer a lot of money.

Well, even Assembler can be slow if you suck at it ;)

But, I've yet to see anything resembling a game that was written in Java - that was also "fast".
 
Joined
Oct 20, 2006
Messages
7,758
Location
usa - no longer boston
Who said we took it as criticism. I merely noted that talking about ice-cream in a thread about threads and their impact on performance would be less appropriate then digging into the details of threads.

Why is everyone taking my comment as some kind of criticism?

I know…. It's the Sith Lord thing, isn't it? ;)
 
Joined
Oct 20, 2006
Messages
7,758
Location
usa - no longer boston
There are some decent games in Java - they aren't necessarily real time like doom but they were decent. Well decent is a matter of opinion. minecraft was written in java; i'm not sure if it is decent but it sure made the developer a lot of money.

I didn't say they weren't decent - I said they were slow as hell. Minecraft is a java game? Ok, I didn't know that.

I haven't actually played it myself.
 
Who said we took it as criticism. I merely noted that talking about ice-cream in a thread about threads and their impact on performance would be less appropriate then digging into the details of threads.

Ok whatever you say :)
 
It's not always one language or the other. A lot of modern games (and other applications) are written in a mixture of compiled and interpreted languages. Scripted parts can be written more quickly and are more easily understood, and the key performance-sensitive stuff is coded in something more efficient.
 
Joined
Nov 8, 2014
Messages
12,085
Just take a look at nwn if you need an example. the base game is written in C++ and as many know it has a very rich scripting language. Tidbit when they first released nwn the linux version had symbols so you could see where it died with gdb. The next release they stripped out the symbol table.

It's not always one language or the other. A lot of modern games (and other applications) are written in a mixture of compiled and interpreted languages. Scripted parts can be written more quickly and are more easily understood, and the key performance-sensitive stuff is coded in something more efficient.
 
Joined
Oct 20, 2006
Messages
7,758
Location
usa - no longer boston
No, I can say with a great degree of certainty that it is caused by SMT. I think you're just bitter at this point because you didn't read what I wrote initially and now you have no way out that doesn't make you look foolish.
Nah, not at all. Here's what you wrote on Steam that prompted my initial comment:
half of the cores on CPUs that support Simultaneous Multi-threading compete for resources with one another and you can never actually do work on all of those threads simultaneously.
Straight up wrong. You can actually "do work" on 2 threads on the same physical core simultaneously with HT, and get more total work done (per unit of real time) than just running 1 thread on that same physical core. That is, in fact, the whole point of HT. Many pieces of software can, and do, take advantage of it successfully. There is no doubt to be had there. My only guess is that perhaps you meant that statement only in the context of Unity's threads, and weren't speaking in general - although I don't know how you would know Unity's internals to such a degree. If what you said was indeed meant to be read only in the context of Unity's threads, then I certainly defer to your (supposed) Unity knowledge, as I have none.

Also, you calling me a troll is ridiculous. Feel free to review my >10 year posting history here to confirm I'm not. Meanwhile, you registered here just to pick a fight over an off-hand comment I made, and every reply I've made to you is completely reasonable, tone-wise. You say I called you "incompetent" but I never said anything of the sort or even close, all I did (once you appeared here) is try to help you understand my original comment.
 
Last edited:
Joined
Sep 26, 2007
Messages
3,467
You have to take this into context. It is possible that two cores can't do work at the same time if they contend for the same memory location (one would presume there is proper locking in that case). However, having said that if a thread is lock it shouldn't be using the processor and some other thread should be running. The problem would be if all threads are locked out and your program is effectively single threaded.
-
Ok what i said while true is kind of silly. However there can be basic contention on memory due to prefetching logic which might reduce performance however the reduction should be far less than if you only ran single threaded. Having said this I basically agree that in most code structure you should be able to run 1x thread per ht with benefit. Furthermore the system is running a huge amount of stuff in the background and most games don't come close to using 100% cpu. As I said I'm curious if pillars 2 is actually using 100% when running 16 threads - this is easy enough to check so maybe I'll go ahead and download the game a start it up in a day or so - I suspect the core issue is spinning or lock contention both of these which are easy enough to fix with good code structure. As i said previously locking is relative cheap but holding a critical lock for a long period of time is bad structure and having a bunch of threads spin on a critical lock is also quite bad.

Nah, not at all. Here's what you wrote on Steam that prompted my initial comment:

Straight up wrong. You can actually "do work" on 2 threads on the same physical core simultaneously with HT, and get more total work done (per unit of real time) than just running 1 thread on that same physical core. That is, in fact, the whole point of HT. Many pieces of software can, and do, take advantage of it successfully. There is no doubt to be had there. My only guess is that perhaps you meant that statement only in the context of Unity's threads, and weren't speaking in general - although I don't know how you would know Unity's internals to such a degree. If what you said was indeed meant to be read only in the context of Unity's threads, then I certainly defer to your (supposed) Unity knowledge, as I have none.

Also, you calling me a troll is ridiculous. Feel free to review my >10 year posting history here to confirm I'm not. Meanwhile, you registered here just to pick a fight over an off-hand comment I made, and every reply I've made to you is completely reasonable, tone-wise. You say I called you "incompetent" but I never said anything of the sort or even close, all I did (once you appeared here) is try to help you understand my original comment.
 
Joined
Oct 20, 2006
Messages
7,758
Location
usa - no longer boston
Back
Top Bottom