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

211–220 of 283 posts

Re: Rust: Not So Great For Codec Implementing

#211

Post by test9753 »

cbhl wrote: post #87
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…

Have you tried Halide? http://halide-lang.org/ I've seen it used for various video/photo processing operations.

Off-topic: the "Halide Talk" video in that page was very good: https://www.youtube.com/watch?v=3uiEyEKji0M

Re: Rust: Not So Great For Codec Implementing

#212

Post by smitherfield »

jandrese wrote: post #163
adrianratnapala wrote: post #151

Earlier quoted context omitted.

These things originate in hardware variations. Apparently all architectures use binary the same way so unsigned overflow just drops the MSB. But signed integers aren't always two's complement, so there is variation. See, no tedious rules to remember, you just have to understand how computers work. But the C standards call such things "undefined behaviour" rather than "platform specific" behaviour, and then try to pre…

I wonder how many processors there are in use these days that don't use 2s complement. I don't think I've ever seen one.

The bigger reason it's still undefined is to enable this type of optimization: https://news.ycombinator.com/item?id=14857316

Re: Rust: Not So Great For Codec Implementing

#213

Post by dbaupp »

jschwartzi wrote: post #208
dbaupp wrote: post #178

Earlier quoted context omitted.

I didn't denigrate C++, I'm specifically talking about the behaviour of the data types/mention of OOP which is orthogonal to the surface syntax like using symbolic operators instead of textual names. It is factual that the default data declaration in C++ has a little of the "pointer soup" due to methods and `this`. This can often get inlined away and so is usually irrelevant (hence "almost so"), but the poster did em…

You could also wrap a reference to a plain old struct and operate on it using a class. That's often how I write C++ when I need to be explicit about how the data is structured. Not everything in C++ requires an OO approach. OP was specifically recommending operator overloading on a plain old struct, which can be done without declaring a class. Indeed, operator overloads can be declared as global functions in C++. The…

I think you're also missing my point. Techniques like what you describe are exactly what I was referring when I said "C++ possess[es] ways" and "using friends rather than methods", although you don't even need a wrapper for a reference (which is actually a pointer, and so also part of what I mean by "pointer soup"!) for this sort of code: just the struct works fine (although a `class` does too, the only difference is the `struct` keyword has different privacy defaults).

The only "downgrade" I made was saying that it is only "almost" the default in C++, versus the other two where they are completely the default.

To be clear, like C and Rust, C++ has great semantic attributes for this sort of thing:

- classes/structs that don't require allocation/pointers

- precise control over pass-by-value (for everything except the `this` pointer of methods)

- pervasive static dispatch of methods/functions (including operators, which can be considered to be method/function with an unusual name and call syntax)

The only downside, and the reason I said "almost" (which is what the C++ETF (C++ Evangelism Task Force) seems to be up in arms about), is methods are what most people reach for by default and so the `this` pointer comes into play. But as you point out, and as I implied in my original comment, this isn't required, just the default.

Re: Rust: Not So Great For Codec Implementing

#214

Post by pcwalton »

binarycrusader wrote: post #205
pcwalton wrote: post #124

Earlier quoted context omitted.

Again, that's what the Rust Platform is for. It's a better solution than copying code, because it doesn't throw away all of the benefits of Cargo just to make some legal policies at some large companies a little easier.

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

I sincerely hope that people never start copying code into their packages. I see virtually no upsides, except for making it easier to dodge bureaucratic hurdles at some big companies, and a huge number of downsides (basically forgoing all the benefits of Cargo).

Re: Rust: Not So Great For Codec Implementing

#215

Post by krallja »

sitkack wrote: post #197
cryptonector wrote: post #179

Earlier quoted context omitted.

Yes, that's right, and multiple compilers support the Windows C++ ABI. You still couldn't write portable C++ in C or assembly (or anything else not C++). Does anyone write C or assembly to that ABI? Probably not, though to be fair that's probably in large part because if you're going to do that you might as well write in C++ :^) Still, I think a public and stable ABI with fine-grained control of binary elements is a…

I would like a declarative language for laying out the heap, stack, objects, etc. Why have one ABI and not an ABI configuration protocol? Would love to share data structures between languages w/o having to write serializers.

You can't just wake up and decide to be Don Box like that!

Re: Rust: Not So Great For Codec Implementing

#216

Post by Sharlin »

_5ysi wrote: post #196
camgunz wrote: post #101

Earlier quoted context omitted.

I can't speak for the author of course, but probably their argument is that a systems language should be able to directly manipulate bits and bytes without outside dependencies. I don't know that I agree. A reasonable counter example is that you need library support to allocate memory in C. The argument is that it's a feature to not require C implementations to include dynamic memory allocation because not all projec…

You don't need a library to allocate memory in C. For example on Linux, use sbrk() system call to grow the heap, then start using it. But your larger point still stands.

I think that the point was more that heap allocation is not a standard language primitive in C. And indeed, it would be ludicruous to require dynamic allocation support from freestanding implementations (no standard library because typically your platform doesn't even have an OS).

Re: Rust: Not So Great For Codec Implementing

#217

Post by nwmcsween »

davemp wrote: post #154
wott wrote: post #138

Earlier quoted context omitted.

> C doesn't "let you do what you mean", it has no knowledge of special registers, interrupts, timers, DMA, etc. 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. That's the role of libraries and OSes with…

> 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_memset vs. memset) or a really fancy IR that can hold these types of requirements.

Re: Rust: Not So Great For Codec Implementing

#218

Post by sitkack »

Animats wrote: post #32

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…

.split_at_mut is a method on a slice ... one is free to implement their own abstractions that ultimately terminate in an unsafe { block } that enable multiple mutable borrows.

   fn split_at_mut(&mut self, mid: usize) -> (&mut str, &mut str) {
		// is_char_boundary checks that the index is in [0, .len()]
		if self.is_char_boundary(mid) {
			let len = self.len();
			let ptr = self.as_ptr() as *mut u8;
			unsafe {
				(from_raw_parts_mut(ptr, mid),
				 from_raw_parts_mut(ptr.offset(mid as isize), len - mid))
			}
		} else {
			slice_error_fail(self, 0, mid)
		}
	}
this is literally the src to .split_at_mut Make your own version. Rusts power isn't what it enables, it is what it removes, undefined behavior, false sharing, etc. Frankly, I am tired of C/C++ programmers complain about Rust. This is a non-starter. I am happy to convert the F#, Haskell, OCaml, Scala and Clojure devs to Rust. Systems programming isn't magic.

Re: Rust: Not So Great For Codec Implementing

#219

Post by aidenn0 »

cryptonector wrote: post #179
adrianratnapala wrote: post #150

Earlier quoted context omitted.

On particular platforms they have nailed down the C++ layout enough to make this possible. I think windows did it for COM (or DCOM?). But in general you are right. On of the most infuriating things about fancy languages is the way they all have their own ABIs. I mean it's nice that they support special features through those ABIs, but standardized vtables and dictionaries would take us a long way. And Kudos to Micros…

Yes, that's right, and multiple compilers support the Windows C++ ABI. You still couldn't write portable C++ in C or assembly (or anything else not C++). Does anyone write C or assembly to that ABI? Probably not, though to be fair that's probably in large part because if you're going to do that you might as well write in C++ :^) Still, I think a public and stable ABI with fine-grained control of binary elements is a…

As a counterpoint, PowerPC has at least 3 mutually incompatible ABIs for C.

Re: Rust: Not So Great For Codec Implementing

#220

Post by test9753 »

steveklabnik wrote: post #89
Manishearth wrote: post #80

Earlier quoted context omitted.

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

Found this paper useful: "The Case for Writing a Kernel in Rust" (https://www.tockos.org/assets/papers/rust-kernel-apsys2017.p...) linked from the "tock os" blog post: https://www.tockos.org/blog/2017/apsys-paper/
Post reply on HN