On Wed, Jun 17, 2009 at 3:28 AM, Kevin Kofler<kevin.kofler@xxxxxxxxx> wrote: > drago01 wrote: >> Only in certain apps, and most of them have handwritten SSE routines >> anyway. > > Not all the apps with handwritten SSE routines can detect the CPU at > runtime, there's a significant amount which needs to be built with or > without SSE support at compile time. (This is broken in principle, but it > exists.) In part, this is because GCC only allows SSE intrinsics to be used > if SSE support is enabled, which also allows GCC to use SSE wherever it > feels like it, even in functions where there are no SSE intrinsics. So the > only way to properly support runtime SSE detection is to compile SSE > routines as a separate compilation unit, which not everyone gets right. Yeah by handwritten I was talking about assembler routines as for instrincts yeah GCC needs sse enabled for this. There is an interesting feature that is worth mentioning here: See "Automatic use of optimized function" in http://udrepper.livejournal.com/20948.html >> Yeah that's why we hide the x86_64 arch from the download page and >> promote x86 everywhere.(attempt to change this failed) > > That's a bad thing indeed, and I'm with you there, this needs to change! The website team does not really care ("x86 works so what?", "cluttering the download page with links is not an option", ...) FESCo delegated this to the website team and as they aren't interested I simply gave up (no need to fight an useless flamewar that wont change anything anyway). A way that would fix this is a LiveDVD with both the x86_64 and x86 image on it and let the bootloader boot the appropriate version. (I don't know if this is possible with the current tools). But this would result into this: * Default media works for every x86 system while it still takes advantage of the hardware (x86_64) * We have more space on the media (even when it has to be shared between x86 and x86_64) * It won't clutter the download page because it will simply replace the current download link But this will probable require some amount of work. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
