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

261–270 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#261

Post by steveklabnik »

mook wrote: post #255
steveklabnik wrote: post #143

Earlier quoted context omitted.

Trust me, being available only on nightly does not reduce pressure :) Most of our users use stable, and want to stick to stable. There's just some use-cases that need features we haven't finished designing yet, such is life.

Might very well be; I have the luxury of not looking a nightlies at all :) it's just been frustrating how often problem reports get a response that the solutions are in the nightlies. I suppose it's possible that it's more meant as "it's being worked on" rather than "this is not a real issue, stop complaining", but the acknowledgement that it's actually an issue for people using release builds seem to be missing when…

> I suppose it's possible that it's more meant as "it's being worked on" rather than "this is not a real issue, stop complaining",

Yup, that's absolutely it. I'm not sure of a good, succinct way to imply the former rather than the later...

> it now has a release number much larger than 1.0

We do releases every six weeks, so while it is in some sense, it's also just going to be higher than other languages.

Re: Rust: Not So Great For Codec Implementing

#262

Post by tinus_hn »

nnethercote wrote: post #207
Gankro wrote: post #86

Earlier quoted context omitted.

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

BMP isn't so trivial, largely because it's been extended multiple times while never having a proper spec. http://searchfox.org/mozilla-central/rev/bbc1c59e460a27b2092... has some of the gory details.

And .ico is just .bmp with some extras.

Re: Rust: Not So Great For Codec Implementing

#263

Post by phkahler »

pertymcpert wrote: post #254
phkahler wrote: post #112

Earlier quoted context omitted.

The sizes I mentioned are extremely common in 2d and 3d geometry. This is due to the number of dimensions visible in our world. While someone may want to run 11 dimensional calculations in string theory, there are a large number of common real-world applications of the lengths 2,3,4. In C and C++ you can often use intrinsics but the big 3 - ARM, Intel, PPC - all define them differently. I want this common stuff to be…

Your issue with intrinsics are that the different ISAs have different specs. Fine. But if that was your only issue, then your use case is that you're manually vectoring hot loops correct? Assuming that's true, you want to maximise performance by using as much of the parallelism that vectors give you. So if you're dealing with [4 x int32], on a 128 bit vector ISA you would be fully utilising your vector registers, but…

I want to do math with 2,3, or 4-element vectors. These will typically represent 2d or 3d coordinates or velocities. 4-element vectors may be used for homogeneous coordinates or similar. My point is that these are very common mathematical entities and should be explicitly supported by the language.

How these map to any particular processors resources is not my problem - though the three major vector extensions today all have 4-element vectors. Some support more, but that's not terribly relevant to the math I want to do. A smart compiler could pack multiple small vectors into a wide vector register just like they try to pack multiple scalars in there today.

I am not interested in vectorizing loops. I want to write code like this:

Vec3double position = {5.8,3.9,2.1};

Vec3double velocity = {1.0,0.0,0.0};

double timestep = 0.01;

position += timestep*velocity;

and so on. Yes, I also want the common use case of multiplication of vector and a scalar to be that easy.

Any paint program or graphics library (including font rendering) does a ton of this stuff. So does every 2d or 3d physics engine. Ray tracing. FEA software. CAD. The list of uses for these vector sizes is long and has nothing to do with auto-vectorizing loops. Of course there are plenty of applications where loop vectorization is valuable and I don't want to take anything away from that. I just want built-in support for these common mathematical entities in the base language.

Re: Rust: Not So Great For Codec Implementing

#264

Post by tmzt »

eddyb wrote: post #229
binarycrusader wrote: post #205

Earlier quoted context omitted.

We're going to have to agree to disagree. This is where I actually prefer Go's "vendor" approach to dependencies. It would be great if rust / cargo eventually had the same and more authors adopted it or simply copied their little dependencies instead of having external dependencies on them. Something like this proposed command, except for crate maintenance instead of distribution: https://users.rust-lang.org/t/cargo-…

FWIW `cargo vendor` already exists, just not part of Cargo itself, but rather a tool by one of the core devs. It's even used for releasing the official Rust tarballs as we now employ crates.io dependencies in the standard library and the compiler.

Does it do more than using relative paths in a Cargo.toml would do?

I think this thread is about copying and pasting code versus using a small library in the Go case, which might be a philosphical difference with Rust.

It might help to point out that vendored crates are compiled from source making the required review process referenced by that poster just as possible with server crates.

Re: Rust: Not So Great For Codec Implementing

#265

Post by davemp »

nwmcsween wrote: post #217
davemp wrote: post #154

Earlier quoted context omitted.

> Special registers are just slots at specific memory addresses. > As far as the rest is concerned, not a single language in the world will provide you with primitives for that and make them portable across a thousand architectures with a million different peripherals. I'm well aware, that's why I said. > When you're dealing with the hardware architecture level you need more detail than C (or any PL) can reasonably p…

> A language does not need to provide every hardware primitive, just realize that it can't and implement a sane way to support hardware features that don't require abusing a cumbersome macro system and heavy compiler modification. The information has to somehow be passed to the compiler, your options are: compiler specific features (see gcc attributes, etc), language level (see the fun that becomes with explicit_mems…

You're right, most of these problems stem from companies extending the Garbage C Compiler that encourages abuse of C's awful macro system to cover up its poor decisions.

Re: Rust: Not So Great For Codec Implementing

#266

Post by tmzt »

test9753 wrote: post #235
gwbas1c wrote: post #160

Earlier quoted context omitted.

Yes, that chapter painfully explains my point. Most of the replies pointed out the new ? operator, which I'll have to check out. (One of the things that I like about the Rust community is that they constantly improve.) The thing is, if you've only handled errors via return codes in C, then Rust's system is a major improvement. The challenge comes once you've programmed with exceptions that have inheritance. It's pret…

Existing error handling facilities in Rust may not suit every use-case. For me personally, the difficulty with the `?` operator (and try! macro) is that the File + Line info about the source of error is lost. Also, I want something simpler than the approach taken by the `error-chain` crate. My current solution is to use some custom macros to check for errors and display an execution trace (example here: https://play.…

Does rust have __FILE__ etc.? Special constants?

Re: Rust: Not So Great For Codec Implementing

#267

Post by mook »

steveklabnik wrote: post #261
mook wrote: post #255

Earlier quoted context omitted.

Might very well be; I have the luxury of not looking a nightlies at all :) it's just been frustrating how often problem reports get a response that the solutions are in the nightlies. I suppose it's possible that it's more meant as "it's being worked on" rather than "this is not a real issue, stop complaining", but the acknowledgement that it's actually an issue for people using release builds seem to be missing when…

> I suppose it's possible that it's more meant as "it's being worked on" rather than "this is not a real issue, stop complaining", Yup, that's absolutely it. I'm not sure of a good, succinct way to imply the former rather than the later... > it now has a release number much larger than 1.0 We do releases every six weeks, so while it is in some sense, it's also just going to be higher than other languages.

> Yup, that's absolutely it. I'm not sure of a good, succinct way to imply the former rather than the later...

Personally, a sentence saying something to that effect (i.e. showing that it's understood that it doesn't immediately hello just yet) would be sufficient. It would probably get tiring every time nightlies are mentioned, though, but it means people (like me) who randomly land on a thread would know that the problems are acknowledged.

> We do releases every six weeks, so while it is in some sense, it's also just going to be higher than other languages.

Right, but the problem is that the rest of the world has expectations on those numbers (e.g. x.0 is probably buggy, >0.x is a thing external people are expected to be able to use). The particular minor version number doesn't matter as much. That ship has sailed (and probably circumnavigated the world a few times) though.

The biggest problem is probably that I'm comparing it to golang, which was the last 1.x language I learned, and that had a more complete standard library by 1.0. Again, likely the effect of the much more open development model (no baking behind closed doors).

Re: Rust: Not So Great For Codec Implementing

#268

Post by mook »

kbenson wrote: post #258
mook wrote: post #255

Earlier quoted context omitted.

Might very well be; I have the luxury of not looking a nightlies at all :) it's just been frustrating how often problem reports get a response that the solutions are in the nightlies. I suppose it's possible that it's more meant as "it's being worked on" rather than "this is not a real issue, stop complaining", but the acknowledgement that it's actually an issue for people using release builds seem to be missing when…

> I suppose it's possible that it's more meant as "it's being worked on" rather than "this is not a real issue, stop complaining", but the acknowledgement that it's actually an issue for people using release builds seem to be missing whenever nightlies are brought up in these sorts of responses. I think that's the right assumption, because it's an acknowledgement that the issue actively being worked on to the degree…

Yeah, I appreciate that nightlies are an option. It's just frustrating how often that option is trotted out without the caveat that it isn't a real solution. (This is again basically reacting to a particular Reddit comment linked above, but those sorts of comments are things that are more memorable.)

Actually interacting with rust-related people, whatever their capacity (developer, user, etc.) tend to go pretty well; it's just that once in a while a random comment shows up that seems dismissive of actual problems people are reporting.

You're probably right though, it's just that people have different contexts and I'm reading more into things than intended. Again, rust development is extremely open (which is great) and these things just tend to not be visible for other languages, rather than not happening.

Re: Rust: Not So Great For Codec Implementing

#269

Post by steveklabnik »

tmzt wrote: post #266
test9753 wrote: post #235

Earlier quoted context omitted.

Existing error handling facilities in Rust may not suit every use-case. For me personally, the difficulty with the `?` operator (and try! macro) is that the File + Line info about the source of error is lost. Also, I want something simpler than the approach taken by the `error-chain` crate. My current solution is to use some custom macros to check for errors and display an execution trace (example here: https://play.…

Does rust have __FILE__ etc.? Special constants?

https://doc.rust-lang.org/stable/std/macro.file.html

https://doc.rust-lang.org/stable/std/macro.line.html

https://doc.rust-lang.org/stable/std/macro.column.html

Re: Rust: Not So Great For Codec Implementing

#270

Post by nwmcsween »

burntsushi wrote: post #141
nwmcsween wrote: post #62

Earlier quoted context omitted.

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.

There are thousands of vendor intrinsics and no compiler that I'm aware of is able to just automatically use all of them in a reliable way. The idea that "Rust needs explicit SIMD due to bounds checking" is very wrong.

Because SIMD ins throughput is highly processor specific? Rust will also not 'automatically use all of them' there is no magic abstraction would make any compiler use some of the really fancy and useful SIMD ins.
Post reply on HN