3 ms·
Our answer to this - is dynamic dispatch. If you want to have multiple version of the same kernel compiled - compile multiple dlls. The big problem here is: OD
by dyaroshev 2y ago
Our answer to this - is dynamic dispatch.
If you want to have multiple version of the same kernel compiled - compile multiple dlls.
The big problem here is: ODR violations.
We really didn't want to do the xsimd thing of forcing the user to pass an arch everywhere.
Also that kinda defeats the purpose of "simd portability" - any code with avx2 can't work for an arm platform.
eve just works everywhere.
Example: https://godbolt.org/z/bEGd7Tnb3 https://godbolt.org/z/bEGd7Tnb3
- janwas 2y agoIt is possible to avoid ODR violations :) We put the per-target code into unique namespaces, and export a function pointer to them.
- dyaroshev 2y agoYou can do many thing with macros and inline namespaces but I believe they run into problems when modules come into play. Can you compile the same code twice, with different flags with modules?
- janwas 2y agoWe use pragma target instead of compiler flags :)
- dyaroshev 2y agoI don't think we understand each other. We want to take one function and compile it twice: ``` namespace MEGA_MACRO { void foo(std::span<int> s) { super_awesome_platform_specific_thing(s); } } // namespace MEGA_MACRO ``` Whatever you do - the code above has to be written once but compiled twice. In one file/in many files - doesn't matter. My point is - I don't think you can compile that code twice if you support modules.
- janwas 2y agoI think I do understand, this is exactly what we do. (MEGA_MACRO == HWY_NAMESPACE) Then we have a table of function pointers to &AVX2::foo, &AVX3::foo etc. As long as the module exports one single thing, which either calls into or exports this table, I do not see how it is incompatible with building your project using modules enabled? (The way we compile the code twice is to re-include our source file, taking care that only the SIMD parts are actually seen by the compiler, and stuff like the module exports would only be compiled once.)
- dyaroshev 2y ago> is to re-include our source file Yeah - that means your source file is never a module. We would really like eve to be modularized, the CI times are unbearable. I'd love to be proven wrong here, that'd be amazing. But I don't think google highway can be modularized.
- janwas 2y agoWhat leads you to that conclusion? It is still possible to use #include in module implementations. We can use that to make the module implementation look like your example. Thus it ought to be possible, though I have not yet tried it.
- dyaroshev 2y agoWell. You have a file, something like: load.h You need to include it multiple times, compiled with different flags. So - it's never going to be in load.cxx or whatever that's called.
- janwas 2y agoAs mentioned ("re-include our source file"), we are indeed able to put the SIMD code, as well as the self-#include of itself, in a load.cxx TU. Here is an example: https://github.com/google/gemma.cpp/blob/9dfe2a76be63bcfe679b94335f171674420f92e8/ops/bench_matmul.cc#L49 https://github.com/google/gemma.cpp/blob/9dfe2a76be63bcfe679...