[RANT]And how much benefit do you think that "ls" is going to get from using SSE instructions? Is it going to spit out each line in parallel? Is it somehow going to get the data off the disk in parallel? The same goes for almost all applications. There are a very few applications that can make good use of the SIMD instructions. Most of those applications actually get their benefit from using the right glibc and right kernel for the applications. The remaining handful -- gimp, lame, xine, et al -- deal with the SIMD instructions in their own way, usually selecting the right routines for the architecture at run time.
Now then: where's my Pentium4-optimized RPMs? The 1990s are long gone and GCC v2.x with it. It's a shame that the "-march=pentium4" and "-msse2" switches in GCC v3.x are going unused in a major distro like Red Hat's.
[/RANT]
There are some applications that don't get the benefit of the SIMD instructions. For example, there are a million and one implementations of base64 encode and decode and a million (or more) of them do good old fashioned bit shifting and I don't believe that the gcc optimiser has yet reached the giddy heights of optimising code to run in a totally different way ...
Pick your favourite "slow" application, find a benchmark for it, and compare that benchmark with the Red Hat supplied version and the version that you compile with whatever fancy architecture flags will make it run faster. Post the results here, I'm sure a lot of people would be interested.
jch
-- Shrike-list mailing list Shrike-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/shrike-list
