> On 19 Sep 2017, at 16:10, Joachim Hein <[email protected]> wrote:
>
> 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)?
>
Found it, already merged into develop. That makes my live easier.
Thanks
Joachim
> Best wishes
> Joachim
>
>> On 15 Sep 2017, at 15:19, Jack Perdue <[email protected]> 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
>> [email protected] http://hprc.tamu.edu
>> HPRC Helpdesk: [email protected]
>>
>>
>>
>
