Thanks for the replies. Below, I am merging responses to both Henry and Raul, since they sort of relate:
Henry Rich <[email protected]> wrote: > The problem with remapping the functions is that then you have to have > all the different functions co-resident, which means that you have to > tell the compiler that it knows AVX2, and then it is liable to use AVX2 > instructions all over the place, so you can't run on non-AVX machines > anyway. Different compilers have different approaches to this. Certainly. There are a couple approaches to solving this that I am aware of. The "dumb" one is to simply have different translation units and compile each with different flags/pragmas. More generally, though, GCC and Clang let you set target-specific options on arbitrary blocks of code by pushing and poping them with the appropriate pragmas. On 10/7/2020 8:26 AM, Raul Miller wrote: > There's https://github.com/google/cpu_features > > But probably this issue would be better dealt with in a script than in > libj. You can include a libj-avx and a libj-noavx and symlink the > appropriate one or use secondary packages or rename one libj and > delete the other or any of a variety of other techniques, depending on > what seems best for the distro in question. > > (And of course if you're on linux you can look in /proc/cpuinfo to > determine whether avx is supported.) Thanks. Maybe I wasn't clear in my original email, but this is already a solved problem for the distros that I maintain the J package for. Like you first suggest, we just have a script that scrabes /proc/cpuinfo and loads jconsole with the appropriate libj.so. > Part of the reason I am thinking this is that the parts of the code where > this decision needs to be made tends to be performance critical, so it's best > to make the decision once, ahead of time. Certainly. The main idea here is to setup a jump table exactly once at initialization. In spirit, it would be doing the same thing a script does, but transparently. Anyway, I vaguely recall watching a Dyalog talk that mentioned them dong some avx-detection stuff at startup. This is something that definitely exists in the wild, and I have (very lightly) worked with this kind of code. My main point being, there really shouldn't be any technical barries to merging the avx libraries; however, how does the calculus come out when including the other concerns you devs deal with: maintenance, backward-compatibility, etc. etc? ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
