https://bugs.winehq.org/show_bug.cgi?id=39521
Bug ID: 39521 Summary: Calling { SetEvent(h); ResetEvent(h); } takes 36000 machine cycles without contention Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: kernel32 Assignee: wine-bugs@winehq.org Reporter: chris.cochran.protoncore@gmail.com Distribution: ---
This bug may be related to Bug #36692, but this one does not involve any calls to WaitForSingleObject( ), so I am reporting it as a new bug.
A Windows 32-bit bench test, built with VC++ 2010 in Windows 7, designed to measure the machine cycles of a wide range of low-level CPU and system operations, reliably demonstrates that the sequence { SetEvent(h); ResetEvent(h); } costs a minimum of about 36000 machine cycles, when run on Wine 1.7.50 over 64-bit Linux Mint 17.2. This is an isolated single-threaded test, without other threads involved and no contention or waiting for the event object. It operates on a previously created Windows Event object, from an earlier h = CreateEvent(0,1,0,0) call. The CPUs running this test include both i7 930 and i7 980. All systems are running normally and without any observed problems. All the other bench tests show Wine behavior to be similar and on par with normal Windows 7 results.
The bench test operates by calling the above sequence in multiple passes of thousands of repetitions per pass, and selects the minimum time for its reported result. On Wine, the result for a single repetition is about 36000 machine cycles, but the exact same 32-bit binary run on 64-bit Windows 7 shows about 1350 machine cycles for the same test. This result is highly reproducible with very little variance in both 32-bit and 64-bit builds.
I control 100% of the C++ code running this test (one .EXE and one .DLL), but the above result should be easy to reproduce solely from the details I have provided here. I can provide the binary upon request. If this bug is related to Bug #36692, the absence of any WaitForSingleObject( ) calls should make this Bug easier to independently test and demonstrate than the #36692 prescription.
This bug fulfills the definition of a "major bug", because it most likely adversely affects response latency in a large majority of asynchronous event-driven processes developed for Windows (e.g. like frame-rates), and there are no practical alternatives for avoiding this problem.