64-bit and SSE

[retard]

Tue, 02 Mar 2010 15:13:10 -0500, Nick Sabalausky wrote:

> "dsimcha" <dsimcha at yahoo.com> wrote in message
> news:hmjpkt$1i20$1 at digitalmars.com...
>> == Quote from retard (re at tard.com.invalid)'s article
>>> Tue, 02 Mar 2010 14:17:12 -0500, Nick Sabalausky wrote:
>>> > "retard" <re at tard.com.invalid> wrote in message
>>> > news:hmjmjd$15uj$1 at digitalmars.com...
>>> >>
>>> >> SSE(2) ? Don't people already use SSE 4.2 and prepare for AVX?
>>> >
>>> > Yes. The ones who enjoy arbitrarily shrinking their potential user
>>> > base.
>>> Why not dynamic code path selection:
>>> if (cpu_capabilities && SSE4_2)
>>>   run_fast_method();
>>> else if (cpu_capabilities && SSE2)
>>>   run_medium_fast_method();
>>> else
>>>   run_slow_method();
>>> One could also use higher level design patterns like abstract
>>> factories here.
>>
>> Two reasons:  At the top end it's more trouble than it's worth unless
>> the code is
>> **really** performance critical, and a lot of code with really
>> performance critical floating point is scientific computing code that
>> may only have to run on
>> one arch anyhow.
>>
>>
> I'd think that kind of branching could be done automatically by a
> reasonably intelligent optimizer. Or there's the possibility of
> compiling-upon-installation that could just detect the CPU being used
> (although that admittedly comes with a few difficulties and potential
> issues). I guess I was only assuming that retard was suggesting
> requiring > SSE2. I'm not sure if he really did mean it that way.

You can compile two versions of e.g. mplayer. The one with architecture 
fixed on compile time and the one with dynamic cpu detection. The latter 
is rather useful for free linux live CDs when you really can't guess all 
the target machines beforehand.