   Do you enable SSE in your products?
  I am interested in hearing from commercial software (esp. game) developers if1) they enable SSE/SSE2/SSE3 et cetera in their products at compile-time2) or do they choose to disable it completely at compile-time3) or do they have some sort of a runtime-detection to use SSE if it is available?I am in favour of the option #3, runtime-detection, but I would like to hear how this problem is approached in the software development industry by the professionals.   
  We'll not being a PC developer, I can't say.But the equivalent vector processors on consoles are defiantly used (inline ASM or intrinsics).No runtime detection needed, since all the consoles of a type contain hardware guaranteed to match some spec, and that usually means only things like HDD size change.;  AMD processors, which tend to lag with SSE support, have had SSE1 since the Athlon XP. So unless you intend to actually support the original Athlon processor, you're better off assuming support for SSE1, and having a start-time check that bails if it doesn't pass. The later SSE iterations are more tricky. AMD didn't have SSE2 until the A64, and SSE3 support appears halfway through the line (starting with the E2 stepping).   ;  I typically assume SSE2.  But then, I'm not in a position to care if someone on a 10-year-old computer can't run my dumb game demo :-D  The reason I use SSE instructions in the first place is because performance would be unacceptable even on more modern hardware without it, so it's no loss to me.   ;  We use libraries that use them internally, both 3rd party libraries and corporate libraries that are written by people who specialize in those optimizations.  These libraries detect the hardware capabilities and select the appropriate routines at runtime.We do not directly code for any SIMD instructions, except in exceptional circumstances.I have seen many programmers spend countless hours trying to 'improve' code with SIMD instructions --- even when the code is not a bottleneck, or when the performance gains are insignificant.As I am one of the senior programmers who is involved in optimizations, I have seen many times over the years that blindly trying to use the SIMD instructions will often result in *decreased* performance.  To use them effectively you must know what you are doing and measure with and without those instructions.The exceptional circumstances of moving our code to use SIMD instructions is only done after we identified the code as a bottleneck, that efficient algorithms are already being used with the work spread evenly across frames, and strong evidence that moving to SIMD would substantially improve performance.  In my current game with many thousand source files, only 7 files deep within the engine contain them.   ;4) detect it in the installer.;  5) or detect it in launcher.exe and launch game.exe, game_sse.exe, game_sse2.exe or whatever else.   ;  I have SSE2 in "requirements" (and bail out at startup). The idea is that if someone runs a CPU that doesn't support SSE2, they probably aren't people you'd want as customers anyway.They probably wouldn't be able to run the game for other reasons (DX7 class graphics card with 6 year old drivers, and something like 128 MB of main memory?), and if it ran, it would not be satisfactory. Rather than having an unsatisfied client who creates a support nightmare and keeps complaining on all boards how bad the game performs, you'd probably be off much better not having this client at all.SSE2 is also a good compromise between functionality and availability. SSE3/SSSE3/etc. add little value except for the very latest revision but greatly reduce the number systems that your code runs on.SSE2 on the other hand, offers most everything you need (except dot product or horizontal add) and is supported practically everywhere.Runtime detection and branching is an option of course, but you have to be careful not to spend more time branching than SSE[234] buys you, and it certainly increases complexity.   ;Quote:Original post by bubu LV5) or detect it in launcher.exe and launch game.exe, game_sse.exe, game_sse2.exe or whatever else.This definitely gets around the performance problems with runtime-branching!   ;Quote:Original post by HodgmanQuote:Original post by bubu LV5) or detect it in launcher.exe and launch game.exe, game_sse.exe, game_sse2.exe or whatever else.This definitely gets around the performance problems with runtime-branching!True, but it also means you have to distribute 3x the amount of executables around, or have the installer-downloader pick a particular version (which then won't work on a different machine), or something.It makes the actual programming easier, but puts the burden on logistics. It probably depends a lot on whether you really need the "extra kick" from using special instructions or not. For the most part (but your mileage may vary here) I think it's not worth the trouble.   