www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Runtime version statement

reply Piotr Szturmaj <bncrbme jadamspam.pl> writes:
The idea is to make versions of code that are environment dependent and 
never change during runtime, _without_ resorting to if statements. This 
statement would be valid only inside function bodies.

Examples of such versions may be:
* supported SIMD CPU extensions MMX, SSE, SSE2, etc.
* AMD vs Intel CPU, to use instructions that are not available on both
* different OS versions (XP/Vista/7, Linux kernel versions)

Why that instead of current if statement?
* some additional speed, avoids multiple checks in frequent operations
* making specific executables (f.i. SSE4 only) by limiting set of 
supported runtime options during compile time

Code example:

void main()
{
     version(rt_SSE4)
     {
         ...
     }
     else version(rt_SSE2)
     {
         ...
     }
     else
     {
         // portable code
     }
}

In this example program checks the supported extensions only once, 
before calling main(). Then it modifies the function code to make it 
execute only versions that match.

Runtime version identifiers may be set inside shared static constructors 
of modules (this implies that rt-version may not be used inside of 
them). SIMD extensions would preferably be set by druntime with help of 
core.cpuid.

Code modification mechanism is up to implementation. One that come to my 
mind is inserting unconditional jumps by the compiler then and fixing 
them up before calling main().

Additional advantage is possibility to generate executables for 
particular environments. This may help reduce execucutable size when 
targeting specific CPU, especially some constrained/embedded system. 
Also many cpuid checks inside druntime may be avoided.

Just thinking loud :)
Jan 07 2012
next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300513427c6a3404b5f7bac4
Content-Type: text/plain; charset=UTF-8

On 7 January 2012 22:44, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:

 The idea is to make versions of code that are environment dependent and
 never change during runtime, _without_ resorting to if statements. This
 statement would be valid only inside function bodies.

 Examples of such versions may be:
 * supported SIMD CPU extensions MMX, SSE, SSE2, etc.
 * AMD vs Intel CPU, to use instructions that are not available on both
 * different OS versions (XP/Vista/7, Linux kernel versions)

 Why that instead of current if statement?
 * some additional speed, avoids multiple checks in frequent operations
 * making specific executables (f.i. SSE4 only) by limiting set of
 supported runtime options during compile time

 Code example:

 void main()
 {
    version(rt_SSE4)
    {
        ...
    }
    else version(rt_SSE2)
    {
        ...
    }
    else
    {
        // portable code
    }
 }

 In this example program checks the supported extensions only once, before
 calling main(). Then it modifies the function code to make it execute only
 versions that match.

 Runtime version identifiers may be set inside shared static constructors
 of modules (this implies that rt-version may not be used inside of them).
 SIMD extensions would preferably be set by druntime with help of core.cpuid.

 Code modification mechanism is up to implementation. One that come to my
 mind is inserting unconditional jumps by the compiler then and fixing them
 up before calling main().

 Additional advantage is possibility to generate executables for particular
 environments. This may help reduce execucutable size when targeting
 specific CPU, especially some constrained/embedded system. Also many cpuid
 checks inside druntime may be avoided.

 Just thinking loud :)

... you could just use if() ? Perhaps detection of these features could be added to the standard library. But I have a feeling it already IS actually (core.cpuid, something I am extremely cynical of) --20cf300513427c6a3404b5f7bac4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 7 January 2012 22:44, Piotr Szturmaj <span di= r=3D"ltr">&lt;<a href=3D"mailto:bncrbme jadamspam.pl">bncrbme jadamspam.pl<= /a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> The idea is to make versions of code that are environment dependent and nev= er change during runtime, _without_ resorting to if statements. This statem= ent would be valid only inside function bodies.<br> <br> Examples of such versions may be:<br> * supported SIMD CPU extensions MMX, SSE, SSE2, etc.<br> * AMD vs Intel CPU, to use instructions that are not available on both<br> * different OS versions (XP/Vista/7, Linux kernel versions)<br> <br> Why that instead of current if statement?<br> * some additional speed, avoids multiple checks in frequent operations<br> * making specific executables (f.i. SSE4 only) by limiting set of supported= runtime options during compile time<br> <br> Code example:<br> <br> void main()<br> {<br> =C2=A0 =C2=A0version(rt_SSE4)<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0...<br> =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0else version(rt_SSE2)<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0...<br> =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0else<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0// portable code<br> =C2=A0 =C2=A0}<br> }<br> <br> In this example program checks the supported extensions only once, before c= alling main(). Then it modifies the function code to make it execute only v= ersions that match.<br> <br> Runtime version identifiers may be set inside shared static constructors of= modules (this implies that rt-version may not be used inside of them). SIM= D extensions would preferably be set by druntime with help of core.cpuid.<b= r> <br> Code modification mechanism is up to implementation. One that come to my mi= nd is inserting unconditional jumps by the compiler then and fixing them up= before calling main().<br> <br> Additional advantage is possibility to generate executables for particular = environments. This may help reduce execucutable size when targeting specifi= c CPU, especially some constrained/embedded system. Also many cpuid checks = inside druntime may be avoided.<br> <br> Just thinking loud :)<br> </blockquote></div><div><br></div><div>... you could just use if() ?</div><= div>Perhaps detection of these features could be added to the standard libr= ary. But I have a feeling it already IS actually (core.cpuid, something I a= m extremely cynical of)</div> --20cf300513427c6a3404b5f7bac4--
Jan 07 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--00248c768f26681d4d04b5f7cd1d
Content-Type: text/plain; charset=UTF-8

On 8 January 2012 00:31, Manu <turkeyman gmail.com> wrote:

 On 7 January 2012 22:44, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:

 The idea is to make versions of code that are environment dependent and
 never change during runtime, _without_ resorting to if statements. This
 statement would be valid only inside function bodies.

 Examples of such versions may be:
 * supported SIMD CPU extensions MMX, SSE, SSE2, etc.
 * AMD vs Intel CPU, to use instructions that are not available on both
 * different OS versions (XP/Vista/7, Linux kernel versions)

 Why that instead of current if statement?
 * some additional speed, avoids multiple checks in frequent operations
 * making specific executables (f.i. SSE4 only) by limiting set of
 supported runtime options during compile time

 Code example:

 void main()
 {
    version(rt_SSE4)
    {
        ...
    }
    else version(rt_SSE2)
    {
        ...
    }
    else
    {
        // portable code
    }
 }

 In this example program checks the supported extensions only once, before
 calling main(). Then it modifies the function code to make it execute only
 versions that match.

 Runtime version identifiers may be set inside shared static constructors
 of modules (this implies that rt-version may not be used inside of them).
 SIMD extensions would preferably be set by druntime with help of core.cpuid.

 Code modification mechanism is up to implementation. One that come to my
 mind is inserting unconditional jumps by the compiler then and fixing them
 up before calling main().

 Additional advantage is possibility to generate executables for
 particular environments. This may help reduce execucutable size when
 targeting specific CPU, especially some constrained/embedded system. Also
 many cpuid checks inside druntime may be avoided.

 Just thinking loud :)

... you could just use if() ? Perhaps detection of these features could be added to the standard library. But I have a feeling it already IS actually (core.cpuid, something I am extremely cynical of)

Sorry, I only half read your post >_< Many(/most?) systems won't let you write to code memory, so using self modifying code in this way this may be a problem... Additionally, many modern systems use encrypted code memory, so self modifying code is impossible on these systems. But it's an interesting idea, which I have thought about myself too on occasion. --00248c768f26681d4d04b5f7cd1d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 8 January 2012 00:31, Manu <span dir=3D"ltr">= &lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail.com</a>&gt;</spa= n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b= order-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_quote">On 7 Jan= uary 2012 22:44, Piotr Szturmaj <span dir=3D"ltr">&lt;<a href=3D"mailto:bnc= rbme jadamspam.pl" target=3D"_blank">bncrbme jadamspam.pl</a>&gt;</span> wr= ote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The idea is to make versions of code that are environment dependent and nev= er change during runtime, _without_ resorting to if statements. This statem= ent would be valid only inside function bodies.<br> <br> Examples of such versions may be:<br> * supported SIMD CPU extensions MMX, SSE, SSE2, etc.<br> * AMD vs Intel CPU, to use instructions that are not available on both<br> * different OS versions (XP/Vista/7, Linux kernel versions)<br> <br> Why that instead of current if statement?<br> * some additional speed, avoids multiple checks in frequent operations<br> * making specific executables (f.i. SSE4 only) by limiting set of supported= runtime options during compile time<br> <br> Code example:<br> <br> void main()<br> {<br> =C2=A0 =C2=A0version(rt_SSE4)<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0...<br> =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0else version(rt_SSE2)<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0...<br> =C2=A0 =C2=A0}<br> =C2=A0 =C2=A0else<br> =C2=A0 =C2=A0{<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0// portable code<br> =C2=A0 =C2=A0}<br> }<br> <br> In this example program checks the supported extensions only once, before c= alling main(). Then it modifies the function code to make it execute only v= ersions that match.<br> <br> Runtime version identifiers may be set inside shared static constructors of= modules (this implies that rt-version may not be used inside of them). SIM= D extensions would preferably be set by druntime with help of core.cpuid.<b= r> <br> Code modification mechanism is up to implementation. One that come to my mi= nd is inserting unconditional jumps by the compiler then and fixing them up= before calling main().<br> <br> Additional advantage is possibility to generate executables for particular = environments. This may help reduce execucutable size when targeting specifi= c CPU, especially some constrained/embedded system. Also many cpuid checks = inside druntime may be avoided.<br> <br> Just thinking loud :)<br> </blockquote></div><div><br></div></div></div><div>... you could just use i= f() ?</div><div>Perhaps detection of these features could be added to the s= tandard library. But I have a feeling it already IS actually (core.cpuid, s= omething I am extremely cynical of)</div> </blockquote></div><br><div>Sorry, I only half read your post &gt;_&lt;</di= v><div>Many(/most?) systems won&#39;t let you write to code memory, so usin= g self modifying code in this way this may be a problem...</div><div>Additi= onally, many modern systems use encrypted code memory, so self modifying co= de is impossible on these systems. But it&#39;s an interesting idea, which = I have thought about myself too on occasion.</div> --00248c768f26681d4d04b5f7cd1d--
Jan 07 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
Am 07.01.2012, 21:44 Uhr, schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:

 The idea is to make versions of code that are environment dependent and  
 never change during runtime, _without_ resorting to if statements. This  
 statement would be valid only inside function bodies.

 Examples of such versions may be:
 * supported SIMD CPU extensions MMX, SSE, SSE2, etc.
 * AMD vs Intel CPU, to use instructions that are not available on both
 * different OS versions (XP/Vista/7, Linux kernel versions)

 Why that instead of current if statement?
 * some additional speed, avoids multiple checks in frequent operations
 * making specific executables (f.i. SSE4 only) by limiting set of  
 supported runtime options during compile time

 Code example:

 void main()
 {
      version(rt_SSE4)
      {
          ...
      }
      else version(rt_SSE2)
      {
          ...
      }
      else
      {
          // portable code
      }
 }

 In this example program checks the supported extensions only once,  
 before calling main(). Then it modifies the function code to make it  
 execute only versions that match.

 Runtime version identifiers may be set inside shared static constructors  
 of modules (this implies that rt-version may not be used inside of  
 them). SIMD extensions would preferably be set by druntime with help of  
 core.cpuid.

 Code modification mechanism is up to implementation. One that come to my  
 mind is inserting unconditional jumps by the compiler then and fixing  
 them up before calling main().

 Additional advantage is possibility to generate executables for  
 particular environments. This may help reduce execucutable size when  
 targeting specific CPU, especially some constrained/embedded system.  
 Also many cpuid checks inside druntime may be avoided.

 Just thinking loud :)

Because it could only fix non-inlined code you can as well use lazy binding using thunks. // use static to make it re-entrant safe __gshared R function(Args) doSomething = &setThunk; R setThunk(Args args) { if (sse4) { doSomeThing = &sse4Impl; } else if (sse2) { doSomeThing = &sse2Impl; } else { doSomeThing = &nativeImpl; } return doSomeThing(args); } Much simpler, thread safe and more efficient. __gshared SSE2 = tuple("foo", &sse2Foo, "bar", &sse2Bar); __gshared SSE4 = tuple("foo", &sse4Foo, "bar", &sse4Bar); __gshared typeof(SSE2)* _impl; shared static this() { if (sse4) { _impl = &SSE4; } else if (sse2) { _impl = &SSE2; } else { _impl = &Native; } } _impl.foo(args);
Jan 09 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf30051342cc3dfa04b6287c24
Content-Type: text/plain; charset=UTF-8

On 10 January 2012 08:09, Martin Nowak <dawg dawgfoto.de> wrote:

 Am 07.01.2012, 21:44 Uhr, schrieb Piotr Szturmaj <bncrbme jadamspam.pl>:


  The idea is to make versions of code that are environment dependent and
 never change during runtime, _without_ resorting to if statements. This
 statement would be valid only inside function bodies.

 Examples of such versions may be:
 * supported SIMD CPU extensions MMX, SSE, SSE2, etc.
 * AMD vs Intel CPU, to use instructions that are not available on both
 * different OS versions (XP/Vista/7, Linux kernel versions)

 Why that instead of current if statement?
 * some additional speed, avoids multiple checks in frequent operations
 * making specific executables (f.i. SSE4 only) by limiting set of
 supported runtime options during compile time

 Code example:

 void main()
 {
     version(rt_SSE4)
     {
         ...
     }
     else version(rt_SSE2)
     {
         ...
     }
     else
     {
         // portable code
     }
 }

 In this example program checks the supported extensions only once, before
 calling main(). Then it modifies the function code to make it execute only
 versions that match.

 Runtime version identifiers may be set inside shared static constructors
 of modules (this implies that rt-version may not be used inside of them).
 SIMD extensions would preferably be set by druntime with help of core.cpuid.

 Code modification mechanism is up to implementation. One that come to my
 mind is inserting unconditional jumps by the compiler then and fixing them
 up before calling main().

 Additional advantage is possibility to generate executables for
 particular environments. This may help reduce execucutable size when
 targeting specific CPU, especially some constrained/embedded system. Also
 many cpuid checks inside druntime may be avoided.

 Just thinking loud :)

Because it could only fix non-inlined code you can as well use lazy binding using thunks. // use static to make it re-entrant safe __gshared R function(Args) doSomething = &setThunk; R setThunk(Args args) { if (sse4) { doSomeThing = &sse4Impl; } else if (sse2) { doSomeThing = &sse2Impl; } else { doSomeThing = &nativeImpl; } return doSomeThing(args); } Much simpler, thread safe and more efficient. __gshared SSE2 = tuple("foo", &sse2Foo, "bar", &sse2Bar); __gshared SSE4 = tuple("foo", &sse4Foo, "bar", &sse4Bar); __gshared typeof(SSE2)* _impl; shared static this() { if (sse4) { _impl = &SSE4; } else if (sse2) { _impl = &SSE2; } else { _impl = &Native; } } _impl.foo(args);

Function pointers are super-slow on some architectures. I don't think it's a particularly good solution unless the functions you're calling do a lot of work. --20cf30051342cc3dfa04b6287c24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 10 January 2012 08:09, Martin Nowak <span dir= =3D"ltr">&lt;<a href=3D"mailto:dawg dawgfoto.de">dawg dawgfoto.de</a>&gt;</= span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"> Am 07.01.2012, 21:44 Uhr, schrieb Piotr Szturmaj &lt;<a href=3D"mailto:bncr= bme jadamspam.pl" target=3D"_blank">bncrbme jadamspam.pl</a>&gt;:<div><div = class=3D"h5"><br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> The idea is to make versions of code that are environment dependent and nev= er change during runtime, _without_ resorting to if statements. This statem= ent would be valid only inside function bodies.<br> <br> Examples of such versions may be:<br> * supported SIMD CPU extensions MMX, SSE, SSE2, etc.<br> * AMD vs Intel CPU, to use instructions that are not available on both<br> * different OS versions (XP/Vista/7, Linux kernel versions)<br> <br> Why that instead of current if statement?<br> * some additional speed, avoids multiple checks in frequent operations<br> * making specific executables (f.i. SSE4 only) by limiting set of supported= runtime options during compile time<br> <br> Code example:<br> <br> void main()<br> {<br> =C2=A0 =C2=A0 version(rt_SSE4)<br> =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> =C2=A0 =C2=A0 }<br> =C2=A0 =C2=A0 else version(rt_SSE2)<br> =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...<br> =C2=A0 =C2=A0 }<br> =C2=A0 =C2=A0 else<br> =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 // portable code<br> =C2=A0 =C2=A0 }<br> }<br> <br> In this example program checks the supported extensions only once, before c= alling main(). Then it modifies the function code to make it execute only v= ersions that match.<br> <br> Runtime version identifiers may be set inside shared static constructors of= modules (this implies that rt-version may not be used inside of them). SIM= D extensions would preferably be set by druntime with help of core.cpuid.<b= r> <br> Code modification mechanism is up to implementation. One that come to my mi= nd is inserting unconditional jumps by the compiler then and fixing them up= before calling main().<br> <br> Additional advantage is possibility to generate executables for particular = environments. This may help reduce execucutable size when targeting specifi= c CPU, especially some constrained/embedded system. Also many cpuid checks = inside druntime may be avoided.<br> <br> Just thinking loud :)<br> </blockquote> <br></div></div> Because it could only fix non-inlined code you<br> can as well use lazy binding using thunks.<br> <br> // use static to make it re-entrant safe<br> __gshared R function(Args) doSomething =3D &amp;setThunk;<br> <br> R setThunk(Args args)<br> {<br> =C2=A0 if (sse4)<br> =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0doSomeThing =3D &amp;sse4Impl;<br> =C2=A0 }<br> =C2=A0 else if (sse2)<br> =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0doSomeThing =3D &amp;sse2Impl;<br> =C2=A0 }<br> =C2=A0 else<br> =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0doSomeThing =3D &amp;nativeImpl;<br> =C2=A0 }<br> <br> =C2=A0 return doSomeThing(args);<br> }<br> <br> Much simpler, thread safe and more efficient.<br> <br> __gshared SSE2 =3D tuple(&quot;foo&quot;, &amp;sse2Foo, &quot;bar&quot;, &a= mp;sse2Bar);<br> __gshared SSE4 =3D tuple(&quot;foo&quot;, &amp;sse4Foo, &quot;bar&quot;, &a= mp;sse4Bar);<br> __gshared typeof(SSE2)* _impl;<br> <br> shared static this()<br> {<br> =C2=A0 if (sse4)<br> =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0_impl =3D &amp;SSE4;<br> =C2=A0 }<br> =C2=A0 else if (sse2)<br> =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0_impl =3D &amp;SSE2;<br> =C2=A0 }<br> =C2=A0 else<br> =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0_impl =3D &amp;Native;<br> =C2=A0 }<br> }<br> <br> _impl.foo(args);<br> </blockquote></div><br><div>Function pointers are super-slow on some archit= ectures. I don&#39;t think it&#39;s a particularly good solution unless the= functions you&#39;re calling do a lot of work.</div> --20cf30051342cc3dfa04b6287c24--
Jan 10 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 Function pointers are super-slow on some architectures. I don't think  
 it's
 a particularly good solution unless the functions you're calling do a lot
 of work.

such things at compile time. Alternative approaches are distributing multiple executables or using template parameterization of whole engines.
Jan 10 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 7 January 2012 22:31, Manu <turkeyman gmail.com> wrote:
 On 7 January 2012 22:44, Piotr Szturmaj <bncrbme jadamspam.pl> wrote:
 The idea is to make versions of code that are environment dependent and
 never change during runtime, _without_ resorting to if statements. This
 statement would be valid only inside function bodies.

 Examples of such versions may be:
 * supported SIMD CPU extensions MMX, SSE, SSE2, etc.
 * AMD vs Intel CPU, to use instructions that are not available on both
 * different OS versions (XP/Vista/7, Linux kernel versions)

 Why that instead of current if statement?
 * some additional speed, avoids multiple checks in frequent operations
 * making specific executables (f.i. SSE4 only) by limiting set of
 supported runtime options during compile time

 Code example:

 void main()
 {
 =A0 =A0version(rt_SSE4)
 =A0 =A0{
 =A0 =A0 =A0 =A0...
 =A0 =A0}
 =A0 =A0else version(rt_SSE2)
 =A0 =A0{
 =A0 =A0 =A0 =A0...
 =A0 =A0}
 =A0 =A0else
 =A0 =A0{
 =A0 =A0 =A0 =A0// portable code
 =A0 =A0}
 }

 In this example program checks the supported extensions only once, befor=


 calling main(). Then it modifies the function code to make it execute on=


 versions that match.

 Runtime version identifiers may be set inside shared static constructors
 of modules (this implies that rt-version may not be used inside of them)=


 SIMD extensions would preferably be set by druntime with help of core.cp=


 Code modification mechanism is up to implementation. One that come to my
 mind is inserting unconditional jumps by the compiler then and fixing th=


 up before calling main().

 Additional advantage is possibility to generate executables for particul=


 environments. This may help reduce execucutable size when targeting spec=


 CPU, especially some constrained/embedded system. Also many cpuid checks
 inside druntime may be avoided.

 Just thinking loud :)

... you could just use if() ? Perhaps detection of these features could be added to the standard librar=

 But I have a feeling it already IS actually (core.cpuid, something I am
 extremely cynical of)

This. If you want CPU detection at runtime, you need to write your own assembly or use core.cpuid. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Jan 10 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 10 January 2012 09:42, Martin Nowak <dawg dawgfoto.de> wrote:
 Function pointers are super-slow on some architectures. I don't think it's
 a particularly good solution unless the functions you're calling do a lot
 of work.

If you're working on very specific platforms you can likely determine such things at compile time. Alternative approaches are distributing multiple executables or using template parameterization of whole engines.

I did have GDC hooked up to the C pre-processor macros, which defined a lot of target-specific identifiers (GNU_SSE, GNU_SSE2, etc) depending on the default target flags, and what extra target flags you passed to the compiler - but was dropped because of growing number of stub dependencies it incurred, and the fact that most macros were about as useful as marmite sundae. I would be certainly up for addressing this in a pragmatic way though. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 10 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
You could make use of shared library filters where
you link against a native implementation. During installation
you can then provide specialized implementations.
Jan 11 2012