On Sat, 15 Apr 2006 23:37:17 -0400, Mike Frysinger wrote:
Why would anybody build without tracing anyway? I would be *very* surprised if it led to any noticable/real world performance improvement. Rather than do this why not just restore your packages configure switches to the upstream defaults?
Mike Hearn wrote:
Why would anybody build without tracing anyway? I would be *very* surprised if it led to any noticable/real world performance improvement.
Because of the exact same reason NVidia doesn't want to add yet another dispatch table to linux's OpenGL libraries (as proposed by someone on the xorg ML to add support for a new fancy feature), for functions that are used heavily and are very small (like glBegin()) it decreases the performance by up to 30% for certain applications (I think it was an opengl test suite). I know the overhead of an dispatch table is bigger than a simple 'if (trace) {}', but this few (load, compare == two?) additional instruction still is noticeable in certain applications.
tom
On 4/16/06, Tomas Carnecky tom@dbservice.com wrote:
The overhead of a dispatch table is *much* bigger - indirect jumps can't be branch predicted on older chips, whereas a simple if (trace) absolutely can be and modern hardware branch prediction engines are over 90% accurate.
The GL thunks already have tracing in, yet, nobody seems to be reporting higher framerates with tracing disabled. When things work properly in fact most people report similar framerates to Windows. And the GL thunks are one of the most performance sensitive regions of Wine there are.
So, I'll say it again - can somebody prove that Wine is faster without the tracing? I doubt it. And if there is a region where the debug channel test slows things down we can always add manual branch prediction hints or just take the trace out of that codepath.
thanks -mike
On Sun, Apr 16, 2006 at 01:55:11PM +0100, Mike Hearn wrote:
So if I take your reasonning further, why even keep the '--disable-debug' / '--disable-trace' options in the configure script ?
For me, as long as the user can disable these traces and that he may get 'trace-disabled' builds from stupid sources, the patch can be useful to prevent loosing too much time helping users...
Lionel
On Sun, 16 Apr 2006 15:10:28 +0200, Lionel Ulmer wrote:
So if I take your reasonning further, why even keep the '--disable-debug' / '--disable-trace' options in the configure script ?
Well, I do wonder ... I guess for specialist scenarios some #define in the source would be just as good.
Sure, I don't object to the patch actually, I just wonder why it's even needed.
Lionel Ulmer lionel.ulmer@free.fr writes:
So if I take your reasonning further, why even keep the '--disable-debug' / '--disable-trace' options in the configure script ?
In fact, I think removing them would be a good idea. People who absolutely want to build a broken Wine can always define the appropriate symbols by hand, but there's no reason to encourage this.
Mike Hearn wrote:
It's because some people are Gentoo zealots whose CFLAGS are "-O9 --omfg-optimize -march=8088"
Don't ask why people such stupid things...
Segin wrote:
If we can, why not?
If there is the option to disable the trace it's gotta be there for a reason, why would it be there else, for fun?
Nobody ever told me that disabling the trace will improve performance but I assumed it, less code means faster code (generally speaking).
But it doesn't improve performance, tested it with WoW, at least nothing noticeable. So I'm all for removing this configure option.
tom
-
Alexandre Julliard -
Lionel Ulmer -
Mike Hearn -
Segin -
Tomas Carnecky