3 ms·
By "large" I mean compared to the fraction of needs-slow-emulation things present currently in C (which is currently approximately zero, other than using intege
by dzaima 3y ago
By "large" I mean compared to the fraction of needs-slow-emulation things present currently in C (which is currently approximately zero, other than using integer/float types unsupported on the target hardware (and maybe multiplication/division), but that's comparatively extremely easy to determine).
Maybe my use-case - implementing an array language - is unusually unfit for being done in a generic way, but I just don't see how it (or much of anything outside of very trivial things) would be reasonable to figure out how to do performantly with anything other than either manually using intrinsics, or with custom-written abstractions around such with known worst-case emulation amount (we're doing[0] the latter with a DSL[1] that's basically a basic compile-time code generator; that just leaves unsupported things undefined on any given architecture, and in most occurrences of hitting that I've found ways to write things avoiding expensive emulation).
[0]: https://github.com/dzaima/CBQN/tree/master/src/singeli/src https://github.com/dzaima/CBQN/tree/master/src/singeli/src
[1]: https://github.com/mlochbaum/Singeli https://github.com/mlochbaum/Singeli
- janwas 3y agoCool, thanks for sharing, wasn't aware of those. It is natural that C has about zero emulated operators - today's CPUs are compatible with ones likely built with that use-case in mind. That is a low bar for comparison, especially given a large speedup from SIMD :) I agree a custom abstraction is currently the most reasonable approach for SIMD. We're basically doing the same thing, just differing a bit in how much emulation is acceptable, and the language for compile-time code generation (it's nice how compactly you can express things in Singeli).