Hi, thanks for the prompt replies.
On Tue, Jan 15, 2013 at 2:09 PM, Kenneth Hoste <[email protected]> wrote: > Like Stijn mentioned, usually you really don't want to use the system > compilers/libraries, and an OS update might breaks all the built software > (sometimes in very subtle ways). You can get around it and define a > non-dummy toolchain that basically just uses the system stuff, but you > probably don't want to (although you may not realize that yet ;-)). > > Can you clarify why you want to use the system compilers/libs? Is it just to > avoid needing to build a full toolchain stack? Well, that was just an idea that we're exploring - I'm still not sure about it. However: - 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. - 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. - 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). - 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. But as I said, the whole idea is more a feeling than a strong opinion, so do not bash me about it :-) Thanks, Riccardo
