News for hackers. Stuff that matters.
Re:Comparing Parallel Rust and C++ by edflsafoiewq on Thursday November 07, 2019 @07:01AM (#21472388)
The Rust is practically line noise. This is just awful

    let pack_simd_row = |(i, (vd_stripe, vt_stripe)): (usize, (&mut [f32x8], &mut [f32x8]))| {
        for (jv, (vx, vy)) in vd_stripe.iter_mut().zip(vt_stripe.iter_mut()).enumerate() {
            let mut vx_tmp = [std::f32::INFINITY; simd::f32x8_LENGTH];
            let mut vy_tmp = [std::f32::INFINITY; simd::f32x8_LENGTH];
            for (b, (x, y)) in vx_tmp.iter_mut().zip(vy_tmp.iter_mut()).enumerate() {
And I tend to write stuff like this in Rust too. The loops especially. It's just so easy to throw together all those iterator combinators and get some ugly blob that's going to make people's eyes glaze over.
Re:Comparing Parallel Rust and C++ by cogman10 on Thursday November 07, 2019 @12:18PM (#21475073)
I honestly don't see what's so bad about this. About the only thing that might be more useful is better variable names and maybe a function or two to clear up exactly what's going on. But even still, this is math heavy code. I don't think I've ever seen math heavy code (particularly dealing with matrix manipulation) that didn't end up looking like this.
Re:Comparing Parallel Rust and C++ by brutt on Thursday November 07, 2019 @12:45PM (#21475359)
Code is easy to follow. I see no problem there.

`pack_simd_row` is lambda: `|arguments: types| { body }` Arguments are: * `i` of type `usize` (unisgned size_t), * tuple (anonymous struct) with two fields: vd_stripe and vt_stripe, which are modified inside of lambda. They are references to fixed size array of 8 floats.

Inside function we have loop over result of iterator, which produces tuple with two fields: `jv` and tuple with two fields: `vx` and `vy`. `vx` and `vy` are elements from `vd_stripe` and `vt_stripe`. `jv` is their index.

Inside loop we create two temporary mutable variables: `vx_tmp` and `vy_tmp`, which are fixed size array of 8 floats, which are initialized with infinity.

Then we have next loop, which goes to modify these temporary arrays in place.

And so on.

Re:Comparing Parallel Rust and C++ by jml7c5 on Thursday November 07, 2019 @02:21PM (#21476377)
While the Rust version does flow logically, succinctness helps a lot more than people seem to appreciate. It's one of the reasons math notation is often so inconsistent: the brevity allows for easier manipulation and scanning. (Though I would not stretch the analogy too far, as inconsistent and overy brief notation can limit understanding while reading proofs.)

Being able to fit part of a program clearly into 5 lines with fewer characters makes it easier to ensure correctness than an algorithm spread over 10 lines that is full of extra "noise". It's why there's so much syntactic sugar in so many languages.

Re:Comparing Parallel Rust and C++ by tluyben2 on Friday November 08, 2019 @11:25AM (#21483724)
It is easy to follow but I cannot say it's very pleasing to read.
Re:Comparing Parallel Rust and C++ by snaky on Thursday November 07, 2019 @11:18AM (#21474522)
Maybe it's time to propose alternative syntax for Rust?
Re:Comparing Parallel Rust and C++ by rezeroed on Thursday November 07, 2019 @02:21PM (#21476379)
I could produce greater horror with c# linq.
Re:Comparing Parallel Rust and C++ by tluyben2 on Friday November 08, 2019 @11:24AM (#21483711)
Please give us an example. I have read a lot of linq; it never looked quite this horrible so I am curious.