Ciao Riccardo et al, On 16 Jan, 2013, at 11:58, Riccardo Murri wrote: > - 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; 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. 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) > - 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?) > - 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
