Hi Greg, > (what's "RT" there, anyway?)
Runtime, 'CHPL_RT_' is the prefix we use for the other runtime specific environment variables (CHPL_RT_NUM_THREADS_PER_LOCALE, ...) > So one could consider CHPL_TARGET_PLATFORM something like a noun and >CHPL_RT_ARCH something like an adjective? They are actually a bit more orthogonal than that. CHPL_TARGET_PLATFORM is more along the lines of what operating system you are using, while CHPL_RT_ARCH would be what processor you have in that machine. > Whatever we do needs to pay attention to CHPL_TARGET_COMPILER... This is very true, each compiler will need it's own tweaks and attention. If I was reading an email from last week correctly, I think that for at least PrgEnv-cray we wouldn't set anything. Thanks, -Kyle On 4/30/14, 3:47 PM, "Greg Titus" <[email protected]> wrote: >Hi Kyle -- > >Just some quick thoughts ... > >We already have CHPL_TARGET_PLATFORM. Is CHPL_RT_ARCH (what's "RT" >there, anyway?) intended as an adjunct to that? So one could consider >CHPL_TARGET_PLATFORM something like a noun and CHPL_RT_ARCH something >like an adjective? > >Whatever we do needs to pay attention to CHPL_TARGET_COMPILER. If we >have CHPL_TARGET_COMPILER=cray-prgenv-*, for example, we need to limit >what things people can do with an environment variable, because if we >don't we can find ourselves in conflict with the other PrgEnv* module >settings that have to do with ISA, etc. > >greg > > >On Wed, 30 Apr 2014, 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
