Hi Craig -
I don't think --specialize makes any sense in combination
with CHPL_TARGET_ARCH=unknown. The combination is
asking for optimization specific to a target architecture,
but the target architecture isn't specified.
You already should get optimization to a least-common-denominator
architecture (e.g. the minimum x86-64 CPU sold)
with just --fast and CHPL_TARGET_ARCH=unknown.
If your environment has multiple processor types and you'd
like to build Chapel for all of them, you might be able to:
1. Concurrently install Chapel to the same directory for the
different relevant settings of CHPL_TARGET_ARCH. This
should populate the runtime sub-directories for the
appropriate CHPL_TARGET_ARCH.
2. Build Chapel for a minimum processor type of your users,
e.g. CHPL_TARGET_ARCH=sandybridge
and then have people using your installation of Chapel
also set CHPL_TARGET_ARCH=sandybridge. Note that this
could happen in a setup script or potentially in a chplconfig file.
(It might even work for that chplconfig file to be in
the installed $CHPL_HOME directory but I havn't tried that yet;
it ought to be saved in a chplconfig when you configure...).
Cheers,
-michael
I'm having some issues with our Chapel installation and being able to
--fast/--specialize.
I build our installation with "unknown" (anticipating a
least-common-denominator) architecture.
Our installation is then NFS mounted on different hosts (with
architectures like sandybridge, ivybridge, haswell, etc...) This all
works fine until someone cares about performance. Once you try to use
--fast/--specialize it looks like chapel expects to have been built for
the special-ized architecture.
[cfreese@ucs1l play]$ chpl -o acpy acpy.chpl
[cfreese@ucs1l play]$ chpl --specialize -o acpy acpy.chpl
warning: --specialize was set, but CHPL_TARGET_ARCH is 'unknown'. If you
want any specialization to occur please set CHPL_TARGET_ARCH to a proper
value.
[cfreese@ucs1l play]$ setenv CHPL_TARGET_ARCH sandybridge
[cfreese@ucs1l play]$ chpl --specialize -o acpy acpy.chpl
/opt/chapel-1.17.1/third-party/gasnet/Makefile.setup:6:
/opt/chapel-1.17.1/third-party/gasnet/install/linux64-gnu-sandybridge/substrate-smp/seg-fast/nodbg/include/smp-conduit/smp-par.mak:
No such file or directory
gmake: *** No rule to make target
`/opt/chapel-1.17.1/third-party/gasnet/install/linux64-gnu-sandybridge/substrate-smp/seg-fast/nodbg/include/smp-conduit/smp-par.mak'.
Stop.
error: compiling generated source
I tried faking it out by making a link .../linux64-gnu-sandybridge ->
.../linux64-gnu-unknown (which isn't ideal but also isn't a completely
stupid work around). That seems to placate gasnet but then chapel seems
to choke on the runtime:
[cfreese@ucs1l play]$ chpl --specialize -o acpy acpy.chpl
/opt/chapel-1.17.1/runtime/etc/Makefile.include:149: *** The runtime has
not been built for this configuration. Check
$CHPL_HOME/util/printchplenv and try rebuilding with 'gmake' from
$CHPL_HOME. Stop.
error: compiling generated source
So, what am I missing? Is there a correct way to handle being able to
compile for multiple architectures from a single chapel installation or
do I need to build a separate version for each?
Craig
P.S. for extra credit one can ponder the effects for building/using
chapel with architecture = "native" ;^)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
