Is it overkill to enable all SIMD instructions supported?

Message

extraketchup · Post by **extraketchup** » Fri Jul 06, 2007 2:37 pm

Hi folks,

I'm sure this must have been covered before, but I couldn't find the thread. Here's my question: if my processor has mmx, mmxext, 3dnow, 3dnowext, sse, etc. etc., is it a good thing to enable support for ALL of these when compiling players such as mplayer and xine, or is it actually overkill and adding code that I don't need?

In other words, if a processor has the extended 3DNow! instructions, do those replace the original 3DNow set, or just add support for features not originally there? If I enable support for 3dnowext when compiling mplayer, will it be smart enough to utilize the original set of 3DNow! when it needs it? And on a similar note, there's SSE, SSE2, and now even SSE3. Do I need to enable support for all of these, or can I just enable support for SSE3 and get all the benefits of SSE and SSE2 without the code bloat? Do I need MMX support, which seems obsolete, just because my processor has MMX?

I've always turned everything on in the past, just because my processor supports it. But I got to thinking that having MMX code in my mplayer that is never used (because mplayer will see I have SSE3 and ignore MMX) is contributing to code bloat (I'm a -Os kinda guy, I hate bloat

), but I'm not sure if I really understand how mplayer uses these. Maybe it can benefit and use both SSE3 and MMX together for even better processing power. So, the big question is - does each new "brand" of SIMD instruction replace and obsolete the previous brand / version, or are they complementary, in that SSE2 depends on the original SSE?

Anyway, if someone can help me with these questions, that would be great. Thanks!!!

Mike

alex.blackbit · Post by **alex.blackbit** » Fri Jul 06, 2007 2:51 pm

IMHO you should enable everything that your processor supports.
if the apperance of SSE2 made SSE obsolete, then why should SSE still be there?
and isn't there SSE 4 already in current intel cpu's?
a quite long time ago i played with the sse and mmx intrinsics in c programs, and AFAIR sse2 just adds more functions and does not replace anything.
but maybe somebody knows more than me...

incidenta5 · Post by **incidenta5** » Sat Jul 07, 2007 2:44 pm

Would this really create additional overhead? I thought that these instructions speed things up.

bLUEbYTE84 · Post by **bLUEbYTE84** » Mon Jul 09, 2007 10:54 pm

They never replace the older; they are always added on top of the other in an iterative way as the new CPU models are developed. Also, as a result, CPU is SSE2 capable implies that it is SSE capable as well (try compiling mplayer with USE="-sse sse2", it will fail - have given me headache sometime ago before I traced this was the result).

FishB8 · Post by **FishB8** » Thu Jul 12, 2007 12:36 am

the -march option implies all supported SIMD instructions.

In other words, if a processor has the extended 3DNow! instructions, do those replace the original 3DNow set,

They do not "replace" anything. 3dnow is a sub-set of 3dnow-ext.

For instance, if 3dnow supports instructions A, B, and C. Then 3dnow-ext supports A, B, C, D and E. A, B, and C are the very same in both instances. Same goes for SSE, SSE2, SSE3...

However, 3dnow and SSE have some overlaps. The complier generally chooses which instruction set is best for a specific task on a specific architecture when you use the -march option.

Generally if you use "-march=insert_arch_here" then you'll do fine. You may want to add "mfpmath=sse". Adding any other SIMD based options to those two options is garbage information as far as the compiler is concerned.

Rob1n · Post by **Rob1n** » Thu Jul 12, 2007 10:55 am

FishB8 wrote:the -march option implies all supported SIMD instructions.

Yes, but I don't think the ebuilds generally check that when choosing parameters for the configure stage - it's then down to the app to do autodetection. To be certain you're best specifying all applicable mmx/sse/3dnow USE flags - the ebuilds will then deal with passing the optimal parameters through for the configure/make stages.

FishB8 · Post by **FishB8** » Fri Jul 13, 2007 1:53 am

Yes, but I don't think the ebuilds generally check that when choosing parameters for the configure stage - it's then down to the app to do autodetection.

If there is a -march option set in your make.conf settings for CFLAGS/CXXFLAGS then ebuilds will pass that right on to the configure script. By default. There is really no checking to be done that you speak of. And many times ebuild will even edit configure scripts when configure scripts fail to take build flags into account. That's the whole point of building with Gentoo.

Ebuilds will somtimes filter out harmful flags by adding options like -mno-sse which when added to a -march option means : use all extensions this architecture has to offer except sse.

Rob1n · Post by **Rob1n** » Fri Jul 13, 2007 8:09 am

FishB8 wrote:If there is a -march option set in your make.conf settings for CFLAGS/CXXFLAGS then ebuilds will pass that right on to the configure script. By default. There is really no checking to be done that you speak of. And many times ebuild will even edit configure scripts when configure scripts fail to take build flags into account. That's the whole point of building with Gentoo.

Yes, I'm aware of that. Unfortunately many configure scripts pay no attention to the CFLAGS settings when deciding what options to enable. If you don't specify the mmx/sse/3dnow USE flags then the configure script may well decide not to use the hand optimised assembly code and fall back to compiling from source. While the compiler will still try to use any mmx/sse/3dnow instructions according to the -march flag, it won't manage to reach the same levels of optimisation.

Cyker · Post by **Cyker** » Fri Jul 13, 2007 7:12 pm

I think most things will automatically enable lower-down ones (e.g. if you enable SSE3, SSE2 and SSE will get turned on too. Specifying SSE tells it to use A; SSE2 tells it to use A and B, SSE3 follows A, B and C).

Problems may arise when ebuilds turn on, say, mmxext, but try and force mmx to be turned off. ebuilds aren't generally very smart in that regard so its best to err on the side of caution and turn on all subsets your CPU supports manually.

As for which one(s) to use, I'll give a run-down (corrections wanted!) of them all and you can decide which ones to enable:

MMX - Uses the x87 FPU registers (So you can't do x87 math while doing MMX ops), accelerates integer operations. All CPUs above a Pentium support this.

3DNow! - Also uses the x87 FPU registers (So you can't do 3DNow! and [x87 or MMX] math at the same time), but can do integer and floating point SIMD math. Uses fast RISC'y instructions but has limited precision (64-bit?). All AMD CPUs above the K6-2 support this.

SSE - Has it's own set of registers, but requires the CPU be switched into a new state which can slow things down if switching back and forth a lot. Does floating-point and integer SIMD and is capable of 128-bit precision. All Intel CPUs above a P-III supprt this; All AMDs above an Athlon XP support this.

You can switch all on and just hope the compiler is smart enough to pick the best one for the job (3DNow! is faster for short bursts because its instructions are very low latency, but SSE is better for 'streams' because it can hold more numbers in its registers).
Additionally, its possibly to use SSE and [3DNow! or MMX] at the same time, but I doubt GCC is smart enough to be able to do this.
I've personally only heard about anyone doing this in hand-crafted assembly Demoscene programs (Best damned programmers in the world that lot!), but anything that uses NASM could if the coders were good enough to balance all the register calls.

Rob1n · Post by **Rob1n** » Fri Jul 13, 2007 8:33 pm

Cyker wrote:You can switch all on and just hope the compiler is smart enough to pick the best one for the job

The USE flags have nothing to do with the compiler (directly anyway). They're just used by the ebuild to determine which switches to pass to the configure script (and are usually used to enable different bits of hand-crafted assembly code in the program). The ebuild should be enabling the fastest option depending on the USE flags (working down through a list until an enabled flag is found).

Cyker · Post by **Cyker** » Sat Jul 14, 2007 11:06 am

Rob1n wrote:
Cyker wrote:You can switch all on and just hope the compiler is smart enough to pick the best one for the job
The USE flags have nothing to do with the compiler (directly anyway). They're just used by the ebuild to determine which switches to pass to the configure script (and are usually used to enable different bits of hand-crafted assembly code in the program). The ebuild should be enabling the fastest option depending on the USE flags (working down through a list until an enabled flag is found).

True, and others have said as much above!

I should have probably said something more like "You can switch all on and just hope the programmer was smart enough to pick the best one for the job"

FishB8 · Post by **FishB8** » Tue Jul 17, 2007 2:10 am

Additionally, its possibly to use SSE and [3DNow! or MMX] at the same time, but I doubt GCC is smart enough to be able to do this.

I'm not sure, but I think that is the functionality enabled by the "-mfpmath=sse,387" option, where gcc uses both the sse and 387 registers at the same time. (I've always thought that is a bit risky though since you would be getting mixed levels of floating point precision.)

The USE flags have nothing to do with the compiler (directly anyway). They're just used by the ebuild to determine which switches to pass to the configure script (and are usually used to enable different bits of hand-crafted assembly code in the program). The ebuild should be enabling the fastest option depending on the USE flags (working down through a list until an enabled flag is found).

I understand now. You're talking about when there are two branches of source code tuned for different SIMD instruction sets. I was thinking the original post was referring to more generic code where the compiler is the only determining factor as to which SIMD instructions to use.

Cyker · Post by **Cyker** » Tue Jul 17, 2007 9:29 am

FishB8 wrote:
Additionally, its possibly to use SSE and [3DNow! or MMX] at the same time, but I doubt GCC is smart enough to be able to do this.
I'm not sure, but I think that is the functionality enabled by the "-mfpmath=sse,387" option, where gcc uses both the sse and 387 registers at the same time. (I've always thought that is a bit risky though since you would be getting mixed levels of floating point precision.)

I think that just enables SSE and 387 floating-point paths, rather than enabling MMX/3DN and SSE, but you're right about it probably being unstable (It specifically says in the man page that using that flag will produce unstable code with gcc.

)

Parallel MMX/3DN and SSE code is still probably limited to hand-crafted ASM alas