News for hackers. Stuff that matters.
Re:RustBelt: securing the foundations of the Rust programmin... by burntsushi on Monday February 05, 2018 @08:31PM (#16313805)
> and is very limited

You might be thinking of the `simd` crate, in which case, you're right. But we are getting closer and closer to exposing a large set of vendor intrinsics: https://github.com/rust-lang-nursery/stdsimd --- You can use it today on Rust nightly. This includes runtime CPU feature detection!

ripgrep is an example of a program that is written in Rust, is CPU bound and uses explicit SIMD in various places to speed up text search. (It hasn't moved to stdsimd yet and is still using the `simd` crate and the old platform intrinsics system exposed by rustc. But ripgrep will move to stdsimd soonish.)

Re:RustBelt: securing the foundations of the Rust programmin... by Const-me on Wednesday February 07, 2018 @12:00AM (#16322343)
Very good.

Finally, someone in Rust community realized we don’t want higher-level abstractions, we just want whatever the hell our hardware can do. If that thing will go stable, I will consider Rust for a next project (BTW, doing CAD/CAM stuff for Windows).

Feature detection is no big deal, it’s just a couple of lines in C.

But I’m curious how well that thing gonna work in practice? In C++ we have low-level control over memory layout allowing to place these SIMD vector values in STL containers with correct alignment. We have function pointers with vectorcall calling convention that enable implementing CPU-dependent routines very efficiently. The compiler inlines a lot of that SIMD code. Maybe you know how much of that applies to rust + stdsimd?

Re:RustBelt: securing the foundations of the Rust programmin... by burntsushi on Wednesday February 07, 2018 @08:57AM (#16324381)
> Finally, someone in Rust community realized we don’t want higher-level abstractions, we just want whatever the hell our hardware can do. If that thing will go stable, I will consider Rust for a next project (BTW, doing CAD/CAM stuff for Windows).

That's great, but please consider that this is an unfair characterization. stdsimd has been in the works since 2016, and many people have been involved. It's not like nobody "realized" we needed to expose vendor intrinsics before then, but it just hadn't been worked on. It's a ton of work.

> Feature detection is no big deal, it’s just a couple of lines in C.

It's only a few lines in Rust as well. But this is spoken like someone who uses it instead of someone who was involved in making it available. :-) It's not just about querying the CPU, but enabling functions to compile with specific target and also reasoning through Rust's safety story there, which is non-trivial.

> But I’m curious how well that thing gonna work in practice? In C++ we have low-level control over memory layout allowing to place these SIMD vector values in STL containers with correct alignment. We have function pointers with vectorcall calling convention that enable implementing CPU-dependent routines very efficiently. The compiler inlines a lot of that SIMD code. Maybe you know how much of that applies to rust + stdsimd?

I don't see any reason why any of that would be a problem with Rust. Inlining is just as important to Rust as it is to C++, and so is control over memory layout. You should try it out and give feedback. :-) Now would be the time!

Re:RustBelt: securing the foundations of the Rust programmin... by dbaupp on Wednesday February 07, 2018 @04:58PM (#16328397)
> It's not like nobody "realized" we needed to expose vendor intrinsics before then, but it just hadn't been worked on.

It had been... in 2015. :)

Re:RustBelt: securing the foundations of the Rust programmin... by burntsushi on Wednesday February 07, 2018 @05:00PM (#16328406)
Errm, d'oh, sorry! :-( I had vendor intrinsics stuck in my head, but now that I say that, I of course now remember the platform intrinsic stuff.