|
Home > Archive > Debian Developers > March 2005 > fftw3 non-pic k7 optimisations
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
fftw3 non-pic k7 optimisations
|
|
| Paul Brossier 2005-03-02, 6:11 pm |
| Hi all,
I am trying to get rid of fftw3 non position independant code
brought on i386 by the --enable-k7 configure flag. As dropping
these K7 optimisations gets rid of the non-pic, the problem seems
to lie in dft/k7/codelets/, which are generated by ocaml scripts
found in genfft-k7/.
Two questions:
- can anyone spot what in these codelets causes the non-pic ?
- how much can it hurt to have this non-pic in fftw3 ?
Cheers, piem
| |
| Florian Weimer 2005-03-02, 6:11 pm |
| * Paul Brossier:
> Two questions:
> - can anyone spot what in these codelets causes the non-pic ?
Tables of constants are addressed directly, not in some IP-relative
way.
> - how much can it hurt to have this non-pic in fftw3 ?
It shouldn't matter much if all PIC code is grouped together in the
binary because few pages have to be copied in this case. PIC code
itself is always slower, significantly so if the code is using all
available integer registers.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Paul Brossier 2005-03-02, 6:11 pm |
| On Wed, Mar 02, 2005 at 05:16:50PM +0100, Florian Weimer wrote:
> * Paul Brossier:
>
>
> Tables of constants are addressed directly, not in some IP-relative
> way.
thanks, i thought this could be sort of a problem. so iiuc:
KP707106781KP707106781: .float +0. 7071067811865475244008443621048490392848
35938, +0. 7071067811865475244008443621048490392848
35938
is ok, but
pfmul KP707106781KP707106781, %mm3
is not pic compliant, and should be replaced with something like
pfmul KP707106781KP707106781(%ebx), %mm3
given i didn't know anything about assembly yesterday, how far am i?
>
> It shouldn't matter much if all PIC code is grouped together in the
> binary because few pages have to be copied in this case. PIC code
> itself is always slower, significantly so if the code is using all
> available integer registers.
I did some tests running 1024 points ffts on an AMD 700, and the
difference between with and without --enable-k7 was roughly a
drop of 1.5%. The drop could become more important on K7 with
smaller number of points, where k7/3dnow optimisations come in.
If there is no objections, and as suggested by upstream, i will
disable the k7 optimisations in order to make sure that
libfftw3f.so remains PIC compliant, despite a little slower.
cheers, piem
| |
| Bill Allombert 2005-03-02, 6:12 pm |
| On Wed, Mar 02, 2005 at 07:25:00PM +0000, Paul Brossier wrote:
> On Wed, Mar 02, 2005 at 05:16:50PM +0100, Florian Weimer wrote:
>
> thanks, i thought this could be sort of a problem. so iiuc:
>
> KP707106781KP707106781: .float +0. 7071067811865475244008443621048490392848
35938, +0. 7071067811865475244008443621048490392848
35938
>
> is ok, but
>
> pfmul KP707106781KP707106781, %mm3
>
> is not pic compliant, and should be replaced with something like
>
> pfmul KP707106781KP707106781(%ebx), %mm3
>
> given i didn't know anything about assembly yesterday, how far am i?
Hello Paul,
You need to refer to KP707106781KP707106781 through the GOT, something
like
pfmul KP707106781KP707106781@GOT(%ebx), %mm3
>
> I did some tests running 1024 points ffts on an AMD 700, and the
> difference between with and without --enable-k7 was roughly a
> drop of 1.5%. The drop could become more important on K7 with
> smaller number of points, where k7/3dnow optimisations come in.
>
> If there is no objections, and as suggested by upstream, i will
> disable the k7 optimisations in order to make sure that
> libfftw3f.so remains PIC compliant, despite a little slower.
Why do you insist to have that code be position-independant ?
On x86 that achieve very little. It is common for library including
hand-written asm code to not be position-independant on x86, because
position-independant asm code is slower and uglier so the incentive
to write it is small.
(Sorry to be pedantic, but 'PIC compliant' is meaningless: PIC is not
a standard but an attribute)
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Goswin von Brederlow 2005-03-04, 2:52 am |
| Florian Weimer <fw@deneb.enyo.de> writes:
>
> It shouldn't matter much if all PIC code is grouped together in the
> binary because few pages have to be copied in this case. PIC code
> itself is always slower, significantly so if the code is using all
> available integer registers.
He is talking about non PIC code in the dynamic library. On i386 that
generaly works but fails pretty much everywhere else (but it's k7
specific code).
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Paul Brossier 2005-03-06, 8:47 pm |
| On Wed, Mar 02, 2005 at 10:47:34PM +0100, Bill Allombert wrote:
> Hello Paul,
>
> You need to refer to KP707106781KP707106781 through the GOT, something
> like
> pfmul KP707106781KP707106781@GOT(%ebx), %mm3
Ok, i gave it a try, it compiles and runs fine, but i still get
the 'objdump -p libfftw3f.so | grep TEXTREL' to show up.
> Why do you insist to have that code be position-independant ?
I could say because it is a 'must' in the debian policy, but...
Given that this error occurs only on i386, that fftw3 now works
fine on K7 and alike and that non-pic code does not seem to cause
too much problems, i could put a lintian override for now.
Upstream told me they will have that fixed in the next release.
> (Sorry to be pedantic, but 'PIC compliant' is meaningless: PIC is not
> a standard but an attribute)
you're not, i'm learning 
cheers, piem
| |
| Florian Weimer 2005-03-07, 7:48 am |
| * Paul Brossier:
>
> I could say because it is a 'must' in the debian policy, but...
There is no such requirement in the Policy. 8-)
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Paul Brossier 2005-03-07, 5:56 pm |
| On Mon, Mar 07, 2005 at 02:05:44PM +0100, Florian Weimer wrote:
> * Paul Brossier:
>
>
> There is no such requirement in the Policy. 8-)
10.2. Libraries
---------------
The shared version of a library must be compiled with `-fPIC', and the
static version must not be. In other words, each source unit (`*.c',
for example, for C files) will need to be compiled twice.
hrm, but yeah of course, one could say that it's fine if a
library compiled with -fPIC still contains non position
independant code.
bye, piem
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Henrique de Moraes Holschuh 2005-03-07, 5:56 pm |
| On Mon, 07 Mar 2005, Paul Brossier wrote:
> On Mon, Mar 07, 2005 at 02:05:44PM +0100, Florian Weimer wrote:
>
> 10.2. Libraries
> ---------------
>
> The shared version of a library must be compiled with `-fPIC', and the
> static version must not be. In other words, each source unit (`*.c',
> for example, for C files) will need to be compiled twice.
>
> hrm, but yeah of course, one could say that it's fine if a
> library compiled with -fPIC still contains non position
> independant code.
Just a small question: does the system KNOW an object compiled with -fPIC
but which contains non-PIC code must be treated as a non-PIC object? If it
does, then yes, it really should not be a major problem to leave the non-PIC
code in place. The lib would not be prelinkable, but that is no major loss.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florian Weimer 2005-03-07, 5:56 pm |
| * Henrique de Moraes Holschuh:
> Just a small question: does the system KNOW an object compiled with
> -fPIC but which contains non-PIC code must be treated as a non-PIC
> object?
On x86, the dynamic linker can perform the necessary relocations when
a DSO is loaded which contains position-dependent code. On other
architectures, this is different, but I expect the PIC penality to be
smaller (thanks to more registers or IP-relative addressing).
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Nicholas Breen 2005-03-07, 5:56 pm |
| On Mon, Mar 07, 2005 at 02:07:31PM +0000, Paul Brossier wrote:
> hrm, but yeah of course, one could say that it's fine if a
> library compiled with -fPIC still contains non position
> independant code.
This came up briefly on -policy some time ago as the result of #175074
and #175077, but without much in the way of resolution:
http://lists.debian.org/debian-poli...2/msg00046.html
I'd interpreted that piece of policy to imply "shared libraries must
not contain non-PIC code", and as a result, have some packages with a
similar problem to yours sitting in limbo... if those x86-only non-PIC
optimizations still satisfy the requirements, I'd like to know too!
--
Nicholas Breen
nbreen@ofb.net
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2005-03-07, 5:56 pm |
| On Mar 07, Paul Brossier <piem@altern.org> wrote:
> 10.2. Libraries
> ---------------
>
> The shared version of a library must be compiled with `-fPIC', and the
> static version must not be. In other words, each source unit (`*.c',
> for example, for C files) will need to be compiled twice.
>
> hrm, but yeah of course, one could say that it's fine if a
> library compiled with -fPIC still contains non position
> independant code.
It's still not generally acceptable, but the policy does not reflect
current practice.
The idea is that PIC code is acceptable on architectures which can
support it (i386 and IIRC another one) *IF* there is a positive tradeoff
between the speed gain and the wasted RAM.
The most situation where non-PIC code is a good idea is a library
containing hand-optimized assembly code. It may still be possible to
rewrite it to be PIC without a major performance loss, but it would
probably take a lot of time.
--
ciao,
Marco
| |
| Daniel Kobras 2005-03-07, 5:56 pm |
| On Mon, Mar 07, 2005 at 07:05:40PM +0100, Marco d'Itri wrote:
> On Mar 07, Paul Brossier <piem@altern.org> wrote:
>
> It's still not generally acceptable, but the policy does not reflect
> current practice.
> The idea is that PIC code is acceptable on architectures which can
> support it (i386 and IIRC another one) *IF* there is a positive tradeoff
> between the speed gain and the wasted RAM.
> The most situation where non-PIC code is a good idea is a library
> containing hand-optimized assembly code. It may still be possible to
> rewrite it to be PIC without a major performance loss, but it would
> probably take a lot of time.
Marco, what's your current feeling towards #175077 (non-PIC code in
libdv) that you submitted back then when prelink entered Debian? It's a
case of hand-optimized assembly in a multimedia lib, and here I've
indeed tried (and failed miserably) to convert to position-independent
assembly. Should we keep such bugs open, waiting for policy to be
changed, downgrade them to wishlist, or simply close them unfixed?
Regards,
Daniel.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Bill Allombert 2005-03-07, 5:56 pm |
| On Mon, Mar 07, 2005 at 12:10:00PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 07 Mar 2005, Paul Brossier wrote:
This is my interpretation of policy, fwiw (that policy require libraries
to be build with -fPIC, not to be position-independant.).
[vbcol=seagreen]
> Just a small question: does the system KNOW an object compiled with -fPIC
> but which contains non-PIC code must be treated as a non-PIC object? If it
> does, then yes, it really should not be a major problem to leave the non-PIC
> code in place. The lib would not be prelinkable, but that is no major loss.
Yes, the static linker take care of it.
Please note that prelinking require slightly less than
position-independance, so in fact the library might end up being
prelinkable while not PIC.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Marco d'Itri 2005-03-08, 7:52 am |
| severity 175077 wishlist
thanks
On Mar 07, Daniel Kobras <kobras@debian.org> wrote:
> Marco, what's your current feeling towards #175077 (non-PIC code in
> libdv) that you submitted back then when prelink entered Debian? It's a
> case of hand-optimized assembly in a multimedia lib, and here I've
> indeed tried (and failed miserably) to convert to position-independent
> assembly. Should we keep such bugs open, waiting for policy to be
> changed, downgrade them to wishlist, or simply close them unfixed?
I'm downgrading it to wishlist, having PIC code should still be a goal
unless it has been benchmarked to be too much slow.
--
ciao,
Marco
|
|
|
|
|