On 12/10/21 17:36, Rémi Bernon wrote:
Well as far as I could see, in all the measurements I've made for a long while xsavec64 / xrstor64 were the highest hitters, and something like 10% to 30% CPU time spent on these two instructions.
I don't know if that should be part of the "optimized vast majority of cases", but it's the same with Proton or with current upstream Wine. In any case it's way worse and nowhere near the overhead we had a year ago with SSE XMM register spilling from the ABI transitions generated by the compiler.
It is strange. Unlike the current Proton, xrstor64 should not appear at all with upstream Wine (unless the app is setting the context for threads constantly). Are you sure that is the case with upstream? In that case maybe there is some genuine bug or easy optimization opportunity involved.
Then, for xsavec64, it is doing saves in one instruction which otherwise split in many with compiler generated registers saves. Can it be it affects its place in perf top? Overall I don't think perf can show anything meaningful on such a fine measurement level due to sampling measurements specifics and CPU instruction flow specifics. A good and simple way would be to measure the time over a large amount of calls with rdtsc with and without xsavec, in the real game by instrumenting the syscall dispatcher with that measurement (fwiw I have such an instrumentation for relay stubs locally but not for syscall dispatcher atm).