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

Why Rust for Low-Level Linux Programming?

groveronline.com

Post reply on HN
Print view View original

161–170 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#161

Post by gdwatson »

korethr wrote: post #145
kazinator wrote: post #133

Earlier quoted context omitted.

C gets out of the way and lets you do useful things that are "undefined behavior". How convenient is it it Rust, to, say, use the unused bits in a pointer (due to alignment) and put a type tag in them?

Okay, now you've piqued my curiosity. Is that something to do because it's really smart and clever and fun, or is there a certain problem or class of problems where doing that is unambiguously the best or least-worst solution?

As to3m says, this is often done in programming language interpreters.

If most objects in your language were heap allocated and you want to store a small integer you would allocate a new object on the heap with space for one integer, set up its headers, etc. You could instead set one of the unused bits in the pointer to indicate that it's an integer and not a pointer, then store the integer in the remaining bits, avoiding the heap allocation at all. The Lisp world calls this a fixnum.

The more pointer bits you can steal, the more kinds of data you can store directly in the "pointer" itself. It's also possible to store the type of objects that are actually allocated on the heap in tags on the pointers to them, but I don't know if that's done any more.

Re: Why Rust for Low-Level Linux Programming?

#162

Post by steveklabnik »

bogomipz wrote: post #160
ktamura wrote: post #4

As a long-time developer marketing person, I must say Rust is kicking ass, not just as a language but as a community. They are deeply strategic. 1. Clear audience target: They aren't going after C++ gurus or C magicians but people who are new to systems programming. From Klabnik to Katz to literally everyone in the community, they are consistent with this messaging. 2. As part of 1, they have invested a lot in teachi…

Can you give an example of 2? Where have they invested in teaching systems programming 101? Is there a specific blog? Thanks.

The Rust book has this chapter, for example: http://doc.rust-lang.org/stable/book/the-stack-and-the-heap....

Re: Why Rust for Low-Level Linux Programming?

#163

Post by igouy »

bjourne wrote: post #134
nemothekid wrote: post #128

Earlier quoted context omitted.

> I didn't cherry-pick; in 5/10 benchmarks, C is twice as fast as Rust. Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me. In 5/10 benchmarks, the benchmark games claims Go has equal if not better performance than Rust. Am I supposed to believe now, that a managed, garbage collected, 6-year-old compiler, language is as fa…

> Making the claim that C is twice as fast as Rust because of 5/10 benchmarks in the "benchmark game" shows an incredible lack of common sense to me. Actually, 2x is likely the lower bound of how much faster well-written C is over Rust. Rust developers have an interest in promoting their language so they will make sure their test programs runs as fast as possible. C doesn't need that kind of marketing. For example, t…

>> For example, the Rust solutions were all updated in 2015 while the C solutions hasn't been touched since 2013.

Not true:

    Jun 02, 2016    revcomp.gcc-6.gcc
    Apr 13, 2016    fasta.gcc-7.gcc
    Sep 26, 2015    revcomp.gcc-5.gcc
    Oct 01, 2014    fannkuchredux.gcc-5.gcc
    Apr 27, 2014    fastaredux.gcc-5.gcc
    Apr 08, 2014    mandelbrot.gcc-9.gcc
    Jan 19, 2014    mandelbrot.gcc-7.gcc
(There may have been others that have subsequently been removed.)

Re: Why Rust for Low-Level Linux Programming?

#164

Post by naasking »

korethr wrote: post #145
kazinator wrote: post #133

Earlier quoted context omitted.

C gets out of the way and lets you do useful things that are "undefined behavior". How convenient is it it Rust, to, say, use the unused bits in a pointer (due to alignment) and put a type tag in them?

Okay, now you've piqued my curiosity. Is that something to do because it's really smart and clever and fun, or is there a certain problem or class of problems where doing that is unambiguously the best or least-worst solution?

Haskell does it automatically as an optimisation: if an algebraic type has fewer than 2-3 cases, then it inline the tag bits directly into the pointer, thus saving an indirection on pattern match.

Some C data structures also make use of low level bit tricks like this to save space and reduce indirections. For instance, the hash-array mapped Trie uses a 32 bit mask to both track which indices of the current node are actually populated, and incidentally, how large the node currently is. It's quite clever.

These are always my foot examples to evaluate any alleged systems programming language. No language less powerful than a theorem prover is currently capable of expressing these idioms safely.

Re: Why Rust for Low-Level Linux Programming?

#165

Post by naasking »

Animats wrote: post #118

Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch…

L4.sec is already formally verified. So the microkernel is already done. You need the user land services to provide POSIX compatibility, and that you can possibly do in Rust.

Re: Why Rust for Low-Level Linux Programming?

#166

Post by naasking »

ArkyBeagle wrote: post #102
kbenson wrote: post #87

Earlier quoted context omitted.

Given Ada's history in safety critical systems (avionics), it's actually somewhat surprising more didn't use Ada. They could have just adopted the military standard (which is fairly stringent, as I understand it). The military is pretty adverse to losing billion dollar pieces of equipment, so they probably take quite a few precautions.

You got me as to why this is. Dude, I tried back in the day - Ada, MODULA, all those. Maybe the "badass 'C' hax0r" meme was stronger than I realized. But I think a lot of it was just switching cost.

To be fair, Ada has a lot of library cruft for dynamically sized structures that you don't have to deal with in C. It can be pretty annoying.

Re: Why Rust for Low-Level Linux Programming?

#167

Post by igouy »

valarauca1 wrote: post #124
bjourne wrote: post #110

Earlier quoted context omitted.

> This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. Cool. Let's call that language with SIMD and inline assembly support FutureRust(tm) to differentiate it from the currently released and available Rust. We can have a discussion about how fast FutureRust will be vs C, but this discussion is about Rust vs C. Or rather clan…

>In 5 of 10 benchmarks, C is twice as fast as Rust fannkuch-redux why? SIMD fasta-redux why? SIMD spectral-norm why? SIMD reverse-complement why? SIMD N-Body why? Oh you guessed it SIMD Seriously read the source code. Remember on HN where a lot of people constantly say the benchmark game is really crappy. This is why. All 5 of these tests boil down to raw FLOPS. Which C/C++ having access to SIMD instructions wins at.…

>> fannkuch-redux why? SIMD

Look how many other programs, written in various languages, are shown ahead of the fannkuch-redux Rust #2 program.

Maybe you can write a better Rust fannkuch-redux program (even without SIMD).

Re: Why Rust for Low-Level Linux Programming?

#168

Post by steveklabnik »

naasking wrote: post #165
Animats wrote: post #118

Rather than writing for Linux in Rust, we need a new kernel written in Rust. I'd like to see a replacement for the QNX microkernel written in Rust. It's about 60K bytes of code, yet you can run POSIX programs on it. (You need file system and networking, which are user processes.) The QNX kernel is stable - it changes very little from year to year. There's hope of catching all the bugs. This offers a way out of "patch…

L4.sec is already formally verified. So the microkernel is already done. You need the user land services to provide POSIX compatibility, and that you can possibly do in Rust.

https://robigalia.org/

Re: Why Rust for Low-Level Linux Programming?

#169

Post by igouy »

valarauca1 wrote: post #124
bjourne wrote: post #110

Earlier quoted context omitted.

> This difference on this test is caused by Rust not having stabilized SIMD support. Also Rust support hand rolled assembly (on nightly) that C has. Cool. Let's call that language with SIMD and inline assembly support FutureRust(tm) to differentiate it from the currently released and available Rust. We can have a discussion about how fast FutureRust will be vs C, but this discussion is about Rust vs C. Or rather clan…

>In 5 of 10 benchmarks, C is twice as fast as Rust fannkuch-redux why? SIMD fasta-redux why? SIMD spectral-norm why? SIMD reverse-complement why? SIMD N-Body why? Oh you guessed it SIMD Seriously read the source code. Remember on HN where a lot of people constantly say the benchmark game is really crappy. This is why. All 5 of these tests boil down to raw FLOPS. Which C/C++ having access to SIMD instructions wins at.…

>> Remember on HN where a lot of people constantly say the benchmark game is really crappy. This is why.

Because the benchmarks game shows some programs to be faster, and you agree those programs actually would be faster? :-)

>> All 5 of these tests boil down to raw FLOPS.

Where exactly are the floating-point operations in fannkuch-redux Rust #2 program ?

Where exactly are the floating-point operations in reverse-complement ?

("Seriously read the source code" ?)

Re: Why Rust for Low-Level Linux Programming?

#170

Post by igouy »

burntsushi wrote: post #157
bjourne wrote: post #131

Earlier quoted context omitted.

Rust is also slower in binarytrees, regexdna and fasta. SSE is not one "barely used corner case" because huge amounts of performance critical code takes advantage of it. Edit: To explain why I don't believe you when you say that "Post compilation they are functionally identical [in performance]" is because if it were so, you would just transliterate the C solutions to the Rust equivalents and it would run as fast as…

Did you know Rust was quite a bit faster than C in regexdna merely a few months ago? It didn't get slower because of Rust. The algorithms employed are radically different. My hope is that the regex library has already regained performance, but until the benchmark game is updated (which is on us, not the benchmark game maintainer), I suppose we'll have to suffer the pedants! Or perhaps, you might look at single thread…

Please don't point people to u64 -- it's no longer updated. (Note the rustc version.)
Post reply on HN