Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Worse performance/latency in 2021 compared to 2017 #5

Open
emoose opened this issue Aug 17, 2021 · 0 comments
Open

Worse performance/latency in 2021 compared to 2017 #5

emoose opened this issue Aug 17, 2021 · 0 comments

Comments

@emoose
Copy link
Owner

emoose commented Aug 17, 2021

It's been claimed that the 2021 build performs worse than the older, Denuvo'ed 2017 build, with 2021 apparently having worse performance & latencies.

I haven't actually checked the performance myself, but do trust the ones claiming this, porting LodMod to all the commonly used builds also revealed a likely cause for it: 2021 seems to have much less build optimizations applied compared to 2017.
No idea if this was a deliberate change, or maybe something that happened with different compiler/build-environments being used, I just know some pretty beneficial build optimizations are no longer being used in the 2021 build for some reason.

As an example, there's a function I name as cMapControllerBase::Init (2017 addr: 0x5A5220, 2021/Win10 addr: 0x7D51B0)

In the 2021 build, this takes a 2nd parameter which is a constant of 7, this never changes and is hardcoded in the EXE (and is also part of what LodMod's HQMapSlots feature updates), but in 2021 you can see that the parameter given to this function gets used for calculations of a bunch of sizes/offset, is pushed/popped from stack, passed to subroutines called inside it... in other words, a lot of code is ran which works on the value of that parameter.

However in the 2017 build, optimization has made the compiler realize that the constant 7 never changes, and there's no need to calculate any things at runtime: all those sizes/offsets can be mostly calculated during the build & hardcoded instead, the function doesn't even seem to take in a parameter to define it anymore, instead that function (and the subroutines it calls) all have the constant 7 hardcoded inside them.

That's just an example from a part of the code I've been working on, things like that can be seen everywhere when comparing 2021 vs 2017 (along with even worse things like dead-code being ran, or jumps all over the place to non-inlined 1-line functions...)

Though from a modding point-of-view the unoptimized code used by 2021 is actually a lot nicer to work with than the 2017 code (I doubt a lot of the LodMod things could have been figured out very easily with 2017's binary alone, would have been a lot more time-consuming at least), but I don't really think this modding benefit outweighs the performance drop from it.

Until another 4 years pass and SQEX maybe (probably not) decides on another update, I'd guess our only option is to somehow salvage the code we already have.

Maybe it's possible to profile the game and find hotspots, and then "transplant" 2017's code over them, I've done this with code from 2017-debug into 2021 already, depending on the code it isn't too difficult, as usual the harder part is finding the code that needs it... I haven't really done profiling of black-box games like this before though, not even sure how possible it is.

Another option could maybe be code "lifting", where all of the machine-code is lifted into a compiler's bytecode format for modification/re-optimization, and then re-compiled from there. It seems like this might be possible using LLVM & McSema (which apparently even has Win-x64 support), but not sure if this has ever been done with a 16MB+ game EXE before, maybe worth exploring if nothing else helps.

Any other ideas would be appreciated, if all else fails we can just downgrade to the 2017 build I guess, but who knows how long Denuvo activation will last for it...

(also before it's brought up, Denuvo doesn't seem to be a cause of the optimization differences here - 2017 debug was also Denuvo'd, and the level of optimization there is pretty much just as bad as the current 2021 build, actually worse in some cases probably due to using debug build config, so IMO it's unlikely that Denuvo somehow optimized the 2017 build)

@emoose emoose changed the title Worse performance/latency in 2017 compared to 2021 Worse performance/latency in 2021 compared to 2017 Aug 17, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant