Hi,

I would side closer to Damian and Kenneth, ie. play a bit conservative, as 
regards the common gcc compiler version.
IMHO, the difference in community opinion among GCC/4* or GCC/5 relates more to 
if you are *supporter* or *supported*.
Let’s remind here why easyconfigs are called “examples” as opposed to 
“solutions” for HPC systems!

When you deal with many users, you need to provide an environment suitable for 
multiple domains, exploiting your limited/finite time.
Compatibility issues among multiple tools such as Intel, CUDA, Matlab, PGI and 
open source components, inevitably imply 
a lesser common denominator. Shop your arguments from the URLs here: 
https://github.com/hpcugent/easybuild-easyconfigs/pull/1294

fi.
If you are into Life Sciences and you do narrow MD experiments, you have good 
reasons to stretch versions to greatest and latest;
however, if you require a compatibility layer with the bioinformaticians next 
door, that makes it a tad more constrained.


>From my point of view, the following dep chain must be fully supported by 
>upstream paths or, the generic toolchains are failing:
(Python, Boost, Perl) -> Intel compilers -> GCC ; allowing CUDA in the mix is a 
bonus, for Molecular Dynamics intentions.
There is loose affinity here with Common Deps list: 
https://github.com/hpcugent/easybuild-easyconfigs/issues/1689

My own litmus test often is a variant of 
HPCBIOS_LifeSciences-20130829-goolf-1.4.10.eb & a Perl that keeps other builds 
happy;
an equivalent symmetric set of builds against some recent Intel toolchain, 
would be convincing: it is centrally supportable and, 
sufficiently advanced for further experimentation on the user-end (we should 
never claim fitness, rather a working skeleton!).

F.

On Jan 13, 2016, at 10:17 AM, Damian Alvarez <[email protected]> wrote:
> Another thing to consider might be CUDA. CUDA 7.5 requires GCC >4.3.4 && 
> <4.9.2 (even though with 4.9.3 works fine). It seems you can make it work (at 
> your own risk) with 5.X as long as you don't use C++11. However, that means 
> that CUDA+C++11 developers will have troubles (i.e.: won't work) in 
> EB-managed environments if we go for GCC 5.X.
> 
> PGI-based toolchains might also require GCC <5.X, but I am not sure about 
> that, the documentation is not clear on that regard.
> 
> I'd suggest to at least keep GCCcore as 4.9.3. With just GCCcore being 4.9.3, 
> the foss toolchain (with GCC 5.X) will be problematic for CUDA usage, but not 
> so the Intel toolchain.

-- 
echo "sysadmin know better bash than english" | sed s/min/mins/ \
  | sed 's/better bash/bash better/' # signal detected in a CERN forum






Reply via email to