31–40 of 86 posts
I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decoding a tiny JPG image took 2 seconds with his code. How is that "performant" by any definition?
I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decoding a tiny JPG image took 2 seconds with his code. How is that "performant" by any definition?
One common pitfall is not turning the optimiser on (with --release for cargo) i.e. benchmarking a debug build rather than a release one, and from a quick glance this code looks like it may be doing a system call to read each and every byte of the file due to the use of .bytes() on an unbuffered file, whereas it would be better to use, say, read_to_end to read many bytes of the file at once.
I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decoding a tiny JPG image took 2 seconds with his code. How is that "performant" by any definition?
After fixing it, it apparently runs in 100 ms.
I don't know rust, but what happens if you get a 0xff as the last byte here, wouldn't i+1 go out of array bounds? while i
I find myself wanting to walk an iterator pairwise regularly for stuff like this and I'm using:
for (cur, next) in (& vec).iter().zip(vec.iter().skip(1)) {
encoded_data.push(cur);
if cur == 0xff && next == 0x00 {
// ...
}
}
I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decoding a tiny JPG image took 2 seconds with his code. How is that "performant" by any definition?
I don't know rust, but what happens if you get a 0xff as the last byte here, wouldn't i+1 go out of array bounds? while i
Since Rust people are reading this. I find myself wanting to walk an iterator pairwise regularly for stuff like this and I'm using: for (cur, next) in (& vec).iter().zip(vec.iter().skip(1)) { encoded_data.push(cur); if cur == 0xff && next == 0x00 { // ... } } Is there a better way to write this? What I'd really like is the equivalent to Clojure's partition[1]. I know that the stdlib has windows `(partition n (dec n)…
I don't know rust, but what happens if you get a 0xff as the last byte here, wouldn't i+1 go out of array bounds? while i
Since Rust people are reading this. I find myself wanting to walk an iterator pairwise regularly for stuff like this and I'm using: for (cur, next) in (& vec).iter().zip(vec.iter().skip(1)) { encoded_data.push(cur); if cur == 0xff && next == 0x00 { // ... } } Is there a better way to write this? What I'd really like is the equivalent to Clojure's partition[1]. I know that the stdlib has windows `(partition n (dec n)…
Earlier quoted context omitted.
It's not, but they're both ML-family languages. I had hoped that Rust would be able to offer a similar level of elegance to Scala.
The biggest difference between Scala and Rust here is ".iter()", which is necessary mainly because you need to specify whether the iterator iterates over references (".iter()") or passes results by value (".into_iter()"). Because Java doesn't have value types and has no concept of move semantics, it has no need for the distinction, while Rust does. In effect, the "elegance" of Scala here is really the product of its…
I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decoding a tiny JPG image took 2 seconds with his code. How is that "performant" by any definition?
I am having some trouble reproducing the 2 seconds number, but with optimizations I'm getting around 1.5 seconds (without, I'm up to 5!), and as balducien mentions, /u/DroidLogician pointed out a _huge_ performance flaw in the file reading code.
Writing bad code is easy in any language (as I just showed :) - writing _super_ performant code is only possible in some.
EDIT: I made a pretty bad mistake while writing this comment, claiming that fixing the file reading code improved the speed of the decoder _a lot_, which was not true at all. In fact, the difference is barely (if at all) noticeable when decoding lena.jpeg. However, when reading a larger file, the improvement is definitely there. So sorry! Replying to HN comments while drinking and watching a movie turns out not to be a great idea after all :)
I feel like i'm missing something. In the "Why" section he claims that Rust is a performant language with a low-level feel. In this part, he claims that decoding a tiny JPG image took 2 seconds with his code. How is that "performant" by any definition?
Somebody on reddit found the bottleneck: https://www.reddit.com/r/rust/comments/4yinbt/writing_a_jpeg... After fixing it, it apparently runs in 100 ms.