9 ms·
Let the Compiler Do the Work
- glangdale 7y agoI'm not a Rust guy, so can someone explain to me why SIMD intrinsics are "unsafe"? They don't seem unsafe in the way that, I dunno, raw memory accesses are unsafe. Non-portable, of course, I get.
- __s 7y agohttps://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm_load_ps&expand=3330 https://software.intel.com/sites/landingpage/IntrinsicsGuide... Not all intrinsics are memory safe
- glangdale 7y agoI get that; obviously if you use an intrinsic that reads from memory it's a raw load. However, surely there's a great big pile of them that are really just different ways of doing things to a (slightly bigger than usual) Plain Old Data structure?
- nicoburns 7y agoI think it's partly architecture compatibility. The SIMD functions exposed by Rust at the moment are all CPU-architecture-specific, but Rust code is generally expected to work seamlessly cross-platform. I believe there are plans to expose higher-level functionality as a safe interface at a later date (the API design work just hasn't been done yet). For now you can get this functionality as a 3rd-party crate https://github.com/AdamNiederer/faster https://github.com/AdamNiederer/faster
- nikic 7y agoSIMD intrinsics are unsafe, because reaching a SIMD intrinsic not supported by the host CPU is undefined behavior (in practice usually SIGILL).
- Avamander 7y agoSo most Rust builds are inefficient given they don't take advantage of modern instructions?
- kibwen 7y agoBy default Rust builds binaries that will run on any processor for the given target. If you want it to generate instructions that are processor-specific--thereby reducing the portability of the binary--you must pass an explicit compiler flag. Clang exhibits the same behavior with its -march and -mcpu flags, and I would assume GCC does as well.
- keldaris 7y agoSo SSE2 intrinsics should be safe for x86_64 builds?
- Narishma 7y agoYes.
- progval 7y agoIn addition to other answers: SIMD in rust is currently exposed via a very low-level API. But in the future, someone will probably build a safe API on top of it.
- GlitchMr 7y agoThere are multiple reasons. 1. Using instructions that don't exist on a given CPU will cause the program to crash. 2. `core::arch` exists so that stable Rust programs could make use of SIMD instructions for performance (in particular, `regex` crate). They are very low level, and there is a lot of those, so whether any given SIMD intrinsic is safe or not wasn't considered as those functions exist for safe SIMD abstractions to use - which is advantageous, as Rust cannot really do breaking changes, while a library could easily release a new version without breaking the users (which will still use the old version).
- quietbritishjim 7y ago> Using instructions that don't exist on a given CPU will cause the program to crash. But surely this also applies to a Rust program that only uses safe code but it's compiled with the right compiler switches that is allowed to use SIMD instructions?
- steveklabnik 7y agoIt will only use the SIMD intrinsically that work on the platform requested, in that case.
- mikepurvis 7y agoSure would be nice to have a way to mark a block as "compile for arches x, y" and have the binary check on entry which you have and select a different code path. This way you could do it only for your hot sections and not need to have the entire binary duplicated. AFAIK the main way to manage this right now is throwing the optimized stuff into a plugin and then loading it at runtime— but that ends up having huge implications on your project structure, source layout, etc.
- zamadatix 7y agohttps://doc.rust-lang.org/1.29.1/std/arch/#dynamic-cpu-feature-detection https://doc.rust-lang.org/1.29.1/std/arch/#dynamic-cpu-featu...
- mamcx 7y ago> why SIMD intrinsics are "unsafe"? Is important to note what is the POV of "unsafe". Is not unsafe for you or for your setup. Is unsafe from the COMPILER ie: it can't PROVE is safe! Static analysis can only decide a subset of the possible "safe" interactions. In the time of COMPILING. Rust can't decide if use of SIMD is safe AT COMPILE TIME because at RUNTIME maybe the cpu don't have it!
- zamadatix 7y agoWhy can't it just run dynamic feature detection to see if it needs to load e.g. a SISD shim version of the function which is exactly the same except the intrinsic is replaced with a generic implementation? Or at least the other way around: if a function is declared with dynamic feature detection and a default path exists why can't it be declared safe by the compiler?
- mamcx 7y agoThis is possible (for example): https://github.com/jackmott/simdeez https://github.com/jackmott/simdeez The thing is that is not yet in-build in the lang. Let the crates sort some problems before commit it in the lang is like part of the philosophy of rust. For example, rust change the hash implementation after certain crate prove it worthy.
- glangdale 7y agoOK, thanks for the clarifications. I think it's kind of daft to lump in "might not run on your particular processor" with "unsafe" - these seem like very different concepts - but it's at least consistent.
- Skunkleton 7y agoInline assembly is possibly one of the most unsafe features available in any HLL. What happens when your inline assembly isn't valid on the target system? Undefined behavior. What happens when your inline assembly does operations that are outside the model of the language? Undefined behavior.
- glangdale 7y agoSurely if you control the whole toolchain, you can stick flags into the binaries/libraries and fail at link/load time. The fact that default C ABI prefers to work without a condom here doesn't mean that Rust has to! This is one of the most avoidable forms of undefined behavior I'm aware of.
- Skunkleton 7y agoEventually the program counter will advance to the unsafe inline assembly. At this point there are no guarantees. There is no enforced ABI. The inline assembly can do anything. This is not a compile or link time problem. This is a runtime problem.
- glangdale 7y agoI just meant that a binary or library could mark itself (say) "If you execute me, I will run AVX2" upon using this kind of inline asm. Static linking to create a bigger library or program transfers the mark. Eventually you will either dynamically link or load a library or attempt to run it on the actual computer where it's meant to run; at this point, you fail gracefully. I know this isn't a 100% panacea, as some programs will have multiple bits of inline asm for different system and some sort of better or worse way of determining at run-time what to run. However, I've written plenty of programs where it pretty much says on the tin: "you must have AVX2 to run this". All up this seems like a pretty trivial problem compared to the problem of 'lack-of-safety' in general, and I'm not thrilled to see SIMD intrinsics being put in the "OMG So Dangerous" box as if they are a bunch of wild pointer ops (except, of course, in the case where they actually are - e.g. scatter/gather)...
- burundi_coffee 7y agoMy prof in Introduction to Programming always said: "Generally, it's a good idea to avoid decisions."
- lorenzhs 7y agoPage isn't loading for me, so here's a snapshot: https://archive.is/i5uvl https://archive.is/i5uvl
- kstenerud 7y ago"sqr is a place where one might be tempted to use a macro in C, but writing such a macro in a way that x doesn't get evaluated twice is tricky." Slightly off-topic, but it's important to point out that in modern C, implementing such a function as a macro is always a mistake. You'd do it as an inline function. Macros in modern C should only be used for code generation (for DRY). If the language supports doing it without a macro, then do it without a macro.
- LandR 7y agoSame advice in LISP. Don't use a macro where a function will do.
- petrogradphilos 7y agoNever use a macro to do an inline function’s job.
- jnordwick 7y agoThe point for doing it as a macro is to be generic over types. In C++ you would do a template function, but no real option in C.
- gallier2 7y agoSince C11 there's _Generic which allows to do it. Using macros in that case is strongly advised (or else it would be very verbose).
- GlitchMr 7y agoYou don't need macros for generic code either :), Rust has generics. fn sqr<T: Copy + Mul>(x: T) -> T::Output { x * x }
- simias 7y agoThat's true, there are many situations where you simply can't replace a macro with a function because of this fact. MIN/MAX is a common example, unless you want to have one specialized version for every type. Unfortunately there are always tradeoffs using macros for something like that, you either end up evaluating the parameters more than once or you have to introduce variables in the macro that may shadow existing variables. Some compilers have extensions to help with that: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html
- shilch 7y agoClang also does some crazy-good SIMD optimizations if you set -march=native. But I think the Rust compiler is based on LLVM as well, right?
- steveklabnik 7y agoIt is, yes.
- rwem 7y agoEverybody should build everything with a reasonable setting of march. Debian Linux still builds everything for K8, a microarchitecture that lacked SSE3, SSE4, AVX, AES, etc. Even building with march=sandybridge seems petty conservative and gives significant speed improvements in many common cases.
- JoshMcguigan 7y agoFor your `sqr` function, what is the benefit of writing `x * x` over using `x.powi(2)` [0]? You didn't mention it in the article, but did you find a performance improvement from doing this? [0]: https://doc.rust-lang.org/std/primitive.f64.html#method.powi https://doc.rust-lang.org/std/primitive.f64.html#method.powi
- chias 7y agoAs far as CPU instructions go, multiplication is _significantly_ faster (i.e. an order of magnitude) than exponentiation. That said, I can't speak to whether the Rust compiler wouldn't just optimize that away -- it seems like unrolling exponentiation into multiplication for small constant powers would be a very safe and easy thing to do.
- raphlinus 7y agoIt certainly does do this: https://rust.godbolt.org/z/ZaDAKa https://rust.godbolt.org/z/ZaDAKa Not just small constant powers either. I tried .powi(1000000) and it compiled into a sequence of 25 vmulss instructions.
- chias 7y agoInteresting, thank you! I suspect then that defining it at x*x is just just because it's easier to type than x.powi(2).
- simias 7y agoOne of the main quality-of-life improvement of Rust over C and C++ IMO is the crate system, and how you don't have to worry about codes from other files not being inlined properly (there's LTO now but it's always more limited than compile-time inlining and optimization). No need to move things to headers (no headers at all, actually), worry about forward declarations and exposing internal bits of the API etc... Just write the code normally and naturally and let the compiler figure it out. No need to consider subtle performance tradeoffs when deciding where to write the code, just put it where it makes sense.
- cwzwarich 7y ago> there's LTO now but it's always more limited than compile-time inlining and optimization In what way do you think it is more limited?