Hi, a user of rakarrack was getting startup exception SIGILL [1].
Seems the config/make/compile process for this app checks CPU capability of the machine it is being compiled on, and applies optimisations that are available on that processor.
The user has a much older processor.
Upstream suggest [2] that distros could add a script to detect runtime CPU, and call the appropriately compiled executable.
To do that in rpm, I think I would need to call configure a second time. Also, the new compile would overwrite the first compile, so it doesn't seem that easy.
Any suggestions on a way forward ?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=700183
[2] http://rakarrack.sourceforge.net/FAQ.html [Why when I run rakarrack I receive a "Illegal Instruction" message?]
On 05/01/2011 08:30 AM, David Timms wrote:
Hi, a user of rakarrack was getting startup exception SIGILL [1].
Seems the config/make/compile process for this app checks CPU capability of the machine it is being compiled on, and applies optimisations that are available on that processor.
The user has a much older processor.
Upstream suggest [2] that distros could add a script to detect runtime CPU, and call the appropriately compiled executable.
To do that in rpm, I think I would need to call configure a second time. Also, the new compile would overwrite the first compile, so it doesn't seem that easy.
Any suggestions on a way forward ?
Rpm's and Fedora's philosophy is to let rpm specify/dictate CFLAGS, which packages are supposed to respect.
Ralf
On 01/05/11 16:47, Ralf Corsepius wrote:
Rpm's and Fedora's philosophy is to let rpm specify/dictate CFLAGS, which packages are supposed to respect.
Yes, I still have VSs bug (514991) regarding opt flags still open.
So, for the lesser CPU problem, does that mean I just suggest, rebuild srpm on their machine ?
Can I add that minimum CPU requirement to package description ?
If a user wanted to rebuild srpm for their CPU, would it be acceptable to place some sort of conditional in the spec make line, so that the local CPU build could use a suitable Instruction Set ?
Would it still be worth adding a CPU detect script to avoid abrt traces from non-compatible CPU machines. In this case, could it just exit, or leave a message to suggest the user to obtain and rebuild the srpm ?
Hi,
On 05/01/2011 09:14 AM, David Timms wrote:
On 01/05/11 16:47, Ralf Corsepius wrote:
Rpm's and Fedora's philosophy is to let rpm specify/dictate CFLAGS, which packages are supposed to respect.
Yes, I still have VSs bug (514991) regarding opt flags still open.
So, for the lesser CPU problem, does that mean I just suggest, rebuild srpm on their machine ?
Can I add that minimum CPU requirement to package description ?
If a user wanted to rebuild srpm for their CPU, would it be acceptable to place some sort of conditional in the spec make line, so that the local CPU build could use a suitable Instruction Set ?
Would it still be worth adding a CPU detect script to avoid abrt traces from non-compatible CPU machines. In this case, could it just exit, or leave a message to suggest the user to obtain and rebuild the srpm ?
Erm, specifying a minimum support CPU in the package description is not acceptable IMHO. The fix here is to patch the packages buildsystem, so that it gets build for the minimum cpu level which is supported by Fedora, and thus will work out of the box on all systems Fedora supports.
No tricks / hacks with multiple compilation, cpu detect scripts, etc. will be necessary then.
Regards,
Hans
On 01/05/11 17:41, Hans de Goede wrote:
Erm, specifying a minimum support CPU in the package description is not acceptable IMHO. The fix here is to patch the packages buildsystem, so that it gets build for the minimum cpu level which is supported by Fedora, and thus will work out of the box on all systems Fedora supports.
Where is that stated currently, and for older releases ?
No tricks / hacks with multiple compilation, cpu detect scripts, etc. will be necessary then.
Though it comes at the cost of audio lag/latency increase when we are trying to achieve near real time (eg live guitar input to sound effect generation output). Even on the my machine (4x core amd 3Ghz), the calculations the app performs for difficult presets (convolution) can cause jack to abort because rakarrack didn't finish it's calculations before it was required to deliver data.
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ? Can that even be done (reliably) ?
Thanks for your input.
On Sun, May 01, 2011 at 05:56:57PM +1000, David Timms wrote:
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ? Can that even be done (reliably) ?
This is exactly what they should be doing, and yes it can be done reliably as many apps do this (start by looking at /proc/cpuinfo).
(I also looked at how Debian have packaged this, but they don't seem to have fixed the problem at all).
Rich.
Am 01.05.2011 09:56, schrieb David Timms:
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ? Can that even be done (reliably)?
ffmpeg has since years a option "--enable-runtime-cpudetect" what makes the binary a little larger but let it run on all CPUs with good performance
so yes, it is possible
On 05/01/2011 11:46 AM, Reindl Harald wrote:
Am 01.05.2011 09:56, schrieb David Timms:
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ? Can that even be done (reliably)?
ffmpeg has since years a option "--enable-runtime-cpudetect" what makes the binary a little larger but let it run on all CPUs with good performance
so yes, it is possible
And libmpeg2 and many, many other especially multimedia libraries that can get a large benefit from the SIMD and other extensions in later CPUs.
This really should be done at runtime and either a jump table consulted, or code patched in/out by some means (if the expense of pointer lookups on each op is excessive).
I recently became aware of rakarrack and would very much like to use it so I might take a peek at the source to get an idea of the work involved as this is an area of interest of mine (hobby thing though - I can't promise to have lots of time to spend on it!).
Regards, Bryn.
David Timms wrote:
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ?
Yes, this is the ONLY solution that's acceptable for binary packaging in distributions. Otherwise, we can only build the most generic version. (The current packages which enable whatever happens to be supported on the build system are completely broken and shouldn't have passed review.)
Can that even be done (reliably) ?
Yes, all the packages which have WORKING support for SSE etc. in Fedora do that. See e.g. https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... for the implementation Solid (in kdelibs) uses.
Kevin Kofler
On 02/05/11 06:31, Kevin Kofler wrote:
David Timms wrote:
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ?
Further, what can I run over an existing executable to detect what CPU it was built for, ie what instuctions have been included ?
Yes, all the packages which have WORKING support for SSE etc. in Fedora do that. See e.g. https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... for the implementation Solid (in kdelibs) uses.
Thanks Kevin, I'll make the suggestion to developers, and see if they are interested. Cheers, David.
On Mon, May 02, 2011 at 08:50:48AM +1000, David Timms wrote:
On 02/05/11 06:31, Kevin Kofler wrote:
David Timms wrote:
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ?
Further, what can I run over an existing executable to detect what CPU it was built for, ie what instuctions have been included ?
This isn't possible in general.
Disassembling the code (objdump -d) will give you a subset of instructions that it could possibly execute, but no indication (without considerable extra manual work) of what instructions it would actually execute.
Plus you'd then need to sit there with the Intel and AMD PRMs trying to work out which instruction corresponds to which CPU feature.
Rich.
Am 02.05.2011 00:50, schrieb David Timms:
Further, what can I run over an existing executable to detect what CPU it was built for, ie what instuctions have been included?
not really
the application must cpu-runtime-detect itself what means taht for performance-critical parts different code is included and at the start the application checks what code-parts have to be used
but this is nothing anybody can make generic by packaging if the developer do not support native nor you can analyze the binary to find this out
On 02/05/11 11:01, Reindl Harald wrote:
the application must cpu-runtime-detect itself what means taht for performance-critical parts different code is included and at the start the application checks what code-parts have to be used
but this is nothing anybody can make generic by packaging if the developer do not support native nor you can analyze the binary to find this out
OK, thanks all responders for clear logic and possible solutions.
On Sun, 01 May 2011 22:31:42 +0200, Kevin Kofler wrote:
Yes, all the packages which have WORKING support for SSE etc. in Fedora do that. See e.g. https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/en... for the implementation Solid (in kdelibs) uses.
There is the STT_GNU_IFUNC feature implemented for it - the indirect is handled by linker without an additional indirect overhead if applied for a shared library function. For apps it works in a similar way as normal indirect.
In use by glibc:
include/libc-symbols.h: /* Marker used for indirection function symbols. */ #define libc_ifunc(name, expr) \ extern void *name##_ifunc (void) __asm__ (#name); \ void *name##_ifunc (void) \ { \ INIT_ARCH (); \ __typeof (name) *res = expr; \ return res; \ } \ __asm__ (".type " #name ", %gnu_indirect_function");
sysdeps/x86_64/multiarch/memmove.c: libc_ifunc (memmove, HAS_SSSE3 ? (HAS_FAST_COPY_BACKWARD ? __memmove_ssse3_back : __memmove_ssse3) : __memmove_sse2); etc.
Or a simpler testcase: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.base/gnu-ifun...
Regards, Jan
Jan Kratochvil wrote:
There is the STT_GNU_IFUNC feature implemented for it - the indirect is handled by linker without an additional indirect overhead if applied for a shared library function. For apps it works in a similar way as normal indirect.
Are there any caveats (initialization order or so) when using this feature? E.g. would one get away with calling something like http://api.kde.org/4.0-api/kdelibs-apidocs/solid/html/tutorial3.html (i.e. Solid::Processor::instructionSets) in the ifunc or would trying to call such C++ classes lead to errors or unpredictable behavior?
And I presume this is available on ELF glibc targets only, isn't it?
Kevin Kofler
On Mon, 02 May 2011 17:24:53 +0200, Kevin Kofler wrote:
Jan Kratochvil wrote:
There is the STT_GNU_IFUNC feature implemented for it - the indirect is handled by linker without an additional indirect overhead if applied for a shared library function. For apps it works in a similar way as normal indirect.
Are there any caveats (initialization order or so) when using this feature?
Yes, a bit. STT_GNU_IFUNC relocations are sorted as last in the library to be relocated. But still they are called before any static initializers (static constructors), the sample code below outputs: resolver constructor main func1 destructor
E.g. would one get away with calling something like http://api.kde.org/4.0-api/kdelibs-apidocs/solid/html/tutorial3.html (i.e. Solid::Processor::instructionSets) in the ifunc or would trying to call such C++ classes lead to errors or unpredictable behavior?
Unless there are static initializers it should work.
And I presume this is available on ELF glibc targets only, isn't it?
It is GNU/Linux feature, unrelated to glibc (glibc is just one of its users).
STT_GNU_IFUNC is ELF feature and it is in STT_LOOS..STT_HIOS, therefore it needs ELFOSABI_LINUX.
Thanks, Jan
------------------------------------------------------------------------------
#include <stdio.h> #include <time.h>
class C { public: C() { puts ("constructor"); } ~C() { puts ("destructor"); } } c;
static void func1 (void) { puts ("func1"); }
static void func2 (void) { puts ("func2"); }
typedef void (*func_t) (void);
asm (".type _Z9gnu_ifuncv, @gnu_indirect_function");
func_t gnu_ifunc (void) { puts ("resolver"); return time (NULL) & 1 ? func1 : func2; }
int main (void) { puts ("main"); gnu_ifunc (); return 0; }
Hi,
On 05/01/2011 09:56 AM, David Timms wrote:
On 01/05/11 17:41, Hans de Goede wrote:
Erm, specifying a minimum support CPU in the package description is not acceptable IMHO. The fix here is to patch the packages buildsystem, so that it gets build for the minimum cpu level which is supported by Fedora, and thus will work out of the box on all systems Fedora supports.
Where is that stated currently, and for older releases ?
I was hoping someone who knows the exact answer knows... All I can give you is: http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/index.html#...
Which is not really exact...
No tricks / hacks with multiple compilation, cpu detect scripts, etc. will be necessary then.
Though it comes at the cost of audio lag/latency increase when we are trying to achieve near real time (eg live guitar input to sound effect generation output). Even on the my machine (4x core amd 3Ghz), the calculations the app performs for difficult presets (convolution) can cause jack to abort because rakarrack didn't finish it's calculations before it was required to deliver data.
Should I be suggesting to upstream to attempt to detect CPU before running non-available instructions, eg as part of app startup ? Can that even be done (reliably) ?
As already answered by others ideal would be one binary, which runtime chooses between normal C and mmx/sse#/whatever variants based on CPU capabilities.
This is definitely something to ask to upstream, as this won't be trivial.
In the mean time, you need to patch the build-system so that you can control what cpu features it will enable, then you can build a number of variants, install them as /usr/libexec/%{name}-$cpufeaturepostfix
And make /usr/bin/%{name} a shell script which checks /cpu/procinfo for features and then executes the right binary (passing through all cmdline args using the "$@" magic var for proper quoting)
For which variants it makes sense to build, you would need to talk to someone who is more of a cpu head then me, try starting a new thread, with an appropriate $subject.
Note that all of this is only really needed on 32 bits, on 64 bit I believe (*) all cpu's have at least sse2, so unless you want to use sse3 you'll only need 1 binary there.
Which brings us to a simpler alternative, build a no cpu specific optimizations 32 bit version and use sse2 on x86_64, which is nice and simple.
You could then add a README.fedora advising people to use the 64 bit version.
Regards,
Hans
*) Still no CPU head, better verify this with someone who is.
Hans de Goede wrote:
Erm, specifying a minimum support CPU in the package description is not acceptable IMHO. The fix here is to patch the packages buildsystem, so that it gets build for the minimum cpu level which is supported by Fedora, and thus will work out of the box on all systems Fedora supports.
No tricks / hacks with multiple compilation, cpu detect scripts, etc. will be necessary then.
+1
Packages MUST NOT require a newer CPU than Fedora itself.
Kevin Kofler