Hi Greg, That is true, we want any of our C code to be compiled with these flags. CHPL_TARGET_ARCH and CHPL_TARGET_FEATURES may be better names.
-Kyle On 5/2/14, 3:04 PM, "Greg Titus" <[email protected]> wrote: >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
