7 ms·

When I read "absurdly fast", I expected to see some benchmarks against an equivalent SIMD implementation in C or at least a similar library in another language.

• bigiain 9y ago
  At a quick glance, the "absurdly fast" seems to be talking about programmer time, not cpu time. It shows four lines of code, and compares it to ~30 lines with the comment "Even with all of that boilerplate, this still only supports x86-64 machines with SSE or AVX ... " The closing section: "Here are some extremely unscientific benchmarks which, at least, prove that this isn’t any worse than scalar iterators." suggests the final executed code probably runs at around the same speed, but the short version is _way_ easier to write and _way_ more portable.
  • AstralStorm 9y ago
    Compared to 4 lines in Eigen it is not impressive anymore. And that thing cab also statically optimize equations. Call back when Rust grows an equivalent.
• archi42 9y ago
  I second this. When I do some quick stuff at home or at work, a small ditch in performance is okay, if I spend less time coding. But I know a few people (researchers) with access to >1 PetaFlop/s clusters. Being hit with performance degradation is possibly an issue there: More power consumption; other people need the system, too; as an individual, you might have limited cluster time available. Of course this depends if 1% is to be expected, or 20%...
• currymj 9y ago
  it seems like the main problem this solves is around the ergonomics of getting Rust to compile your code down to SIMD instructions. having run into this while working on Rust code a while ago, I really appreciate this library! I would expect Rust users to come to this library when they find themselves working with numeric arrays on Intel CPUs, much like I did. I think it would be quite useful to me right now, whether or not it turns out to be fast enough to make users doing array computations come to Rust. (I'd guess probably not, although it could get there!)
• vvimpcrvsh 9y ago
  I'll add benchmarks soon; I'm trying to make it usable first ;). Right now, it's within 5% of ugly-style explicit SIMD code in the absolute worst case (the example in the README is more like 1%). The hot bit (the body of the map) compiles down to 100% simd instructions in the order LLVM thinks will be the fastest, and the load/store bit has an extra branch per load/store. This is because faster is mainly a bunch of 1-line wrappers around SIMD intrinsics, and a bunch of polyfills which only get used on machines which don't support those intrinsics. The main reasons you'd experience a perf hit compared to explicit SIMD when using this library would be using runtime feature detection (minimal, and not implemented yet - would add around 2 branches per simd_iter call), getting lazy with gathers/scatters rather than ugly bit-level hacks, and accidentally using operations which aren't vectorizable on your machine (scatters on non-avx512, reductive operations on non-sse4.2, etc) and not realizing it (explicit simd will throw a SIGILL; faster will use a scalar polyfill).
  • hateduser2 9y ago
    You do you.. but why wait on the benchmarks? its the only thing I care about when I look at this.. I'm willing to forgo semantics if its absurdly fast
    • Ar-Curunir 9y ago
      If you don't care as much about usability and care only about speed, there's already stdsimd which allows you to invoke SIMD intrinsics directly. This crate explicitly focuses on usability, and given the limited author time, prioritizes that.
      • geezerjay 9y ago
        The people behind stdsimd haven't started this thread praising their work as being absurdly fast. Extraordinary claims require extraordinary evidence. A baseless claim accompanied by excuses such as "no time for proofs, working on aesthetics" to avoid presenting evidence that would support those claims doesn't build any confidence on the original claim.