13 ms·
Faster: Fast numerical calculations in Rust
- nerdponx 9y agoHow do these numbers stack up to equivalent algorithms in C and Fortran? Are we going to see a RustBLAS soon? Something open-source that could go up against MKL for performance would be really amazing.
- fnl 9y agoIt would be cool to have some equivalent of a complete BLAS implementation in pure Rust, but I am not sure how sensible/economically viable that would be. But there do exist Rust creates built on top of existing BLAS libraries, e.g. https://github.com/mikkyang/rust-blas https://github.com/mikkyang/rust-blas Rather, I'd like to have something like Python's Numpy for Rust, not sure there is something equivalent to that, but this faster crate certainly is a step in that direction, conceptually at least.
- adrianN 9y agoWhat's the point of reimplementing BLAS in Rust? Those libraries have been polished for literally decades. They're not even security critical.
- nerdponx 9y agoNo point of doing it in Rust specifically, as opposed to any other language. But the point would be no longer having to trade software freedom (or at least open source) for performance -- try benchmarking Numpy built on MKL vs OpenBLAS and you'll see what I mean. If someone gets inspired by a new language to try and write a free or open-source MKL competitor, because that language has such-and-such features that make it more feasible than in Fortran or C, then that'd be fantastic. All I was suggesting is that it'd be cool if Rust was that language.
- SloopJon 9y agoIs there a simpler way than building to find out whether a crate requires nightly, as this one does?
- eridius 9y agoYou could try clicking on the "build|passing" badge and see what it's being built against.
- steveklabnik 9y agoCheck src/{main, lib}.rs for any !#[feature] flags.
- FridgeSeal 9y agoFor better or worse I have a very big soft spot for things in programming that go fast, even moreso for things that go really fast. I look forward to learning more Rust so I can get an excuse to use this.
- dboreham 9y agoBack in the day we had to add extra STOP statements at the end of our Fortran programs if the machine was really fast because it would crash through the first one or two.
- FridgeSeal 9y agoReally? That's actually awesome! CPU's and GPU's are capable of breakneck speeds, so I love to see things that really make the most out of the capacity available.
- dboreham 9y agoNope. This is what used to pass for a programmer joke. STOP C Add a couple more stop statements in case someone runs this on a Cray and it is going so fast it breaks though the first one: STOP STOP
- Someone 9y agoWell, there is this: http://elixir.free-electrons.com/linux/latest/source/arch/x86/kernel/process.c#L360 http://elixir.free-electrons.com/linux/latest/source/arch/x8... Yes, Linux does the equivalent of while(true) { halt } I don’t think that code will loop, but why take the risk? There is/was a detailed description of what it takes to stop an OS that included multiple ways to stop the CPUs, executed in order in the hope/expectation that one of them would work that in the end hit a similar loop, but I can’t find it anymore.
- chime 9y agoThere used to be a Turbo button on most PCs in the 90s which would be on by default but could be disabled to support games made for slower CPUs.
- pzone 9y agoUtterly superficial thought, but how about the name "fastr" for this crate?
- bpicolo 9y agoMaking it harder to look up / talk to people about seems worse ;)
- hinkley 9y agoUsing a common adjective for your project name already makes it difficult to search for. Misspelling it works in your favor. Except for autocomplete...
- deleted 9y ago[deleted]
- drb91 9y agoAre you referring to “fastr” or “faster”, though? I’d imagine the former is much, much, much easier to google for and remember than “faster rust library”, which could return basically any piece of rust code ever.
- bpicolo 9y agofastr is a loaded term already anyway, plenty of google hits for it (graalvm’s r implementation). Crates.io search works just fine though
- aquadrop 9y agoor "simder"
- mncharity 9y agoI wonder if one could do a Rust version of https://github.com/ekmett/rts https://github.com/ekmett/rts ? It's a SPMD-on-SIMD exploratory hack, with SOA and masked branching, built on C++ templates. Core is https://github.com/ekmett/rts/blob/master/src/rts/varying.hpp https://github.com/ekmett/rts/blob/master/src/rts/varying.hp... and https://github.com/ekmett/rts/blob/master/src/rts/vec.hpp https://github.com/ekmett/rts/blob/master/src/rts/vec.hpp .
- Ar-Curunir 9y agoSo something like rayon + faster?
- mncharity 9y agoYes, plus integrated branched control flow using simd masks.[1] [1] eg, random ggl link: https://gain-performance.com/2017/05/14/umesimd-tutorial-8-conditional-execution-using-masks/ https://gain-performance.com/2017/05/14/umesimd-tutorial-8-c... https://github.com/AdamNiederer/faster https://github.com/AdamNiederer/faster https://github.com/rayon-rs/rayon https://github.com/rayon-rs/rayon
- flukus 9y agoFinally, the performance of C combined with the readability of perl.
- sctb 9y agoCould you please not post like this? https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- flukus 9y agoCan we apply this policy for every "C is unsafe and should never be used" post? Seems like it's selectively applied by the languages with the best brigading teams.
- gatmne 9y agoWhen 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. Please consider adding such benchmarks so that we can assess how fast this library really is when compared to other more established libraries.
- bigiain 9y agoAt 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 agoCompared 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 agoI 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 agoit 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!)
- IncRnd 9y agoI don't see absurdly fast anything in this post. Are there any benchmarks that would support the statement "absurdly fast numerical calculations"?
- partycoder 9y agoSuperlatives are problematic because for instance "fast" is relative to something and that something might change over time. Superlatives are usually challenged and you will require proof. The proof itself can also be challenged. Suddenly you are spending a lot of time. I would rather say: "SIMD math library" rather than "Fast library".
- smnc 9y ago"Faster" is technically a comparative, not a superlative. Otherwise, sound advice.
- partycoder 9y agoRight, superlative is not the right term. "Fastest" would be the superlative, and is not in use. I am just generally against referring to software in absolute terms like: simple, fast, friendly, lightweight, etc. since it can be misleading. I consider a good practice to separate facts and opinions to achieve clear communication. Passing opinions as facts is dogmatism.
- mkj 9y agoWon't the compiler be autovectorising that kind of code already?
- vvimpcrvsh 9y agoSadly, even something like [1.0f32].map(|s| s.sqrt().abs().recip()).collect() doesn't get vectorized 99% of the time; you can check the disassembly and you'll see sqrtss et al.
- galangalalgol 9y agoThere are some llvm flags you can pass to see what got autovectorized in the rustic output. And some that make it autovec more stuff. It is really sensitive to container size. Just throwing a few flags when compiling n-body speeds it up quite a bit over the one up on the benchmark game. I got it to beat the c implementation which had explicit SIMD with portable rust code. Still didn't beat FORTRAN with ifort but faster than gfortran. Also, when rust brings in an llvm with newgvn the autovec should get better.
- fnord77 9y agoI thought modern languages optimized code into SIMD instructions where it could automatically... I know Java does this.
- burntsushi 9y agoThey do. It's called auto-vectorization and the Rust compiler does it (mostly by virtue of LLVM). But there are thousands[1] of SIMD instructions just for x86_64 alone and auto-vectorization doesn't come close to covering all of them. Even if auto-vectorization does cover the instructions you want to use, you might be justifiably uncomfortable with relying on it for performance in every case (or perhaps you simply can't rely on it), and would instead prefer to explicitly write out the transformations. [1] - https://software.intel.com/sites/landingpage/IntrinsicsGuide/ https://software.intel.com/sites/landingpage/IntrinsicsGuide...
- vvimpcrvsh 9y agoLLVM and rustc are pretty fickle with what they'll autovectorize. The idea of faster is to make things which are impossible to autovectorize easy to write as SIMD. A few examples I'm targeting for the next point release are matrix determinants, cross products, byte-aligned encoding (like https://github.com/AdamNiederer/base100/blob/master/src/lib.rs https://github.com/AdamNiederer/base100/blob/master/src/lib....), and reductive operations like strcmp. AFAIK none of that can be autovectorized at all.
- YSFEJ4SWJUVU6 9y agoDid you also know that a sufficiently smart compiler can deduce the whole programming logic from English prose? It's just pretty hard to create one. Same applies to automatic optimizations in the general case: what do you exactly know about what Java does beyond that it is capable of using SIMD instructions? Have you perhaps evaluated how and where it does so, or how the end result compares to more explicit manual use of stream operations? edit: and for the record, the problem is not as easy as you seem to think it is, given how you described your astonishment.
- exDM69 9y ago> I thought modern languages optimized code into SIMD instructions where it could automatically... Kinda-sorta yes, but not really. Auto-vectorization is a very brittle optimization that only works at the best of times and the slightest change in your code can cause it to fall out of the hot path. You have to be extra careful with aliasing and use the "restrict" keyword a lot. If you really do care about performance, you still have to write your hot loops with explicit SIMD code.
- vvimpcrvsh 9y agoAuthor of Faster here. Thanks so much for posting this; I was wondering where the flood of stars was coming from!