High CPU use in some applications (not video related)

[kktsuri]

I'm puzzled why does wine sometimes use 3 to 4 more CPU power than Windows does, on applications who do nothing but process data (at least the CPU usage from that).

In my case, I am using an audio DAW called Plogue Bidule.(plogue.com). It works great in wine (as in, no broken features other than lack of auto redraw, no big issue)... but no matter what kind of audio processing you add, be it external VST plugins or native "modules" in the app... you get 3-4 times the CPU usage than in Windows.

It's hard to prove it, and the log/terminal output file isn't helpful at all. It's only like this:

Code: Select all

err:ole:CoInitializeEx Attempt to change threading model of this apartment from apartment threaded to multi-threaded
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",0x3ebe9b8): stub
fixme:win:SetGestureConfig (0x607f0 00000000 1 0x33e580 12): stub
fixme:ole:RemUnknown_QueryInterface No interface for iid {00000019-0000-0000-c000-000000000046}
fixme:avrt:AvRevertMmThreadCharacteristics (0x12345678): stub
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",0x3fbe9b8): stub
fixme:process:GetProcessWorkingSetSize (0xffffffff,0x337068,0x33706c): stub
fixme:msvcrt:__clean_type_info_names_internal (0x5b07458) stub
fixme:msvcrt:__clean_type_info_names_internal (0x5b07438) stub
fixme:avrt:AvRevertMmThreadCharacteristics (0x12345678): stub
fixme:avrt:AvSetMmThreadCharacteristicsW (L"Pro Audio",0x3fbe9b8): stub

and then it repeats those last 2 for a long time, on the tests I did. I am using wine 1.7.42.

Any ideas of what could be the culprit?

Just for information, it scales EXACTLY with CPU use in audio processing directly, so it's not some static wine overhead.

For example, halving the samplerate of the project effectively halves the processing / CPU use, which is normal and same thing happens on Windows (logical too).

It is as if wine uses heavier CPU instructions, I just don't get it, since it's not even an emulator, I doubt apps use many windows APIs in their processing..?


If so, please let me know if you have any ideas. Any ideas for what APIs and dlls should I use for override, to get almost same performance as on windows etc? I mean, just some general push into the right direction, I would appreciate any ideas or help on this. Obviously wine is doing something horrible somewhere, maybe there are some processing performance libraries in windows I am not aware of, which is why I ask for help here. On the appDB page nothing is posted, except my post.

This is unreal. Heck, it runs better (= more performance / less CPU use!) in VirtualBox with a Windows guest OS than in wine...


Any ideas? Should I file a bug...? (I hope it's solveable)

[dimesio]

Just for information, it scales EXACTLY with CPU use in audio processing directly, so it's not some static wine overhead.

Perhaps the native Linux libraries Wine forwards calls to are simply more CPU intensive than the ones in Windows.

[lahmbi5678]

Hello,

how often (per second) do you get that fixme messages? This may sound ridiculous, but excessive spilling of fixmes can seriously slow down wine. You could try to completely suppress wine's debug output:

WINEDEBUG=-all wine your.exe

or just supress the fixmes:

WINEDEBUG=fixme-all wine your.exe

If that fixme is printed excessively, then in some way it may be a bug/shortcoming in wine, so you may file a bug. A wine developer would then probably fix that issue in such a way, that the fixme is printed only once.

Some of the CPU usage may be related to your application desperately trying to do again and again what the fixmes indicate. In that regard you'd have to wait for the wine developers to implement the missing functions, which would also mean that you'd have to file a bug.

kind regards,

[kktsuri]

Thanks for the replies!

I actually don't get much of that message, no idea if it's because I don't have full debug enabled or something but it's pretty rare and only when I "work around" the project (i.e changes settings/routings, add modules etc). My obvious complaint isn't say, sluggish GUI etc which I can obviously work around (just small inconvenience) but the processing on the audio that is done real-time.

As for libraries, well that is my question, which libraries could it be at work here? I mean, think about a program that just processes audio data in effects (modular digital audio workstation). I'm not talking about GUI, changing app settings etc... but only that, the constant processing it does anyway.

It seems to be a constant multiplier of the CPU used on Windows, and I do not understand why. And I am talking about the processing only. Even if I redirect this audio to dummy output (i.e no device / wine driver bugs), it still processes slow. It is as if... the app calls a windows API function to do math data on the audio samples, but then, which library could it be? I'm not aware of any, perhaps other than msvcrt libs...?

What's best way to go around using those dll overrides, just input their names in winecfg and place them near the app or in system32? (I have WinXP disk so no problems there can just copy them -- in virtualbox it works even faster than wine at processing like i said, a bit disappointing)


Unfortunately the WINEDEBUG=-all didn't work for the processing high CPU use. I did notice it started up slightly faster though I'm not sure if that's just placebo effect.

And how would I go about filing up a bug regarding CPU hit?

[lahmbi5678]

Hi,

well, the library in question is probably avrt.dll (as the fixme idicates). If you want to try Windows XP's avrt.dll, put it into the same folder where your application's .exe is. Then set an override in winecfg. Please note, that this may not work, especially if the dll relies on e.g. directx internals, yet it may be worth a try.

If it doesn't work, file a bug in wine's bugzilla and describe the performance penalty.

kind regards,

[kktsuri]

Alright I'll try that, so seems even if i put it in the app directory I still have to override in settings. Perfectly understandable about it messing up (not just directx but I guess other libs that are too deep into low-level stuff), but the app uses OpenGL so shouldn't problems with that (and barely, it's an audio app after all, just GL for basic UI). (anyway it has no issues with the UI other than lack of redraw without clicking )

I'll report tomorrow when I get home I'm too sleepy right now to not mess up something.

[kktsuri]

Late reply but I've been going nuts over trying so many different ways to do it. Overriding avrt.dll did nothing to the processing although it loaded faster (again, could just be placebo effect).

I'm gonna try to hunt down more override dlls 1 by 1, I'll post here if I find success with it, else I'll probably file a bug. (well if I get it working I'll file bug too but I figure if I track down the exact issue, it will be far easier on the developers should they have time to look into it -- anyway I love wine so I can try to help with this atleast)

Thanks for the help.

[kktsuri]

It appears as if having too many parameters exposed is what is causing this massive slowdown, even when opening the Bidule windows. When going to the Parameters window at the top, moving around to assign is painfully slow if you expose many parameters (5000+ for example).

There is no such slowdown in Windows or even in VirtualBox so I can only assume it's a wine bug.

But no idea how to help track down the issue here, as nothing related to it is put into the debug log. I'm fairly new to bug reporting in Wine and I would like to be as helpful as possible and not waste devs' time tracking it down, especially because it's not terribly easy to reproduce (because a "slowdown" would have to be compared to Windows or in a virtual machine, it's not definitive like a crash). I mean it is a very significant slowdown but you'd have to compare it to Windows to see what I'm talking about.