Hi -
I'm not convinced it's as bad as you say.
For one thing, it appears that -msse3 and similar flags
are in both gcc int icc. And then, it seems to me (from
documentation) that the following options work
across icc and gcc for -march= :
pentium3 (2000)
pentium4 (2002)
core2 (2006)
corei7 (2008) (GCC 4.6)
corei7-avx (2011) "2nd Generation Core i7" (GCC 4.6)
core-avx-i (2012) "3rd Generation Core i7"
core-avx2 (2013) "4th Generation Core i7/Haswell" (GCC 4.7)
Somebody else could make the corresponding chart for AMD,
PowerPC, or whatever else...
So things don't look that bad for Intel processors to me...
So - I think we should:
- create a configuration variable as you say, as a backup plan,
and also insist on its setting when cross-compiling
- find a way to detect cross-compilation and default to -march=native
if not cross-compiling
- consider defaulting toa more recent flag if we know it's Intel
(a script can check /proc/cpuinfo for Intel...)
Cheers,
-michael
On 04/30/2014 06:13 PM, Kyle Brady wrote:
> Hi all,
>
> While I was working on the BitOps library, I noticed that using compiler
> intrinsics wasn't actually giving a performance increase. In fact, some
> compiler's intrinsics would actually perform worse than my versions of the
> operations that were plain C. The problem boils down to that unless you
> tell the compiler to optimize for a specific architecture or instruction
> set it assumes that those instructions are not available for use.
>
> The easy way to tell the compiler (gcc/clang/intel) about these featuers
> is by setting '-march=native' when compiling [0]. This tells the compiler
> to detect and use any features available in the host processor, but it
> creates a non-portable binary. The problem with that is we cross-compile
> often. Beyond 'native' there are a large number of processor
> architectures available for -march. There are also flags to enable support
> for a specific instruction sets in the form of the -msse, -msse2, -mavx
> and several others.
>
>
> So we need some way to specify the minimum feature set for compilation. To
> complicate things further, we'd like to use these settings while compiling
> the runtime. In addition, even though -march=native is shared across
> intel, clang, and gcc, for anything other than 'native' intel uses
> different values than clang/gcc. The values gcc uses vary from version to
> version as well.
>
> All of this together means that we probably have to add an user
> configurable setting along the lines of 'CHPL_RT_ARCH' and/or
> 'CHPL_RT_INSTRUCTION_SETS' and provide no default value. An alternative
> would be to use -march=native when nothing has been given, unless we are
> in a known cross-compilation setting (PrgEnv-*).
>
> So that is the gist of it. Does anyone have thoughts or preferences on
> this?
>
> Thanks,
>
> -Kyle
>
> [0] For a good overview on these settings see:
> https://wiki.gentoo.org/wiki/GCC_optimization#The_basics
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Chapel-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chapel-developers
>
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Chapel-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-developers
