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

21–30 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#21

Post by knieveltech »

bigdubs wrote: post #19
eptcyka wrote: post #10

Whilst unrelated to the article, my complaint about codecs in Rust is that they seem to be slow. Whilst the reason for this might be the immaturity of the libraries that I've used, but they've always been slower than their C counter-parts. The native JPEG decoder spins up 4 threads to decode the same amount of frames at 3x the time as the libjpeg-turbo does. There's a similar story for the FLAC decoder. I don't think…

~fin~

While hijacking a thread for idle pedantry is something of a sport around here your comment is unusually pointless for the form. Go eat something, you'll feel better.

Re: Rust: Not So Great For Codec Implementing

#22

Post by mrec »

pornel wrote: post #12
eptcyka wrote: post #10

Whilst unrelated to the article, my complaint about codecs in Rust is that they seem to be slow. Whilst the reason for this might be the immaturity of the libraries that I've used, but they've always been slower than their C counter-parts. The native JPEG decoder spins up 4 threads to decode the same amount of frames at 3x the time as the libjpeg-turbo does. There's a similar story for the FLAC decoder. I don't think…

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.

Re: Rust: Not So Great For Codec Implementing

#23

Post by mcguire »

kllrnohj wrote: post #9
modalduality wrote: post #4

Not a Rust expert, but some thoughts on the negatives. > Compilation time is too large Can you try compiling incrementally? https://blog.rust-lang.org/2016/09/08/incremental.html . Might still only be on nightly. > And, on the similar note, benchmarks. I agree, profiling as well isn't as full featured as in more mature languages. Clojure, incidentally has great benchmarking due to being on the JVM. > Also the tuple a…

> Clojure, incidentally has great benchmarking due to being on the JVM. Eh? Benchmarking on the JVM is notoriously difficult bordering on impossible. There's things like Google Caliper but test runs take forever due to attempting to force JIT warmup and doing GCs after every run. And the project's own wiki tells you the results are basically meaningless for a variety of reasons. Benchmarking things like C++ or Rust a…

Benchmarking is pretty meaningfree in the best cases. The JVM isn't any worse in this regard.

The JVM is slow in many regimes due to things like JIT warmup. Rather than accepting that many JVM people are hypersensitive: thou must only benchmark in the JVM's best case scenario.

Re: Rust: Not So Great For Codec Implementing

#24

Post by modalduality »

kllrnohj wrote: post #9
modalduality wrote: post #4

Not a Rust expert, but some thoughts on the negatives. > Compilation time is too large Can you try compiling incrementally? https://blog.rust-lang.org/2016/09/08/incremental.html . Might still only be on nightly. > And, on the similar note, benchmarks. I agree, profiling as well isn't as full featured as in more mature languages. Clojure, incidentally has great benchmarking due to being on the JVM. > Also the tuple a…

> Clojure, incidentally has great benchmarking due to being on the JVM. Eh? Benchmarking on the JVM is notoriously difficult bordering on impossible. There's things like Google Caliper but test runs take forever due to attempting to force JIT warmup and doing GCs after every run. And the project's own wiki tells you the results are basically meaningless for a variety of reasons. Benchmarking things like C++ or Rust a…

My bad, I meant profiling, not benchmarking.

Re: Rust: Not So Great For Codec Implementing

#25

Post by spatulon »

bigdubs wrote: post #19
eptcyka wrote: post #10

Whilst unrelated to the article, my complaint about codecs in Rust is that they seem to be slow. Whilst the reason for this might be the immaturity of the libraries that I've used, but they've always been slower than their C counter-parts. The native JPEG decoder spins up 4 threads to decode the same amount of frames at 3x the time as the libjpeg-turbo does. There's a similar story for the FLAC decoder. I don't think…

~fin~

It's still widely used and not considered archaic in British and Australian English.

Re: Rust: Not So Great For Codec Implementing

#27

Post by zanny »

Sean1708 wrote: post #11

> 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.

There is a real change in mentality you have to go through if you transition from a fairly strict C/C++/ even Java background to trying out Rust. In the former languages, adding dependencies rapidly becomes a painful experience, whereas Rust does much better dependency management and automatic building than even Python (where you need a requirements file or something similar to go pull down all the deps).

With Rust, you really should just use crates. The std is meant to be limited to just the most used code and that which should not change for the sake of keeping the ecosystem stable.

Re: Rust: Not So Great For Codec Implementing

#28

Post by bigdubs »

spatulon wrote: post #25
bigdubs wrote: post #19

Earlier quoted context omitted.

~fin~

It's still widely used and not considered archaic in British and Australian English.

https://www.merriam-webster.com/dictionary/whilst

The definition is singularly, "while", with no extra connotation, other than it is as you said chiefly British.

https://trends.google.com/trends/explore?q=while,whilst

"While" is, not surprisingly, much more widely used, "whilst" being more affected.

Re: Rust: Not So Great For Codec Implementing

#29

Post by mastax »

Sean1708 wrote: post #11

> 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.

Some C & C++ programmers are averse to third-party libraries (moreso than other languages in my experience). It's a valid position, but if you really value that then perhaps Rust is not for you.

Re: Rust: Not So Great For Codec Implementing

#30

Post by cwyers »

simias wrote: post #5

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…

> Now this whole section feels a lot like "I'm trying to code in Rust like in C and it doesn't work and it frustrates me".

Who's fault is that?

Rust seems like an attempt to take a lot of foreign concepts to C/C++ programmers and dress them up in ALGOLy syntax. If you look at Rust's influences page[1], there's stuff from ML, Haskell, Erlang... and yet Rust code examples I've seen all look like "slightly weird C++." If Rust wasn't meant to be written like C/C++, it could spend less time aping it and more time looking like languages where you expect to come across ADTs and the like.

1) https://doc.rust-lang.org/reference/influences.html

Post reply on HN