On 04/29/2011 01:31 AM, Marcus Meissner wrote:
dlls/dinput/device_private.h | 148 +++++++++++++++++++++--------------------- 1 files changed, 74 insertions(+), 74 deletions(-)
What exactly is this supposed to to? This is inside header file, everything declared in it is internal to dinput. Why do we need some extra declarations on it?
Vitaliy.
On Fri, Apr 29, 2011 at 07:38:30AM -0600, Vitaliy Margolen wrote:
On 04/29/2011 01:31 AM, Marcus Meissner wrote:
dlls/dinput/device_private.h | 148 +++++++++++++++++++++--------------------- 1 files changed, 74 insertions(+), 74 deletions(-)
What exactly is this supposed to to? This is inside header file, everything declared in it is internal to dinput. Why do we need some extra declarations on it?
If they are not declared hidden, the -fPIC compile generates PLT relocations for those symbols, even if they are internal to the dll (the compiler does not know what to export during our build).
With the hidden attribute these get turned into just relative calls or simpler relocations.
On x86 this will also save use of the %ebx register.
So e.g. this piece of code:
extern int g(void) __attribute__((__visibility__("hidden"))); int f() { return g(); }
will generate without the visibility line a PLT relocation resolving call:
0000045c <f>: 45c: 55 push %ebp 45d: 89 e5 mov %esp,%ebp 45f: 53 push %ebx 460: 83 ec 04 sub $0x4,%esp 463: e8 ef ff ff ff call 457 <__i686.get_pc_thunk.bx> 468: 81 c3 8c 1b 00 00 add $0x1b8c,%ebx 46e: e8 15 ff ff ff call 388 g@plt 473: 83 c4 04 add $0x4,%esp 476: 5b pop %ebx 477: 5d pop %ebp 478: c3 ret
but with the visibility hidden just a relative call, no relocations:
0000042c <f>: 42c: 55 push %ebp 42d: 89 e5 mov %esp,%ebp 42f: 83 ec 08 sub $0x8,%esp 432: e8 05 00 00 00 call 43c <g> 437: c9 leave 438: c3 ret
0000043c <g>:
Ciao, Marcus
On Friday, April 29, 2011 7:18:47 AM Marcus Meissner wrote:
If they are not declared hidden, the -fPIC compile generates PLT relocations for those symbols, even if they are internal to the dll (the compiler does not know what to export during our build).
With the hidden attribute these get turned into just relative calls or simpler relocations.
Wouldn't it be better to compile with -fvisibility=hidden, then? Default to hidden, then explicitly mark the functions that can be exported from the .so (if Wine even needs PE exports to have "default" visibilty; I don't think it does). Functions that are *never* called from outside the module may be better marked as "internal":
"Internal visibility is like hidden visibility, but with additional processor specific semantics. Unless otherwise specified by the psABI, GCC defines internal visibility to mean that a function is never called from another module. Compare this with hidden functions which, while they cannot be referenced directly by other modules, can be referenced indirectly via function pointers. By indicating that a function cannot be called from outside the module, GCC may for instance omit the load of a PIC register since it is known that the calling function loaded the correct value." http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Function-Attributes.html#Functio... Attributes
FWIW, you can even mark COM functions as "hidden". As noteded above, hidden functions can still be called from the outside (through function pointers, like vtables), they just aren't able to be directly referenced.
Am 29.04.2011 16:18, schrieb Marcus Meissner:
On Fri, Apr 29, 2011 at 07:38:30AM -0600, Vitaliy Margolen wrote:
On 04/29/2011 01:31 AM, Marcus Meissner wrote:
will generate without the visibility line a PLT relocation resolving call:
0000045c <f>: 45c: 55 push %ebp 45d: 89 e5 mov %esp,%ebp 45f: 53 push %ebx 460: 83 ec 04 sub $0x4,%esp 463: e8 ef ff ff ff call 457 <__i686.get_pc_thunk.bx> 468: 81 c3 8c 1b 00 00 add $0x1b8c,%ebx 46e: e8 15 ff ff ff call 388 g@plt 473: 83 c4 04 add $0x4,%esp 476: 5b pop %ebx 477: 5d pop %ebp 478: c3 ret
but with the visibility hidden just a relative call, no relocations:
0000042c <f>: 42c: 55 push %ebp 42d: 89 e5 mov %esp,%ebp 42f: 83 ec 08 sub $0x8,%esp 432: e8 05 00 00 00 call 43c <g> 437: c9 leave 438: c3 ret
0000043c <g>:
Ciao, Marcus
Hi Marcus, That's a very cool search&replace job, Wine reduces size and get's faster. The question is how much faster? Hope we'll see some benchmarks from you :)
On Fri, Apr 29, 2011 at 08:12:36PM +0200, André Hentschel wrote:
Am 29.04.2011 16:18, schrieb Marcus Meissner:
On Fri, Apr 29, 2011 at 07:38:30AM -0600, Vitaliy Margolen wrote:
On 04/29/2011 01:31 AM, Marcus Meissner wrote:
will generate without the visibility line a PLT relocation resolving call:
0000045c <f>: 45c: 55 push %ebp 45d: 89 e5 mov %esp,%ebp 45f: 53 push %ebx 460: 83 ec 04 sub $0x4,%esp 463: e8 ef ff ff ff call 457 <__i686.get_pc_thunk.bx> 468: 81 c3 8c 1b 00 00 add $0x1b8c,%ebx 46e: e8 15 ff ff ff call 388 g@plt 473: 83 c4 04 add $0x4,%esp 476: 5b pop %ebx 477: 5d pop %ebp 478: c3 ret
but with the visibility hidden just a relative call, no relocations:
0000042c <f>: 42c: 55 push %ebp 42d: 89 e5 mov %esp,%ebp 42f: 83 ec 08 sub $0x8,%esp 432: e8 05 00 00 00 call 43c <g> 437: c9 leave 438: c3 ret
0000043c <g>:
Ciao, Marcus
Hi Marcus, That's a very cool search&replace job, Wine reduces size and get's faster. The question is how much faster? Hope we'll see some benchmarks from you :)
I do not think there will be noticable speed-up.
It however has the possibility to make funny Windows code who has troubles with %ebx changes work better.
Also the size of the .sos gets smaller a bit (but just in the kilobyte range).
Ciao, Marcus
On Friday 29 April 2011 21:01:36 Marcus Meissner wrote:
I do not think there will be noticable speed-up.
Actually, not using -fPIC gives a ~2-3% speed boost in a number of d3d benchmarks.
I don't know how much the effect of marking a few functions hidden changes that though. In the d3d code most things are already either static or hidden, and still not using -fPIC on wined3d alone improves things.
On 30 April 2011 00:41, Stefan Dösinger stefandoesinger@gmx.at wrote:
I don't know how much the effect of marking a few functions hidden changes that though. In the d3d code most things are already either static or hidden, and still not using -fPIC on wined3d alone improves things.
Things like TRACEs still cause pc loads. There's the actual wine_dbg_log() call that has to go through the plt, but also the string references and the debug channel info that go through the got. I suppose that if you're crazy enough about performance to care about that kind of thing you'd already compiled those out anyway though.
On Sat, Apr 30, 2011 at 05:18:03AM +0200, Henri Verbeet wrote:
On 30 April 2011 00:41, Stefan Dösinger stefandoesinger@gmx.at wrote:
I don't know how much the effect of marking a few functions hidden changes that though. In the d3d code most things are already either static or hidden, and still not using -fPIC on wined3d alone improves things.
Things like TRACEs still cause pc loads. There's the actual wine_dbg_log() call that has to go through the plt, but also the string references and the debug channel info that go through the got. I suppose that if you're crazy enough about performance to care about that kind of thing you'd already compiled those out anyway though.
This is one of our major overheads, yes.
As distribution packager I wonder if I should build without debug or not. A special package (wine-nodebug)? Or just leave out TRACE() messages?
Ciao, Marcus
On Saturday 30 April 2011 12:31:28 Marcus Meissner wrote:
As distribution packager I wonder if I should build without debug or not. A special package (wine-nodebug)? Or just leave out TRACE() messages?
Is there a configure option for disabling debugging? I couldn't find any when I was looking for one and edited a header file manually
On Sat, Apr 30, 2011 at 12:48:49PM +0200, Stefan Dösinger wrote:
On Saturday 30 April 2011 12:31:28 Marcus Meissner wrote:
As distribution packager I wonder if I should build without debug or not. A special package (wine-nodebug)? Or just leave out TRACE() messages?
Is there a configure option for disabling debugging? I couldn't find any when I was looking for one and edited a header file manually
Quick look, short of
CPPFLAGS="-DWINE_NO_TRACE_MSGS -DWINE_NO_DEBUG_MSGS" ...CFLAGS... ./configure ...
Apparently not.
Ciao, Marcus
On Sat, Apr 30, 2011 at 12:41:19AM +0200, Stefan Dösinger wrote:
On Friday 29 April 2011 21:01:36 Marcus Meissner wrote:
I do not think there will be noticable speed-up.
Actually, not using -fPIC gives a ~2-3% speed boost in a number of d3d benchmarks.
I don't know how much the effect of marking a few functions hidden changes that though. In the d3d code most things are already either static or hidden, and still not using -fPIC on wined3d alone improves things.
I suspect the fixes I am doing are really neglible speed wise.
They are usually not in any fast-paths, it is basically just clean-up.
Perhaps a small bit better load speed of the DSO, also %ebx handling changes might assist broken Windows programs, but otherwise there likely will be no measurable effect.
Ciao, Marcus
-
André Hentschel -
Chris Robinson -
Henri Verbeet -
Marcus Meissner -
Marcus Meissner -
Stefan Dösinger -
Vitaliy Margolen