{perf}[GCCcore/12.3.0] PAPI v7.1.0

[satishskamath]

(created using eb --new-pr)

[satishskamath]

icl-utk-edu/papi#160 reported by @Flamefire

[Flamefire]

Additionally there already is a PAPI EC for 12.3.0

[satishskamath]

@Flamefire we wanted support for zen4 arch as well which only comes with 7.1.0 . So not sure how you would like me to name this PR or for a higher release of GCCcore?

[Flamefire]

I see. The general approach, at least for the ECs of this official repo, is to have exactly 1 software version per toolchain to avoid conflicts (aka dependency hell)
We already have ECs (and hence someone likely has modules) using PAPI 7.0.1 with GCC 12.3 so adding PAPI 7.1 and ECs/modules depending on it will lead to issues when loading a module that depends on 7.0.1 and one that depends on 7.1

That just for explanation. From what I can see there currently is no PAPI for 13.1 or 13.2 so you could add that for this toolchain. Although we'll have trouble at our site installing this as the test will fail.

[casparvl]

You're close, but not quite: we have no restrictions on having versions of a software in a given toolchain. E.g. having two GROMACS versions in the same toolchain is totally fine. So in that sense, this PR is totally fine.

What we do not allow (at least not by default) is using multiple different versions of a software as a dependency. Our CI also checks for this, and fails if you try to do this. We do make exceptions if there are good reasons: sometimes, your software just needs a newer version of a dependency, because it will not work otherwise. Other justified reasons for using a second dependency version is if there is a proven/substantial performance benefit. In those cases, the PR that contributes an EasyConfig that depends on a 2nd version has to also include an exception for the CI tests, to make those pass. See e.g. here. I'd say the fact that 7.0.1 doesn't work for zen4 would also be a good enough reason.

It should all be seen in the context of why we try to avoid this: if software A and B both depend on C, but on different versions, you cannot load A and B at the same time. PAPI is basically only used in the POP tools, and as far as I can tell, only in Score-P. We currently have a Score-P-8.1-gompi-2023a.eb that depends on PAPI 7.0.1. You'd never want to (or could) load Score-P-8.1 and the 8.3 from #19524 at the same time anyway. So, the fact that these depend on different PAPI versions is no problem at all and the zen4 support in PAPI 7.1.0 would be good enough reason for me as reviewer to make this exception.

One caveat here is that from this I understand that 7.1.0 didn't work for @Flamefire on a particular zen2-model CPU (EPYC 7352). It did work for a zen2 model in @satishskamath 's system and the PAPI devs also weren't able to replicate it. That makes it tricky: whatever we pick, there'll always be someone for whom it doesn't work :\ I'd still vote for using 7.1.0 since with 7.0.1 we know it will not work for any zen4, whereas with 7.1.0 we know it will not work for some zen2's... If you really wanted to, we could even add both and suffix the Score-P with the PAPI version used.

Then again: I'm not the most independent reviewer here, since Satish and I are both at the same company :) I'll ping on the maintainers chat for an second opinion ;-)

[satishskamath]

@Flamefire and @casparvl I have added the file for GCCcore 13.2 But is it okay to add the same versions of rest of perf analysis tools for toolchain of 13.2? I don't think that is a sustainable idea.

[verdurin]

@satishskamath could you explain a bit more please? Not sure I follow.

[satishskamath]

@verdurin I am only upgrading PAPI to 7.1.0 which is a dependency and the major versions of rest of the software are the same as #19524 . I was not sure if it is okay if I submit the same versions for 13.2.0 toolchain as well.

[satishskamath]

I think this can be closed since @Flamefire has already pushed for PAPI 7.1.0 in 13.2.0 which I did here as well.

[Flamefire]

Ah yes, I added it as part of a larger PR including Score-P and forgot about that. I've seen the issue (in the test) pop up randomly there too but not in the test report where it happened to succeed.