Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust: Not So Great For Codec Implementing

codecs.multimedia.cx

Post reply on HN
Print view View original

81–90 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#81

Post by cryptonector »

davemp wrote: post #58

> And that’s why C is still the best language for systems programming—it still lets you to do what you mean (the problem is that most programmers don’t really know what they mean) Honestly after a ~1yr of embedded C co-op/intership experience, I'm familiar enough but not too entrenched to say that C is not that great for embedded/systems. When you're dealing at the hardware architecture level you need more detail tha…

"do what I want" usually means "simple ABI that is trivial to interface with" which means you "can layout structures the way you want" and "calling conventions are simple so you can call C from assembly and any HLL FFIs and vice-versa".

Really, that's all. If it was possible to build C++ classes in C or assembly, it would be done. But it's not because C++ doesn't have the kind of ABI (or any) that would allow one to do that.

Of course, in practice C only gets you 95% of the structure layout functionality you need, as the rules for packing structures and bitfields(!) aren't sufficiently nailed down. Still, 95% out of the box is pretty good, and with some care you can get 100%. This matters when writing, e.g., drivers, but also codecs for another example.

Any systems programming language aiming to replace C has to provide support for a C-like ABI.

I'm not praising C here, mind you. It can't be replaced (with Rust or similar) quickly enough.

Re: Rust: Not So Great For Codec Implementing

#82

Post by steveklabnik »

gwbas1c wrote: post #74

I tried Rust for the first time a few months ago. One of the things that really impressed me was that it was very easy to just get started. Even though the language is very different than I'm used to, I was able to "just jump in" without jumping through a lot of hoops. I was working with 3rd party crates very quickly. One thing that I think does need improvement is the error handling. Far too many idiomatic examples…

There's a whole chapter in the second edition of the book devoted to error handling https://doc.rust-lang.org/book/second-edition/ch09-00-error-...

Re: Rust: Not So Great For Codec Implementing

#83

Post by AceJohnny2 »

Codecs are actually a wonderful test-case for Rust: they're a frequent source of vulnerabilities because they have to deal with arbitrary input, they usually have to perform fiddly sub-byte and/or array manipulation, and their pressure for maximum performance mean they have to make as efficient use of the hardware and memory as possible (and any mistake lead back to the first point)

So even if you don't agree with some of the author's points, his use-case is a good test for the suitability of Rust as a Systems Programming Language.

Re: Rust: Not So Great For Codec Implementing

#84

Post by dbaupp »

nwmcsween wrote: post #62
phkahler wrote: post #39

Earlier quoted context omitted.

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…

It doesn't really make sense in C as any modern optimizing compiler will turn it into SIMD. IIRC rust needs explicit SIMD due to bounds checking.

Bounds checking gets in the way for simple cases but anything even slightly more complicated needs to be written extremely carefully in any language, for autovectorisation to work. It is like, essentially, writing explicit SIMD without using intrinsics and without guarantees it will work as desired.

And, that is assuming that the autovectoriser is able to synthesise the desired instructions, e.g. I believe SSE2's packssdw & packusdw ("pack with signed/unsigned saturation") and pmaddwd ("multiply and add packed integers") are useful in a JPEG codec but I find it extremely unlikely that any compiler will autovectorise to them.

Re: Rust: Not So Great For Codec Implementing

#85

Post by curun1r »

gwbas1c wrote: post #74

I tried Rust for the first time a few months ago. One of the things that really impressed me was that it was very easy to just get started. Even though the language is very different than I'm used to, I was able to "just jump in" without jumping through a lot of hoops. I was working with 3rd party crates very quickly. One thing that I think does need improvement is the error handling. Far too many idiomatic examples…

For error handling, I'd encourage you to look at error-chain. It makes it pretty simple to propagate all your errors with try!/? so long as all your functions return a Result. And the quick_main macro can handle the panicking if you let it propagate all the way to main. Hopefully once the ? In main RFC gets released, quick_main won't even be necessary.

There's a couple of annoyances to it. The documentation is really sparse for something as integral as it aims to be. And there's a frustratingly large number of third-party crates that don't use standard error types and prevent you from calling chain_error to convert from their error types to yours.

But once you get the gist of it, a few lines of boilerplate gives you the ability to handle errors concisely and correctly throughout your program.

Re: Rust: Not So Great For Codec Implementing

#86

Post by Gankro »

AceJohnny2 wrote: post #83

Codecs are actually a wonderful test-case for Rust: they're a frequent source of vulnerabilities because they have to deal with arbitrary input, they usually have to perform fiddly sub-byte and/or array manipulation, and their pressure for maximum performance mean they have to make as efficient use of the hardware and memory as possible (and any mistake lead back to the first point) So even if you don't agree with so…

Yes, let us never forget how many exploits there are in trivial codecs like ICO and BMP, because they're written in C(++): https://bugzilla.mozilla.org/show_bug.cgi?id=775794#c0

Re: Rust: Not So Great For Codec Implementing

#87

Post by cbhl »

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…

Have you tried Halide? http://halide-lang.org/

I've seen it used for various video/photo processing operations.

Re: Rust: Not So Great For Codec Implementing

#88

Post by eridius »

gwbas1c wrote: post #74

I tried Rust for the first time a few months ago. One of the things that really impressed me was that it was very easy to just get started. Even though the language is very different than I'm used to, I was able to "just jump in" without jumping through a lot of hoops. I was working with 3rd party crates very quickly. One thing that I think does need improvement is the error handling. Far too many idiomatic examples…

There actually is a way to do that, which is to return Results, with error types that implement From so the nested errors can be "wrapped" in the generic ones, and then you can just use the ? postfix operator as an alternative to unwrapping in order to bubble up the errors.

If you're designing your own errors then there's some boilerplate you need to allow for the error wrapping, though you can always take the cheap way out and use Box as your error type (as any error can be wrapped in that).

And there's an RFC that's been accepted (https://github.com/rust-lang/rfcs/blob/master/text/1937-ques...) to allow main to return a Result, so you can use the ? operator in main, which will let you avoid even more unwraps, especially in example code.

Re: Rust: Not So Great For Codec Implementing

#89

Post by steveklabnik »

Manishearth wrote: post #80
davemp wrote: post #58

> And that’s why C is still the best language for systems programming—it still lets you to do what you mean (the problem is that most programmers don’t really know what they mean) Honestly after a ~1yr of embedded C co-op/intership experience, I'm familiar enough but not too entrenched to say that C is not that great for embedded/systems. When you're dealing at the hardware architecture level you need more detail tha…

> but if it makes an honest effort to be ergonomic for embedded There are constant improvements but I wouldn't say we're there yet. I think we will be though, embedded is something a lot of folks care about.

The latest on this front: http://blog.japaric.io/rtfm-v2/

Re: Rust: Not So Great For Codec Implementing

#90

Post by valarauca1 »

dbaupp wrote: post #73
valarauca1 wrote: post #38

Earlier quoted context omitted.

I agree with the author. 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 req…

Being an ARC backed array isn't like std::string, and I don't see why having that copy-on-write behaviour implies it is fundamental. Could you expand?

This is my mistake. I assumed shared pointer semantics and applied it to the wrong type :\
Post reply on HN