Rust: Not So Great For Codec Implementing

Post by Zelizz » Tue, Aug 01, 2017, 6:55 PM UTC

phkahler wrote: post #39

mrec wrote: post #22

Earlier quoted context omitted.

If anyone's interested, this is the (epic!) discussion thread for "Getting explicit SIMD on stable Rust": https://internals.rust-lang.org/t/getting-explicit-simd-on-s... It still wouldn't compete with really good hand-tuned asm, but it might help reduce the perf/usability tradeoff a bit.

I'd just like to see 2,3, and 4 element vectors as a first class citizen in C, C++, or Rust. These are incredibly common for so many things it's hard for me to understand this omission. I want to be able to pass them by value and as return values from function. I want to do operations like a=b+c with vectors without creating classes or overloading operators. For a lot of people the SIMD instructions are about paralle…

Post by kbenson » Tue, Aug 01, 2017, 6:59 PM UTC

dbaupp wrote: post #117

kbenson wrote: post #95

Earlier quoted context omitted.

Is that true? Consider variables a=3, b=4, c=7. With a large single array of 100 elements, but divided into 10 10 element pieces by convention, a slice of elements might be accessed by getting the elements array[10 a+b] through array[10 a+c]. If we also want a slice from the next segment, that would be array[10 (a+1)+b] through array[10 (a+1)+c]. With a multidimensional array, of 10 bounds checked segments of 10 elem…

That's true: it probably does make some (probably common) things easier because you get to disjoint slices with simpler indexing conditions, but the problems are equally hard in the general case: the type checker/borrow checker has to understand arithmetic rules like `a != a+1`, and be flow sensitive for things like `if a != b { ... }` and other ways to imply the inequality. (And, it's only a subset of the cases when…

Post by greenhouse_gas » Tue, Aug 01, 2017, 7:14 PM UTC

Manishearth wrote: post #55

nolok wrote: post #45

Earlier quoted context omitted.

Haven't used Rust yet, is it kind of similar to Go where any file can simply import and then Go knows how to fetch and build when needed ? And then when you remove the calls (eg during a refactor) the compiler force you to remove the imports too, stopping the infinite bloat caused by "no one really knows if we still need this" that can be common in other language. I really liked that "dependancy as part of the langua…

> is it kind of similar to Go where any file can simply import You declare your crate dependencies in a Cargo.toml file. Rust does proper versioning of dependencies so having a separate manifest is desirable. Within your code you declare the existence of a crate via `extern crate` and then you can use it wherever. > the compiler force you to remove the imports too it warns.

Post by steveklabnik » Tue, Aug 01, 2017, 7:18 PM UTC

greenhouse_gas wrote: post #125

Manishearth wrote: post #55

Earlier quoted context omitted.

> is it kind of similar to Go where any file can simply import You declare your crate dependencies in a Cargo.toml file. Rust does proper versioning of dependencies so having a separate manifest is desirable. Within your code you declare the existence of a crate via `extern crate` and then you can use it wherever. > the compiler force you to remove the imports too it warns.

Do you know if there are plans for rustfmt to auto-import like gofmt does? In the sense that if a crate is available (in the .toml file) and you reference it, rustfmt will automatically insert the required "import" and "use".

Post by phaylon » Tue, Aug 01, 2017, 7:24 PM UTC

pcwalton wrote: post #40

Animats wrote: post #32

The only legitimate complaint there is that it's tough in Rust to get two arbitrary mutable slices into the same array. Rust wants to be sure they're disjoint, to prevent aliasing. For some matrix manipulation, this is inconvenient. It would be easier if Rust had real multidimensional arrays. If the compiler knows about multidimensional arrays, some additional optimizations are possible. For example, if you want to b…

As the article notes in an edit, there's a method for this: split_at_mut(). It's very useful, and I reach for it quite a bit in low-level array code. It might be nice to have some sort of pattern matching syntax for it, I suppose: let [ref mut a..16, ref mut b..] = *c; Meh. Sure is ugly. I'm not sure adding syntax would be worth it.

    let (a, b) = c[..16..];