The approach I’m taking for the tinderbox is to not use any special optimisation flag in it, even though I could use it to test stuff that can get tricky, such as -ftracer. It is important to note that it doesn’t even set any particular architecture, meaning that the compiler is told to use the default i686 architecture without any SIMD extension enabled.
Why is this relevant? Well, there seems to be some trouble with this idea. A number of packages, both multimedia and not, seem to rely to the presence of some of those instructions. The problem is not when they actually insert literal ASM code using said extensions, as that is passing right through the compiler and sent directly to the assembler program, which is always supporting the whole set of extensions, at least for what concerns x86, for what I can tell (other architectures seem to have more constrained assemblers).
The problem is that a C compiler such as GCC provides an “higher-level” interface to the processor’s: intrinsics. Intrinsics allow to write C code that calls instructions directly on the C objects, without using volatile ASM literals, and reusing similar syntax between MMX/SSE or other extensions. This is not really a common way to implement SIMD-based optimisations, as most of the developers involved in hard optimisation, such as in libav, prefer writing their own code directly, tweaking it depending on the processor’s design and not just on the extension used. As you can see in libav’s sources, the most recent optimisations have been written directly in assembly source files compiled with yasm rather than in C files.
Unfortunately, this is hindering my tinderboxing efforts, as it is going to stop me from installing in the container some of the packages, which in turn means that their dependencies can’t be installed. Now it is true that many times this situation is mostly something that the developer didn’t consider, and can be fixed, but in a number of projects there is no intention to remove the blocker, as they refuse to support older CPUs without said SIMD, mostly because of performance reasons.
I’m not sure how to proceed here: I could either change the tinderbox’s flags so that SSE is enabled, which would reflect your average modern system, or I could keep filing bugs for those packages until we sort out a way to deal with them. Suggestions are definitely welcome.
What happened to the amd64 tinderbox? I imagine that will have SSE2 enabled by default
The point of the tinderbox is to do the greatest good for the greatest number of people, no? It seems likely to me that Gentoo is being run more often on semi-modern servers and desktops than on very old hardware or intense embedded scenarios. So it’s probably more beneficial to enable SSE on the tinderbox than to continue building without it.That’s not to say that USE blockers shouldn’t be added for packages that require SSE implicitly. Those are still good to have – accurate metadata harms nobody.
I somehow doubt that there are many Gentoo users who use pre- Pentium III / Athlon-XP (2001) machines, that don’t have SSE.It’s a shame, though, that we don’t know the actual user demographics – it’d be nice if there was some service which gathered what people use so that developers knew what was worth putting effort into and what wasn’t.
While it is of course nice to find implicit dependencies, I consider it a waste of time to support very old architectures in new version of software. If people want to stay on that old hardware, they should also accept to stay at old software at some point.Not that it applies here, multimedia apps and old hardware don’t fit toghter very well. So my personal suggestion would even be to set -march=native. Better to find bugs triggered that way, they’ll help more people.
+1 for enabling SSE.Perhaps auto-bugfile for those that you have detected, and then make the switch. I sincerely doubt that fixing those bugs will be a major priority though
I don’t see the point of filing bugs for such packages. You already said upstream won’t support older CPUs so, unless you are willing to patch forever…On the other hand, it’s true that these packages will be hardly used on pre-sse cpu
I wonder if any of the modern cell phone style ARM CPU do not have SSE/MMX?Things like the newer qualcom’s, and tegra2, and such. I see those as viable home server platforms in the near future.anyways, also +1 for enabling SSE/MMX.
First of all, yes, all the packages that will fail to build with SSE or other extensions enabled in the compiler’s flags have a bug opened against them. Most of the time, the bug will stay open simply because there is no way to deal with them.Simply requiring @USE=sse@ is not enough unless we make the USE mangle the flags and add a @-msse@ to the compiler to enable the instruction set, which could actually be an option, but not a very solid one.My original reason to not want to add any arch to the tinderbox was to make it possible to catch stuff that cannot be built for generic targets, which is usually what we do for stages. But I start to wonder if it isn’t more useful to go native indeed.Mike, the 64-bit tinderbox is sitting tight right now; last time I started up it had a bit of trouble so it is last in the set of three tinderboxes that run: the main one is still 32-bit and still takes way too much time to run.Cynyr, ARM does not have SSE/MMX proper, since they are x86-specific SIMDs. And yes, this also means that the software that does not fall-back to have a pure C version if SSE is not available will never run on non-x86 architectures. They call it a compromise. I’m not sure I agree.
It would seem to me that ebuilds need some mechanism to indicate a dependency on particular SIMD extensions and, possibly, specific compilers. (Considering they’re using intrinsics, which are going to be particular to the compiler in question)I say, keep submitting bug reports until the ebuilds in question expose dependency information for those instructions and intrinsics. (Which would lead you to not build them in the first place…)
Use flags are not always enough as things will break. I am thinking of dev-libs/gf2x and bug #366945. So this thing has a sse2 configuration flag and you are allowed to use it on amd64, except that the code for the amd64 rely on sse2 as its default. Passing -sse2 on most amd64 will results in a compilation failure.I guess the configuration could be fixed in some ways to ignore –without-sse2 on amd64 but it is not trivial. For now the strategy adopted is to use a bindist use flag so we can default to the lowest common denominator for that particular arch.
I recently found out that -march=native does NOT always turn on sse Much to my surprise and wound up manually adding -msse4a which did enable the ones supported. I also removed -pipegcc -Q -march=native -O2 -ggdb -D_FORTIFY_SOURCE=2 –help=target reported that sse flags were not enabled while with -msse4a they were (BTW -pipe will break your report if you try that)It is unclear to me if the sse USE flag actually does anything if gcc doesn’t have it enabled.IMHO building as Gentoo does on less than a PIII is too time consuming. Though as flameeyes has confirmed I suspected ARM did not support sse Perhaps other architectures would not (Sparc? Alpha?)
@user99,That output is misleading.See here, for instance: https://forums.gentoo.org/v…
Just my two cents: non-x86 compatibility might be worth something but x86 without even SSE is so useless it’s pretty much outperformed by a mobile phone not to mention that SIMD is mostly used with multimedia applications where you nowadays will want at least a dualcore even if you’re just a user (the pros were packing quadcores and many GB of RAM years ago). In other words, for x86 SSE2 or maybe even SSSE3 would be in order (I’m sorry but nowadays the fabled 3GHz P4 is considered too weak for real multimedia).
You said “I’m sorry of some browsers might fail to display the image properly; please upgrade to a decent, modern browser as it’s a simple SVG file.”I happen to agree with the sentiment. But, purely for informational purposes: your SVG based instant graph did not display properly in Konqueror in web browsing mode.From the ‘about Konqueror’ window:KonquerorVersion 4.7.00 (4.7.0)Using KDE Development Platform 4.7.00 (4.7.0)Or perhaps this might be more meaningful:# eix konqueror[I] kde-base/konqueror Available versions: (4) 4.6.3!t{tbz2} (~)4.6.4!t{tbz2} (~)4.6.5!t{tbz2} (~)4.7.0!t{tbz2} {aqua +bookmarks debug +handbook kdeenablefinal kdeprefix svg} Installed versions: 4.7.0(4)!t{tbz2}(09:56:07 PM 07/30/2011)(bookmarks handbook svg -aqua -debug -kdeenablefinal) Homepage: http://www.kde.org/ Description: KDE: Web browser, file manager, …That I emerged this with USE=”svg”.. should I attempt this upstream?