>Kevin Kofler wrote:
>>Dave Love wrote:
>> As far as I can tell, it doesn't do dynamic dispatch. Experimentally,
>> if you build with -mavx2 and run on ivybridge (or for skx and run on
>> haswell), the test code generates illegal instruction errors. It's some
>> time ago since I looked at it, and I don't remember, but that's probably
>> why I thought it wasn't very useful, apart from only having x86 and arm
>> support.
>
>That's because it is a header-only library. It is either hard (and non-
>portable) or impossible to do dynamic dispatch in a header-only library,
>depending on the compiler and compiler version. (At least in past GCC
>versions, it was impossible. This may or may not have improved since.)
>Hence, dynamic dispatch, if desired, is left to the client application. And
>I agree that this makes the library mostly useless.
>>Dave Love wrote:
>> As far as I can tell, it doesn't do dynamic dispatch. Experimentally,
>> if you build with -mavx2 and run on ivybridge (or for skx and run on
>> haswell), the test code generates illegal instruction errors. It's some
>> time ago since I looked at it, and I don't remember, but that's probably
>> why I thought it wasn't very useful, apart from only having x86 and arm
>> support.
>
>That's because it is a header-only library. It is either hard (and non-
>portable) or impossible to do dynamic dispatch in a header-only library,
>depending on the compiler and compiler version. (At least in past GCC
>versions, it was impossible. This may or may not have improved since.)
>Hence, dynamic dispatch, if desired, is left to the client application. And
>I agree that this makes the library mostly useless.
Less useful then we would like. But could be part of the larger solution. Properly structured they could help (not impede) building shared objects with multiple implementations and dynamic selection for vector codes.
>You need an actual shared object with actual functions to do dynamic
>dispatch nicely and transparently.
I think the problem is lack of good documentation and examples. And perhaps motivation. GLIBC has been doing this some time, but at the time is was hard and difficult. But the compiler and runtime infrastructure has improved since. Perhaps we can make this simple enough for wide application to higher level libraries.
I am finding for the implementation of pveclib, that vector multiple quadword (128-bit) precision multiplies are large enough, that you don't want to expanded them in-line. But the vector multiply quadword itself and the operations that implement it can and should be inline (for ppc64le). So I was forced to cross that boundary.
Give me some time and I will have a documentation/examples that might general useful.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
