- the system toolchain has a much wider community of users and
vendor/upstream support. I see this as an advantage because bugs in
Ubuntu's GCC or ATLAS packages would have probably already spotted
by someone else. With a custom-compiled toolchain (or a "completely
isolated HPC environment" as Fotis put it), more support activity is
on our shoulders as the user community is basically restricted to
the local users.
The bottom question here is if you prefer to ride on a given distribution's
support channels or, rather pick scientific computing communities as that;
if you want to use the ubuntu gcc source (ie gcc with patches), you can
also use that with easybuild.
In our case, the constraint was debuggers and wider software compatibility,
discussed some here: https://github.com/hpcugent/easybuild-framework/issues/400
btw. IMHO, even if a team only does HTC (as opposed to HPC), eventually this
kind of discussion will pop-up, because upgrading your compiler toolchain
in effect "increases" your resources (gcc 4.4 vs 4.6, gcc vs icc etc).
- Ubuntu and Debian do not upgrade the compiler in stable releases,
exactly for the point Stijn and you mentioned: almost every piece of
a GNU/Linux system can be broken by a mad upgrade of the compiler,
not just HPC software.
i don't understand this. i find it hard to believe that they don't fix
bugs (or are you using 'do not upgrade' like rhel "never" upgrades eg
their kernel)
As of Jan. 2013 I think the "center of gravity" in gnu compilers is ~ v4.6.1-2;
If you make a compromise on an earlier version you may lose performance and,
on a later version you may lose compatibility (very generic statement, it can
be shot)
with easybuild the choice is to the users, you can provide a default,
but it all about what the user wants imho.
- our cluster is heterogeneous: ATLAS built on one node might not be
compatible with other nodes. With the system packages, this won't
happen (at the price of performance drop, but see next point).
ATLAS coming from system packages just reinforces this argument:
now your heterogeneity includes the package builder's system architecture :)
ATLAS gives headaches for 2 reasons, the one just stated and also
difficulties in running it under Virtual Machines.
Kenneth stated at some point that a future toolchain may be "goolf",
where the 3rd letter stands for OpenBLAS, an apparent spin-off of GotoBLAS.
I think going in that direction could remove plenty of the current issues.
(but hey, it may be best to prefer v4.6.x + openblas?)
+1
stijn
- the cluster is mainly for HTC usage rather than HPC. In practice
this means we're less concerned with raw performance and more with
the robustness of the system in processing a large number of jobs.
My definition of robustness is to favor versions that can be deployed
for the longest possible time span (5+ years). Your take? :)
I guess you want to ride on Ubuntu/12.04LTS: https://wiki.ubuntu.com/LTS
But as I said, the whole idea is more a feeling than a strong opinion,
so do not bash me about it :-)
The more people that come around easybuild, the more experience we pool;
it's good if everybody throws his technical arguments so that we can
shop from the ones that apply for each team's case...
On 16 Jan, 2013, at 12:12, Riccardo Murri wrote:
- A way to stack search paths for '*.eb' so that local `*.eb` files
override distributed ones. (Sorry I didn't look carefully into the
documentation, so maybe it's already present.)
Not yet. The following two issues are relevant, especially the first one:
https://github.com/hpcugent/easybuild-framework/issues/211 # easyconfigs
https://github.com/hpcugent/easybuild-framework/issues/119 # easyblocks
I recall there are some open issues as regards patches, if you need those
better you search the list of issues on github to prevent debugging in vain.
enjoy,
Fotis
