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

151–160 of 231 posts

Re: Why Rust for Low-Level Linux Programming?

#151

Post by gue5t »

digi_owl wrote: post #149
gue5t wrote: post #117

Earlier quoted context omitted.

C does have a standard ABI on each platform (where "platform" is slightly vague, ranging from "a place where people agree to use the SYSV ABI" to "Windows+MSVC"), so you can generally call into C libraries from the same "ecosystem" and not have to notice if they get recompiled between runs; library maintainers can put in some work and make promises about ABI stability. The reason Rust doesn't have a defined ABI is ba…

Or how about we avoid the whole thing and allow multiple versions of a lib to exist, and then prune the branches as they are no longer needed? Something akin to Nix/guix, Gobolinux, or even GNU Stow.

Eventually we will want to do updates, unless you prefer bugs to not. When we do, we'll need strategies to tame the quadratic space blowup caused by lack of sharing across the dependency tree relative to the current model.

Re: Why Rust for Low-Level Linux Programming?

#152

Post by Matthias247 »

pjmlp wrote: post #25
TheMagicHorsey wrote: post #11

Is there any reason why embedded software for autonomous vehicles is still being written in C/C++? This last week I was talking to a friend at a company that makes a small autonomous vehicle. During testing their prototype suddenly went off in a straight line. They had to pull a safety to halt the vehicle or it would have gone straight forever into the Pacific Ocean. Turns out there was an unsafe access to a variable…

Industry standards, certified compilers and cargo cult are usually the main reasons.

I would sum it up in a similar fashion. Another point that should be taken into consideration is that the industry is not really interested in software, and therefore most stuff will be done as it was always done. And now that everything should be based on Autosar (a standardized C-based OS and Giga-framework specification) chances are even lower that anybody looks at saner alternatives.

Rust won't change anything about this, if there would have been interest in changing the situation other alternatives like Ada would have been available for years.

Re: Why Rust for Low-Level Linux Programming?

#153

Post by nwmcsween »

dbaupp wrote: post #142
Bromskloss wrote: post #92

Earlier quoted context omitted.

What are we looking for in the qsort example? Is there a Rust equivalent we should compare to?

The C code is forced to use a function pointer and hence do dynamic virtual calls for each comparison, while Rust and C++ can use generics/templates to get static dispatch (and hence inlining, constant folding etc.). You can see C vs. C++ in http://www.martin-ueding.de/en/programming/qsort/index.html , and Rust is likely to be similar to C++.

LTO will allow qsort to be inlined, etc.

Re: Why Rust for Low-Level Linux Programming?

#154

Post by digi_owl »

gue5t wrote: post #151
digi_owl wrote: post #149

Earlier quoted context omitted.

Or how about we avoid the whole thing and allow multiple versions of a lib to exist, and then prune the branches as they are no longer needed? Something akin to Nix/guix, Gobolinux, or even GNU Stow.

Eventually we will want to do updates, unless you prefer bugs to not. When we do, we'll need strategies to tame the quadratic space blowup caused by lack of sharing across the dependency tree relative to the current model.

Yes, but it means they can be done in the background without disrupting the workflow as much.

Install/build the new version while keeping the old in place, then flip over to the new when ready, and then starting taking out the old one.

Re: Why Rust for Low-Level Linux Programming?

#155

Post by ArkyBeagle »

crypto5 wrote: post #143
ArkyBeagle wrote: post #111

Earlier quoted context omitted.

MISRA is okay. It's not a panacea.

Wiki says it is proprietary..

Yeah, although the principles/rules are in quite public places. It's rather like the ITU standards in that regard - you pay for the documents.

Applying them feels like buying indulgences. :)

Re: Why Rust for Low-Level Linux Programming?

#156

Post by tome »

bjourne wrote: post #33

Performance. Rust is still twice as slow as C ( http://benchmarksgame.alioth.debian.org/u64q/performance.php... ) which is still a fair bit slower than if a skilled assembly programmer had taken on the task. Rust aficionados will say that their compiler is getting better, but so is C. clang has gotten faster than gcc on some benchmarks and on some others gcc has catched up and is now faster than clang again. But what…

> Rust is still twice as slow as C which is still a fair bit slower than if a skilled assembly programmer had taken on the task.

Really? Are there really people who write (a lot of) assembly in order to get code "a fair bit" faster than C? What on earth are they working on?

Re: Why Rust for Low-Level Linux Programming?

#157

Post by burntsushi »

bjourne wrote: post #131
valarauca1 wrote: post #124

Earlier quoted context omitted.

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

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 threaded performance and wonder, maybe there is something more interesting going on than a naive surface analysis of C vs. Rust! :-) https://benchmarksgame.alioth.debian.org/u64/rust.php

And by the way, transliterating a regex library isn't trivial. I invite you to transliterate Tcl's regex library. Let me know how that goes. ;-) So I think your reasoning is specious at best.

Re: Why Rust for Low-Level Linux Programming?

#158

Post by Animats »

CUViper wrote: post #144
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…

Redox may be exactly what you're looking for: http://www.redox-os.org/ And there are others: http://wiki.osdev.org/Rust

Redox is close, but they have pipe-like, rather than call-like, interprocess communications semantics. That means another layer of overhead. More important, it breaks the tight integration between scheduling and interprocess calls required to make a message-passing OS work fast under load.

Here's the QNX architecture document on this, which discusses how message passing and CPU scheduling integrate.[1] Microkernel designers need to read this very carefully. A good test is to run a message-passing benchmark on an idle system, then run it again with a CPU-bound process of equal priority in round-robin mode also running. If the message passing-task starves, or the CPU-bound task starves, message passing was misdesigned. If, on a multiprocessor, a simple message pass causes a CPU switch, message passing was done wrong.

If message passing and scheduling do not play very well together, a service-oriented architecture (sorry, "microservices" architecture) will be sluggish. This is where most microkernels fail.

[1] http://www.qnx.com/developers/docs/6.4.1/neutrino/sys_arch/i...

Re: Why Rust for Low-Level Linux Programming?

#159

Post by pornel »

kazinator wrote: post #133
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…

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?

Like in C you can cast the pointer to an integer and back. Rust allows such hacks if you mark them with a "hold my beer" keyword:

    let the_bits:usize = unsafe { std::mem::transmute(pointer) };
You can also use `std::mem::forget(*pointer)` to avoid fighting with Rust about who manages the memory.

Re: Why Rust for Low-Level Linux Programming?

#160

Post by bogomipz »

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.
Post reply on HN