[WIP] Add likwid 5.2.1 #4913
[WIP] Add likwid 5.2.1 #4913
Conversation
|
Patch tends to be more stable since it will fail if it couldn't apply it. Ideally you would be reusing HWLoc_jll instead of building it again, same with lua |
|
@carstenbauer: The I never tried building LIKWID with musl. For building with external hwloc and lua, check spack's LIKWID package. |
Yes, indeed, just forgot to put it on the Todo list. |
@TomTheBear Can you elaborate a bit more, i.e. where should I add it exactly? I tried setting it in |
If you add it to the |
|
@TomTheBear That's what I did (and it works in the sense that you describe) but I still get Do I need to put it somewhere else as well? |
sandbox:${WORKSPACE} # echo '#include <features.h>' | cc -dM -E - | grep -E '#define __GLIBC_(|MINOR_)_'
#define __GLIBC__ 2
#define __GLIBC_MINOR__ 12is probably more cross-compilation friendly than running Related to the topic of cross-compilation, we looked into building likwid some time ago, but I remember it wasn't really possible to do a cross-build because the package needed some information about the target system at compile time, or some local kernel modules, or something like that. Is this still the case? |
It seems like likwid still installs Before After I see that they apply a patch in the easyconfig that addresses this. @TomTheBear Why isn't the easyconfig patch the default? I.e., is there a deeper reason for the creation of |
|
The script |
Yeah. That's certainly unfortunate. But the |
Co-authored-by: Mosè Giordano <[email protected]>
It'd be nice to build for all Linux platforms, if possible (at least glibc ones, if that's a requirement). I'm thinking in particular of aarch64 and powerpc64le, which are more popular in HPC settings. |
@carstenbauer: I test LIKWID only in the default configuration varying important options ( |
@giordano This can be avoided by getting the script path in the beginning. It's just Lua. Patch it if you need it differently. Until now, Yggdrasil seems to be the only package manager having problems with absolute paths. |
This is the only sensible thing given that Yggdrasil
The last point might be the most important of all. |
While true, that's a Julia / Yggdrasil perspective. A tool (like likwid) may not care about what Yggdrasil wants / needs. It's a tedious task to cater to the specific needs of various package managers so we can't expect non-Julia developers to spend much time on it. We can hope though 😉 Fortunately, in this case, @TomTheBear has already committed a few simple patches to likwid so that from version 5.2.2 on
Thanks for this! ❤️ |
Absolutely, I just wanted to explain the perspective of Julia/Yggdrasil, not to rant about the projects that don't do it, or ask for every project to do it. I'm sorry if my comment read otherwise. 😅
Thanks, @TomTheBear! That sounds incredible. 🎉 |
PowerPC aarch64 i686 |
if [[ "${target}" == powerpc64le-linux-* ]]; then
COMPILER=GCCPOWER
elif [[ "${target}" == aarch64-linux-* ]]; then
COMPILER=GCCARMv8
else # assume x86_64
COMPILER=GCC
fi |
|
FYI: I'll wait until the next likwid release before continuing on this. |
There was a problem hiding this comment.
Is this good to go now? I'm not sure how this is going to work though, the package hardcodes build-time paths, which makes it non-relocatable
% x86_64-linux-gnu/bin/likwid-features
zsh: x86_64-linux-gnu/bin/likwid-features: bad interpreter: /workspace/destdir/bin/lua: no such file or directory
% lua x86_64-linux-gnu/bin/likwid-features
lua: x86_64-linux-gnu/bin/likwid-features:33: module 'likwid' not found:
no field package.preload['likwid']
no file '/workspace/destdir/share/lua/likwid.lua'
no file '/usr/share/lua/5.4/likwid.lua'
no file '/usr/share/lua/5.4/likwid/init.lua'
no file '/usr/lib/lua/5.4/likwid.lua'
no file '/usr/lib/lua/5.4/likwid/init.lua'
no file './likwid.lua'
no file './likwid/init.lua'
no file '/usr/lib/lua/5.4/likwid.so'
no file '/usr/lib/lua/5.4/loadall.so'
no file './likwid.so'
stack traceback:
[C]: in function 'require'
x86_64-linux-gnu/bin/likwid-features:33: in main chunk
[C]: in ?
|
I'm in the progress of making LIKWID relocatable but it's not finished yet: RRZE-HPC/likwid#480 |
No it's not (for the reasons you mentioned). Just wanted to push it a bit closer to the finish line. |
Co-authored-by: Mosè Giordano <[email protected]>
Co-authored-by: Mosè Giordano <[email protected]>
|
This would be an awesome feature to have. Looking forward to the progress that @TomTheBear can make on this. |
|
This is not an easy task. LIKWID consists of multiple files (misc Lua functions, C library, performance group files, benchmark files, accessdaemon, ...) that need to be found at runtime and interact with each other (e.g. UNIX socket communication). |
This is my attempt to provide a basic configuration of LIKWID, in particular the library
liblikwid, via BinaryBuilder (JuliaPerf/LIKWID.jl#24). The plan is to later use this as a fallback in LIKWID.jl (if there is no system-wide likwid available).TODOs:
ldd: --versionissues (as much as possible)Potential TODOs:
likwid-topology,likwid-perfctr, etc.) asFileProducts-> difficult due to absolute pathsQuestions / Remarks:
config.mk, I've opted for threesedcommands. (Should I use a patch instead? What would be the advantage / disadvantage?)makelog:Note the
bits. Should I care about those given that the build process seems to proceed just fine?
(@TomTheBear, @Suavesito-Olimpiada FYI)