On Tue, 2005-01-25 at 23:58, Rein Klazes wrote:
On 25 Jan 2005 14:22:40 -0800, you wrote:
I'm quite certain that many programs use that function for extremely time critical code (games, anyone??), and that thus the Windows function is equally highly optimized, certainly much less slow than a gettimeofday() call.
This should remain based on rdtsc IMHO, or on equally suitable and fast methods (ACPI counter, ...).
Or did you actually test it with programs calling it a large number of times, or test its performance behaviour on Windows?
Andreas Mohr
Our system uses the performance counter all the time in extremely time critical code. If the call is anything more than a few cycles with absolutely no chance of blocking, we are hosed!
The application is an embedded audio plugin player. The audio is processed with SCHED_FIFO and needs to be as deterministic and fast as possible.
I hope this fix/change doesn't jeopardize our product's use of Wine...
You are of course in an excellent position to quantify better then "extremely time critical" and "few cycles". Just try the patch and tell us when you are "hosed". I have done a few further tests. A loop like:
for(i=0;i<10000000;i++) QueryPerformanceCounter( &count);
takes under Windows 2k, on some hardware 45 seconds. Under Wine on the exact same hardware it takes (with the patch) 13 seconds.
OK. Sorry. My ebullience has once again resulted in poor mailing list style! Not the first time. I'll turn on "serious careful engineer mode". Let's see how I do... %)
My concern isn't the number of cycles. It sounds like the function runs very quickly, even faster than in Windows. That's great news.
But I am concerned about blocking or preemption. I assume that the new call doesn't hit the wineserver, right? Is there any other thread sync required (critical sections, etc) for gettimeofday() which might cause the new implementation to block? I don't know how it is implemented, but it sounds like a "system call" which makes me suspicious. I know that Windows developers class QueryPerformanceCounter as a "system call that's safe to use in real time" so that's why I am trying to keep tabs on it.
We don't have control over what APIs our hosted audio plugins use. They are written by other developers, and given to us in binary form. So we have to keep a close eye on APIs that plugins commonly use during real time processing.
Sometimes plugins make calls they shouldn't from a r/t priority thread --- like InvalidateRect. I guess in Windows such calls work without blocking almost all the time. But that isn't the case in Wine.
The Wine Semaphore implementation has caused us problems as well. They are much more likely to block in Wine than in Windows. One plugin used it where it shouldn't and its audio processing execution time went completely erratic as it blocked on the wineserver.
Anyway, thanks for your attention to this issue. It sounds like Receptor (our product) will be fine with this change. ... mo