I am working on packaging pagedgeometry and I noticed that when building on gcc it passes -msse which I am guessing says to use sse instructions. I think that even in F12 we can't assume these instructions are available. The package may gain a lot of benefit from using those instructions. (I haven't tested that yet as I am still pretty early in the process.) Is there some relatively standard way to handle something like this?
On Fri, 2009-10-30 at 23:07 -0500, Bruno Wolff III wrote:
I am working on packaging pagedgeometry and I noticed that when building on gcc it passes -msse which I am guessing says to use sse instructions. I think that even in F12 we can't assume these instructions are available. The package may gain a lot of benefit from using those instructions. (I haven't tested that yet as I am still pretty early in the process.) Is there some relatively standard way to handle something like this?
You should always adjust any build process which wants to use custom compiler flags to use the standard Fedora flags. Well-written build systems allow you to set compiler flags trivially with a parameter or environment variable. Badly-written ones hard-code their preferred flags and require you to patch before you can pass in the Fedora flags. In the latter case, patch the build system and send the patch upstream.
On Fri, Oct 30, 2009 at 21:29:24 -0700, Adam Williamson awilliam@redhat.com wrote:
You should always adjust any build process which wants to use custom compiler flags to use the standard Fedora flags. Well-written build systems allow you to set compiler flags trivially with a parameter or environment variable. Badly-written ones hard-code their preferred flags and require you to patch before you can pass in the Fedora flags. In the latter case, patch the build system and send the patch upstream.
The way they have this setup with cmake is such that it seems to add -msse on to the Fedora defaults. I think they are going to want that to be the normal case when building for linux. Under those circumstances, am I supposed to ask them to put in a test for Fedora in the cmake build file or is there some standard way of adding -msse when options aren't specified from rpm, but it is added when they are not? I am not sure what I am supposed to recommend to upstream other than perhaps something they aren't likely to do.
Changing the cmake specs in the spec file won't be hard.
2009/10/31 Bruno Wolff III bruno@wolff.to:
I am working on packaging pagedgeometry and I noticed that when building on gcc it passes -msse which I am guessing says to use sse instructions. I think that even in F12 we can't assume these instructions are available. The package may gain a lot of benefit from using those instructions. (I haven't tested that yet as I am still pretty early in the process.) Is there some relatively standard way to handle something like this?
-msse is fine for x86_64 and ia64 by default (but not for non-intel arches). The only way to have sse enabled on ix86 is for a library to be built twice, the provides the sse version in %{_libdir}/sse2. The linker will then enable the appropriate library at runtime. (note that only sse2 wrap exists - not sse{,3,4},atom,i7 ) That's not possible when the optimized code is within a binary.
Now I would really like to promote a comprehensive understanding of that policy. Because sometimes the application requirements are beyond the entry point of sse. There is a package, outside of the Fedora collection, that might be compiled with sse on ix86. There is generic code for it, so it will probably works on s390 or sparc, along with non-sse ix86. But mixing real time multimedia streams for deejay will then became harder if not sse enabled. So the application requirement was to be higher than if the app wasn't compiled with sse.
I also have another case for a package which is an image renderer for blender. Using such app on computer that doesn't have sse is really a miss understanding of what your computer is better used at.
Nicolas (kwizart)
On Sat, Oct 31, 2009 at 09:25:30 +0100, Nicolas Chauvet kwizart@gmail.com wrote:
-msse is fine for x86_64 and ia64 by default (but not for non-intel arches). The only way to have sse enabled on ix86 is for a library to be built twice, the provides the sse version in %{_libdir}/sse2. The linker will then enable the appropriate library at runtime. (note that only sse2 wrap exists - not sse{,3,4},atom,i7 ) That's not possible when the optimized code is within a binary.
That is very useful information. It sounds like I will want to do this for this package, since enabling sse2 will turn on the sse instructions and sse2 might turn out to be useful for this code as well.
Now I would really like to promote a comprehensive understanding of that policy.
It would be nice to have an example of how do the build for something like this in one spec file.
If there is some documentation it should be included in or pointed to by the base packaging page on the wiki so that people can easily run accross it.
I also have another case for a package which is an image renderer for blender. Using such app on computer that doesn't have sse is really a miss understanding of what your computer is better used at.
The package I am working on is doing image rendering as an add on to ogre.
On Sat, 2009-10-31 at 09:29 -0500, Bruno Wolff III wrote:
That is very useful information. It sounds like I will want to do this for this package, since enabling sse2 will turn on the sse instructions and sse2 might turn out to be useful for this code as well.
Now I would really like to promote a comprehensive understanding of that policy.
It would be nice to have an example of how do the build for something like this in one spec file.
The documentation there is is at https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
but it's not a lot.
On Sat, Oct 31, 2009 at 09:33:13 -0700, Adam Williamson awilliam@redhat.com wrote:
On Sat, 2009-10-31 at 09:29 -0500, Bruno Wolff III wrote:
That is very useful information. It sounds like I will want to do this for this package, since enabling sse2 will turn on the sse instructions and sse2 might turn out to be useful for this code as well.
Now I would really like to promote a comprehensive understanding of that policy.
It would be nice to have an example of how do the build for something like this in one spec file.
The documentation there is is at https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
but it's not a lot.
That is where I would expect sse2 information; either inline or a pointer to something more comprehensive.
Not much is using sse2 right now. I would expect that the main ogre package could make use of this, but currently doesn't.
I am having trouble finding good documentation on what the runtime linker does. The link below is the best description I have found so far, and answers a question I had about whether stuff needs to be in /usr/lib/sse2/OGRE or /usr/lib/OGRE/sse2 (the former). (http://lkml.indiana.edu/hypermail/linux/kernel/0704.3/0002.html
I think I know enough to attempt a -sse2 subpackage for x86 arch. The path to proven packager is paved with much learning.
On Sat, Oct 31, 2009 at 09:33:13AM -0700, Adam Williamson wrote:
On Sat, 2009-10-31 at 09:29 -0500, Bruno Wolff III wrote:
That is very useful information. It sounds like I will want to do this for this package, since enabling sse2 will turn on the sse instructions and sse2 might turn out to be useful for this code as well.
Now I would really like to promote a comprehensive understanding of that policy.
It would be nice to have an example of how do the build for something like this in one spec file.
The documentation there is is at https://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags
but it's not a lot.
We could definitely use a more comprehensive section that addresses the need to build the library twice, where to drop the resulting libs on the filesystem, and what flags are/are not supported by the linker.
If someone would like to create a packaging draft for the packaging committee that wouldbe wonderful.
-Toshio
On Sat, 2009-10-31 at 09:25 +0100, Nicolas Chauvet wrote:
2009/10/31 Bruno Wolff III bruno@wolff.to:
I am working on packaging pagedgeometry and I noticed that when building on gcc it passes -msse which I am guessing says to use sse instructions. I think that even in F12 we can't assume these instructions are available. The package may gain a lot of benefit from using those instructions. (I haven't tested that yet as I am still pretty early in the process.) Is there some relatively standard way to handle something like this?
-msse is fine for x86_64 and ia64 by default (but not for non-intel arches). The only way to have sse enabled on ix86 is for a library to be built twice, the provides the sse version in %{_libdir}/sse2. The linker will then enable the appropriate library at runtime.
Strictly, this is not true. Newer binutils has a feature called "indirect functions" that lets you do (logically, this is not what the syntax actually looks like):
typedef void *(*memcpy_func)(void *, void *, size_t); static void *_mmx_memcpy(void *d, void *s, size_t n) { ... } static void *_sse_memcpy(void *d, void *s, size_t n) { ... } /* ... */
__attribute__((indirect)) memcpy_func *memcpy() { if (has_mmx()) return _mmx_memcpy; if (has_sse()) return _sse_memcpy; /* ... */ }
The indirect function is called at symbol resolution time instead of the normal lookup rules, so you can build a single object with support for multiple ISA extensions, without the runtime lookup penalty.
- ajax
On Mon, Nov 02, 2009 at 09:43:30 -0500, Adam Jackson ajax@redhat.com wrote:
Strictly, this is not true. Newer binutils has a feature called "indirect functions" that lets you do (logically, this is not what the syntax actually looks like):
Can you point us to some documentation on this?
Is this something that is encouraged for use in Fedora?
On Mon, 2009-11-02 at 08:49 -0600, Bruno Wolff III wrote:
On Mon, Nov 02, 2009 at 09:43:30 -0500, Adam Jackson ajax@redhat.com wrote:
Strictly, this is not true. Newer binutils has a feature called "indirect functions" that lets you do (logically, this is not what the syntax actually looks like):
Can you point us to some documentation on this?
Is this something that is encouraged for use in Fedora?
Well, the best documentation I can find is the thread discussing the implementation:
http://www.x86-64.org/pipermail/discuss/2009-June/010546.html
and the testcase in binutils:
http://github.com/jiez/binutils/blob/master/ld/testsuite/ld-ifunc/lib.c
glibc seems to be using it in a few places in F12, so I can't imagine it's too broken. That said, I don't think it's the _recommended_ solution for Fedora yet.
- ajax
-
Adam Jackson -
Adam Williamson -
Bruno Wolff III -
Nicolas Chauvet -
Toshio Kuratomi