On Monday 27 August 2007, tim prince wrote:
> Mihai Donțu wrote:
> > ".p2align 4,,15" I said to myself: "good
> > to know" and did the necessary changes in my "*.S" files.
> > Indeed, what was before a nasty unaligned code, now it's nicely put at a
> > 16byte boundary. However, to my disapointment, this did not make the code
> > run faster :(. "Au contraire", it made it run slower. So why is gcc using it?
> > Or am I missing something?
> >
> > I've tested this on an AMD64 (Turion @ 2.2GHz) machine.
> >
> Did you check your object files, to see whether your linker has observed
> those alignments? Several years into the SSE era, gnu binutils for
> Windows was still configured so as to disable 16-byte alignment. I'm
> told it's still that way on Solaris.
> As the name indicates, the specific version you quote is designed for
> P-II. It won't have as remarkable an effect on other CPUs; I don't even
> know whether anyone has checked this out on Turion. In any case, it
> would normally show a significant gain only for the head of a frequently
> executed loop, and likely only in the case where it avoids an orphan
> partial instruction at the loop head.
> You didn't even say whether you are running in 64-bit mode, where there
> are more possibilities for orphans, such as where the first 2 bytes of
> an LCP instruction form an orphan. Depending on your specific
> combination of circumstances, you might be interested in trying
> variations, such as .p2align 4,,2.
Sorry for the dalayed response. I've been extremely busy :(
So: I'm on a 64bit Gentoo GNU/Linux, stable, gcc 4.1.2 with the latest
and greatest binutils :)
Since I use Gentoo, you can imagine I'm a speed freak :), thus I'm using
the following rule when building my files:
%.o: %.S
gcc -c -g -pipe -ansi -std=gnu99 -W -Wall -Winline -Wdisabled-optimization \
-Wmissing-prototypes -march=athlon64 -fPIC -DPIC -DNDEBUG -DNMMUNIT -D_REENTRANT \
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I. -O3 -fno-exceptions \
-fomit-frame-pointer -o $@ $<
The assembler file I'm compiling, contains 12 routines (stubs) which
make the 'calling-convention-switch' (WIN64->x86_64) (just like NDIS
Wrapper does). Yes, this is the _new_shiny_thing_ these days :)
Now, these stubs (or as I call them: trampolines) induce a fair amount of
delay in the program execution, making this the reason for which I turned
to '.p2align' (never ONCE did I make the association between the name and
Intel PII).
Why I need all this: I have a tool that loads a DLL, provides the basic
needs for it (a couple of kernel32.dll routines) and gives control to it.
I use this DLL to perform a certain type of analysis on some files (7447
of them to be exact).
This DLL calls HeapAlloc() and HeapFree() (along with some others) frequently, via
a code like this (automatically generated at link time or when GetProcAddress() is
called):
movq <pe_address>, %r10 /* the address of the routine that needs to be called */
movq <stub_address>, %r11 /* the address of the trampoline */
jmpq *%r11d /* jump to the required trampoline */
A trampoline, looks like this:
00000000000003f0 <x86_64pc5>:
3f0: 48 89 7c 24 f8 mov %rdi,0xfffffffffffffff8(%rsp)
3f5: 48 89 74 24 f0 mov %rsi,0xfffffffffffffff0(%rsp)
3fa: 48 83 ec 10 sub $0x10,%rsp
3fe: 48 89 cf mov %rcx,%rdi
401: 48 89 d6 mov %rdx,%rsi
404: 4c 89 c2 mov %r8,%rdx
407: 4c 89 c9 mov %r9,%rcx
40a: 4c 8b 44 24 38 mov 0x38(%rsp),%r8
40f: 48 31 c0 xor %rax,%rax
412: 41 ff d2 callq *%r10
415: 48 83 c4 10 add $0x10,%rsp
419: 48 8b 7c 24 f8 mov 0xfffffffffffffff8(%rsp),%rdi
41e: 48 8b 74 24 f0 mov 0xfffffffffffffff0(%rsp),%rsi
423: c3 retq
424: 66 data16
425: 66 data16
426: 66 data16
427: 90 nop
428: 66 data16
429: 66 data16
42a: 66 data16
42b: 90 nop
42c: 66 data16
42d: 66 data16
42e: 66 data16
42f: 90 nop
430: /* next trampoline (x86_64pc6) */
Now, without '.p2align' the tool analyses all 7447 files in approx. 4:30 minutes.
With '.p2align 4,,15'' it rises to approx: 4.50 minutes (not much, but I'm going
easy, with 790MB of files - when I'm done optimizing, this tool will "dive" into
tens of GB).
I'm looking at what gcc does and it seems to believe that '.p2align 4,,15' is *the*
alignment to use for *all* functions and some jump points (jump points usually get
'.p2align 4,,7')
I've tried '.p2align 4,,2': it is *slightly* faster than '.p2align 4,,16' but not
as fast, as without '.p2align'.
Anyway, my question was: why is gcc so "found" of '.p2align' (it uses it in *all*
situations) since it does not always generate fast code. Other than that, gcc does
a great job! ;)
--
Mihai Donțu
