31–40 of 283 posts
Since the link is a bit slow, here's an IPFS version: https://www.eternum.io/ipfs/QmYrdKpWbHCuNPUrBd6MPFrcTqPBW55w...
Nice to see IPFS links popping up
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 borrow two different rows, that's fine as long as the row subscript is different.
Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…
> Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. If you use CMake, you do get tests for free at least. > Maybe it's worth the hassle of making array manipulation slightly less convenient for the sake of security? On my computer I will always choose speed over security... especially for video processing & stuff like this. Wasting CPU cycles has a direct effect on…
CMake is not part of C. Tests and (soon) benchmarks are parts of Rust. That makes a big difference in practice.
Besides if third party solutions are considered it won't be difficult to come up with one for Rust.
>On my computer I will always choose speed over security... especially for video processing & stuff like this.
It's true that the prospect of running unoptimized codecs is not very appealing. That being said when I think about it video and audio streams are probably the main source of untrusted 3rd party data that I actually handle on my computer. And it's not simple processing either, it's quite complex.
Imagine the havok if a zeroday in a popular codec library is found and an attacker manages to ship it on a popular tracker in the form of "Game of Thrones S07E04.mkv". The payoff would be immense. I wouldn't run a random executable found on bittorent but I won't think twice about opening a video file.
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…
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…
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…
I've only looked into Rust briefly, but I thought this was the point of unsafe blocks? You can roll your own multi-dimensional array data structure using unsafe blocks if you're certain what you're doing is actually safe.
Some of the complaints are perfectly fair (compile time, powerful but unwieldy macros). Other complaints seem a bit odder to me: > While overall built-in testing capabilities in Rust are good (file it under good things too), the fact that benchmarking is available only for limbo nightly Rust is annoying; Okay, but what are you comparing it against? Neither C or C++ have builtin benchmarking or even tests. > If you ca…
> I don't understand this one at all. What's wrong with "as"? That it silently overflows. > And if you need a checked conversion just write a small wrapper function? A better suggestion would be to wait for TryFrom/TryInto which IIRC should be stabilised soon-ish. > So unless I'm missing something something like: Assignment ( https://doc.rust-lang.org/reference/expressions.html#assignm... ) not declaration ( https://…
> And don’t tell me about Bytes crate—it should not be a separate crate I'd be interested to hear the author's reasoning behind this, if it does what they want then why not use it? It's small and well written, so I don't think vetting it should be a problem. The rest of the article seems quite sensible, that comment just strikes me as a little odd.
Bytes is basically just C++'s `std::string` (kind of don't bite my head off people who've memorized the C++17 standard). Its an ARC backed array [1]. This suggests it should be a fairly fundamental abstraction.
Edit: ^^^My C++ is wrong sorry :(
Really I disagree with its purpose. In its immutable, non-threaded safe form you can create the same structure by just borrowing a value. This ofc requires making your peace with the borrow checker and `Cow` copy on write types.
By in large Bytes advertised purpose is network code. And for networking code its really only _super_ useful if your using a Packet Ring in Linux. As jemalloc will not return regularly re-allocated buffers.
Really this is all performance theater. How you manage/architect your socket reads/writes will have an order of magnitude larger effect then what abstraction you _store_ those bytes in once read.
[1] https://carllerche.github.io/bytes/bytes/struct.Bytes.htm
Earlier quoted context omitted.
Decoding in libjpeg-turbo is mostly implemented in ASM. Rust, like C, is slower than hand-optimized SIMD ASM.
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.
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…
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;