SSE2 and SEE4.2 acceleration should be decided at runtime instead of compile time

[GoogleCodeExporter]

If I enable SSE4.2 acceleration on a machine that doesn't support SSE4.2, 
compile and run it, an exception will occur.

It would be preferable if the decision to use SSE2 or SSE4.2 was decided at 
runtime, so that a single executable could be run on a variety of machines 
(some without SSE2 and SSE4.2, some without SSE4.2 and some with SSE4.2), and 
the code would always use the fastest option available.

You could still have preprocessor constants to enable SSE2 or SSE4.2, but at 
runtime, it will always try to use the fastest available code path.

Original issue reported on code.google.com by keith3...@rocketmail.com on 21 Jan 2013 at 11:38

[GoogleCodeExporter]

You can find code for detecting processor support for SSE here:

http://stackoverflow.com/questions/6121792/how-to-programmically-check-if-a-cpu-
supports-sse3/7495023#7495023

Original comment by keith3...@rocketmail.com on 22 Jan 2013 at 1:25

[GoogleCodeExporter]

The link I gave is only for Windows. The following link includes cpuid code 
that apparently works on Windows, Mac and Linux

http://stackoverflow.com/questions/1666093/cpuid-implementations-in-c/4823889#48
23889

Original comment by keith3...@rocketmail.com on 22 Jan 2013 at 1:49

[GoogleCodeExporter]

I think this would really hurt auto-inlining.

Original comment by vaddi...@gmail.com on 21 Mar 2013 at 1:55

[GoogleCodeExporter]

What do you mean?

Could be implemented as construction of a struct in an unnamed namespace:

namespace
{
  cpuinfo = getcpuinfo();
}

Or maybe as a simple const variable in the main namespace (I don't know the 
current design in the project but I will look into this if I have time, maybe 
post a pull request). It won't have any more overhead than a simple if (no 
wrong branch predictions since the values won't change I assume).

Original comment by fasdfas...@gmail.com on 23 Jul 2013 at 9:17

[GoogleCodeExporter]

I just noticed the project is dead, the maintainer is on the wind, is that 
right?

Original comment by fasdfas...@gmail.com on 23 Jul 2013 at 9:20

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This will not be implemented due to the following reason:
* runtime overhead (e.g. function pointer, unable to inline)
* Issue #104 causes that user may need to add paddings if using SIMD 
acceleration on some platforms.

Original comment by milo...@gmail.com on 30 Jun 2014 at 10:13

• Changed state: WontFix
• Added labels: Type-Enhancement
• Removed labels: Type-Defect