Dear Jack and Kenneth Just a quick thanks for your input on the issue, highly appreciated. This is to say I noticed your input and I intend to get back to it soon, but I lost a lot of time last week due to “sick child” that I have to extinguish the fires that created before I can get back to this.
Do I understand Kennet correctly, he has now done a Perl in GCCcore 6.4.0? If so where is it (e.g. GitHub PR)? Best wishes Joachim > On 15 Sep 2017, at 15:19, Jack Perdue <j-per...@tamu.edu> wrote: > > On 09/15/2017 07:21 AM, Kenneth Hoste wrote: >> Dear Joachim, >> >> On 08/09/2017 19:12, Joachim Hein wrote: >>> Hi >>> >>> For building git, it seems I require Perl. I think git would sit nicely in >>> GCCcore (instead of foss/intel). Is there a reason why the new Perl 5.26.0 >>> sits in intel/2017b or foss/2017b instead of GCCcore 6.4.0? >>> >>> I assume if I build a Perl in GCCcore for git I get nice conflicts with >>> anything loaded simulaneously taking it out of foss/intel at runtime? >> >> Up until now, we've usually been installing Perl at the foss/intel level >> (unless we needed it as a build dep for something built with GCCcore). >> >> This has sort of grown historically (we've always been doing it like that at >> HPC-UGent), the main motivation being is that we tend to compile all >> end-user applications with Intel compilers (I also included the 'foss' >> equivalent for Perl 5.26.0 since it was dead-easy to do so). >> >> I have to admit I never really benchmarked whether it's necessary to build >> Perl with Intel compilers for better performance, I just assumed it would be >> beneficial. >> >> Yesterday I did a quick benchmarking session using the Perl-Formance package >> [1], and I ran into some surprising results: the Perl that was built on top >> of GCCcore was significantly faster than the same installation done with >> intel/2017b... >> >> For several of the tests included in Perl-Formance, I saw 10-15% *longer* >> runtimes with Perl/5.26.0-intel-2017b compared to using >> Perl/5.26.0-GCCcore-6.4.0; >> for one test, there even was a ~40% difference, but only on one of two >> systems I tested on (Sandy Bridge, not observed on Haswell). >> >> So, I shouldn't have made the assumption that compiling with Intel compilers >> yields better performance, I should have checked. >> Disclaimer: these results may be specific to the benchmark tests used, and >> the versions of Perl and the compilers, the conclusion may change over >> time... >> >> Long story short: >> https://github.com/easybuilders/easybuild-easyconfigs/pull/5126 >> >> To answer your questions w.r.t. conflicts: since Perl is only a build >> dependency for git, you shouldn't run into conflicts on Perl when combining >> git with something else that was built including Perl built with intel >> toolchain as a dependency. >> >> >> regards, >> >> Kenneth >> >> [1] >> https://metacpan.org/pod/distribution/Benchmark-Perl-Formance/bin/benchmark-perlformance > > Howdy Joachim, > > > Thank you for your message and the resulting PR#5126. > I keep kicking the guys at UGhent to think about --minimal-toolchains > but they are kinda sick of the bruised shins. :) > > Glad to have someone else to help. > > Personally I think GCC does a pretty good job in most cases. > Certain maths might benefit from Intel-only vector math and what not > but the benefit of having things based on GCCcore seems to outweigh them. > > The more we can demote things down to GCCcore (or iompi/fompi/iimpi) the > better. > > Jack Perdue > Lead Systems Administrator > High Performance Research Computing > TAMU Division of Research > j-per...@tamu.edu http://hprc.tamu.edu > HPRC Helpdesk: h...@hprc.tamu.edu > > >
