Hi Kyle -- On Wed, 30 Apr 2014, Kyle Brady wrote:
> 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, ...) This isn't an issue specific to the runtime, though, is it? Rather, it's any code compiled for the target processor. That includes the runtime (when building the runtime) and the C code produced by the Chapel compiler (when building user programs). Thos other CHPL_RT_* environment variables parameterize the behavior of the runtime specifically. greg >> 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
