Eclipse Corrosion (Rust IDE) on RPi

[clicky]

Given this: viewtopic.php?f=81&t=276291
and fact I decided to learn rust (programming language) I've set up new instance of Eclipse and installed Eclipse Corrosion directly of marketspace...

All seems to be working well including Eclipse familiar debugging and variables inspectors (screenshot attached here)

[Heater]

I have never been into Eclipse much. It always seemed so big, slow and complicated when I have had to use it on various projects. But this looks pretty cool.

How are you getting on with Rust? I have been getting into Rust, slowly, for nearly a year. It's been fascinating if somewhat frustrating at times. It's amazing how one can get code to run as fast as C and C++ whilst being sure you have no weird memory usage errors creeping in.

One thing that sold me on Rust, again, a few days ago was the ease with which one could get code to distribute work over many cores and get a commensurate performance boost. For example:

Code: Select all

    pub fn dot_product(xs: &[f32], ys: &[f32]) -> f32 {
        xs.iter()
            .zip(ys)
            .fold(Fast(0.), |acc, (&x, &y)| acc + Fast(x) * Fast(y))
            .get()
    }

    pub fn convolution_serial(sample: &[f32], coeff: &[f32]) -> Vec<f32> {
        sample
            .windows(coeff.len())
            .map(|window| dot_product(window, coeff))
            .collect()
    }

    pub fn convolution_parallel(sample: &[f32], coeff: &[f32]) -> Vec<f32> {
        sample
            .par_windows(coeff.len())
            .map(|window| dot_product(window, coeff))
            .collect()
    }

Can you spot the difference between the serial and parallel versions of convolution there?
Magic!

[clicky]

I have never been into Eclipse much. It always seemed so big, slow and complicated when I have had to use it on various projects. But this looks pretty cool.

I've lived through rise and fall of Eclipse and how people slated it while alternatives weren't any better...
Now, I appreciate it even more than before: IntelliJ (and PyCharm in that respect) UI is slower than SWT Eclipse use and IntelliJ's scan, rebuild, setup to run set of steps are visibly slower than Eclipse's compiler. Maybe on the latest laptops/desktops it makes no difference, but here on RPi it is difference between comfortable and bearable.

As per Rust support - I am not overly impressed (and I have nothing to compare with). it does mark errors and warnings almost correctly, provides with feedback on hovering mouse over them (but no auto-fix suggestions) and, that is really cool, it does breakpoints and variable inspections on them quite well. There are a few little things missing in comparison to same Java stuff (refactoring in Rust is only rename, formatting code while typing is not quite there, etc), but I would rather have Eclipse than VS Code where I would need to remember all commands I should type if I want to do anything...

How are you getting on with Rust? I have been getting into Rust, slowly, for nearly a year. It's been fascinating if somewhat frustrating at times. It's amazing how one can get code to run as fast as C and C++ whilst being sure you have no weird memory usage errors creeping in.

Actually, today is my second day really. I've managed (just) to port my Python code which was quite OO (StreamField extended to StreamByteField, StreamWordField, ... with StreamDefinition having list of StreamFields where StreamField defines some behaviour like to_json() and then re-implemented in specific fields) with 'not-that-many-repetitions'
Also, failed to make constructor at the same time as ability chain methods - there are still quite a few hidden corners for me...

Can you spot the difference between the serial and parallel versions of convolution there?
Magic!

Yes, I can see it! It pretty much re-assembles Java's streams (and, I am sure many other languages' similar concepts). I had some feeling that people who wrote some of Rust libraries did they homework well and made quite a few functional(-alike) stuff built in. So, I am quite excited to learn more. And, thanks for the example - you won't believe how much more I've learnt from it, too!

[Heater]

...thanks for the example - you won't believe how much more I've learnt from it, too!

Wow, that is nice to hear.

Thing is for a long time I have been writing Rust like I write C. I have almost no experience of "functional" programming and was never sold on the "everything in OOP" of the likes of Java which is just a silly idea.

During a number of conversations over on the rust-lang forum about bits of code I was writing people always suggested I adopt the "functional" idiomatic Rust style.

Problem was, the functional style solutions they suggested were verbose, obfuscated and worst of all slow! I was not buying it.

But that example I gave above is the result of one such discussion: https://users.rust-lang.org/t/rust-perf ... tion/44075. After another round of verbose, obfuscated and functional style slow suggestion we arrived at that. Which I think is short, sweet, poetry. And runs faster than C

I guess I should say that the "Fast" used in that example comes from the fast-float crate and ensures the compiler generates vector instructions for a speed boost. Then the "par_windows" thing comes from the rayon crate which parallelizes the work.

[clicky]

I can see so many different concepts meeting in Rust: strong typing; compilation to fast, c-alike low level; functional style and innovative memory handling (at compiler level - memory handling of Rust seems just 'standard', well known, common sense stuff) and such...

That functional style code, in theory, is supposed to be very 'optimisable' at a few different levels - not saying that all languages (and all libraries and such) always do so... I would be nice to have confirmation that Rust does them

[Heater]

... memory handling of Rust seems just 'standard', well known, common sense stuff...

That is a surprising statement to me.

I have never seen any other programming language with the approach to memory that Rust has. What with it's rules about multiple aliases to variables, the "borrow checker", no garbage collector and all that. As far as I know this is all very new.

That functional style code, in theory, is supposed to be very 'optimisable' at a few different levels - not saying that all languages (and all libraries and such) always do so... I would be nice to have confirmation that Rust does them

I have read things like that many times. Problem is it is by no means always true. As I said, I have received many suggestions for "functional" style solutions to my Rust experiments. Mostly the suggestions were slower that what I had already and impossible to read as well. Do have a read of that rust-lang thread for some good (bad) examples.

What I found is that if you write Rust in a C style with typical arrays and "for" loops it will be slower than C. Because it has to add run-time array bounds checking and it cannot use vector instructions as a consequence.

You can reach C speeds by helping Rust with those array bounds. Use slices for example. Like this version of the convolution:

Code: Select all

    pub fn convolution_safe(sample: &[f32], coeff: &[f32]) -> Vec<f32> {
        let mut out: Vec<f32> = vec![0.0; sample.len() - coeff.len() + 1];
        for i in 0..out.len() {
            let mut acc: f32 = 0.0;
            let window = &sample[i..i + coeff.len()];
            for j in 0..window.len() {
                acc += window[j] * coeff[j];
            }
            out[ i ] = acc;
        }
        out
    }

That runs as fast as C and as fast as the functional Rust style above.

But... It's much easier to parallelize the functional style version that this "C" style.

[clicky]

... memory handling of Rust seems just 'standard', well known, common sense stuff...

That is a surprising statement to me.

I have never seen any other programming language with the approach to memory that Rust has. What with it's rules about multiple aliases to variables, the "borrow checker", no garbage collector and all that. As far as I know this is all very new.

I'm sorry I might have mislead you with my statement. Approach to memory handling in Rust is same (similar) as with other languages - allocating structs on stack or heap - nothing new there. But, how references and values are tracked at compile time - that's completely new and original.

That functional style code, in theory, is supposed to be very 'optimisable' at a few different levels - not saying that all languages (and all libraries and such) always do so... I would be nice to have confirmation that Rust does them

I have read things like that many times. Problem is it is by no means always true.

Yeah, hence my hope I'll be able to confirm that it is better with some Rust libraries...

As I said, I have received many suggestions for "functional" style solutions to my Rust experiments. Mostly the suggestions were slower that what I had already and impossible to read as well. Do have a read of that rust-lang thread for some good (bad) examples.

Yeah, it is so easy to lose track of what is really happening to code when people move one level up...

What I found is that if you write Rust in a C style with typical arrays and "for" loops it will be slower than C. Because it has to add run-time array bounds checking and it cannot use vector instructions as a consequence.

You can reach C speeds by helping Rust with those array bounds. Use slices for example. Like this version of the convolution:

pub fn convolution_safe(sample: &[f32], coeff: &[f32]) -> Vec<f32> {
let mut out: Vec<f32> = vec![0.0; sample.len() - coeff.len() + 1];
for i in 0..out.len() {
let mut acc: f32 = 0.0;
let window = &sample[i..i + coeff.len()];
for j in 0..window.len() {
acc += window[j] * coeff[j];
}
out = acc;
}
out
}

That runs as fast as C and as fast as the functional Rust style above.

I'm yet to get that far!

[jahboater]

I have never seen any other programming language with the approach to memory that Rust has. What with it's rules about multiple aliases to variables,

It is the "restrict" keyword in C.

[Paeryn]

I have never seen any other programming language with the approach to memory that Rust has. What with it's rules about multiple aliases to variables,

It is the "restrict" keyword in C.

Except that in C restrict is basically just a hint to the compiler that anything accessed through a restricted pointer cannot be accessed via any other restricted pointer (within scope) and the compiler can generate code that assumes so. C will not enforce it, it will happily let you have two restricted pointers that access the same variable (or memory locations) at the same time and if you do that, it immediately becomes undefined behaviour.

[Heater]

I have never seen any other programming language with the approach to memory that Rust has. What with it's rules about multiple aliases to variables,

It is the "restrict" keyword in C.

The "restrict" keyword in C does not do anything for enforcing rules about pointers aliasing the same data or preventing multiple references to that same shared mutable data. It is only a hint to the compiler that it can assume pointers do not refer to the same data so that it might perform optimizations it might otherwise not do.

If one uses "restrict" but still uses pointers to create shared mutable data C does not complain. It just goes ahead and computes the wrong results. It is undefined behavior.

Rust will not let you get into such a mess. I have never seen any other programming language with this feature.

I have never seen use of "restrict" actually cause any performance increase. gcc and clang just optimize anyway.

"restrict" in C is such a broken feature that coding standards forbid it's use:
MISRA: http://my.ldrasoftware.co.uk/repository ... liance.pdf
SEI CERT: https://wiki.sei.cmu.edu/confluence/dis ... d+pointers
Sonar: https://rules.sonarsource.com/c/RSPEC-1836

As an example, the original C code for the Rust examples here is:

Code: Select all

void convolution(float *out, int *out_length, const float *sample, int samplelen, const float *coeff, int coefflen) {
    int outlen = samplelen - coefflen + 1;
    for (int i = 0; i < outlen; i++) {
        float acc = 0.;
        for (int j = 0; j < coefflen; j++) {
            acc += sample[i + j] * coeff[j];
        }
        out[i] = acc;
    }
    *out_length = outlen;
}

Adding "restrict" to those pointer parameters doe not prevent one calling this function with overlapping arrays, you just get the wrong result if you do.

It also does not do anything for optimization.

[ejolson]

I have never been into Eclipse much. It always seemed so big, slow and complicated when I have had to use it on various projects. But this looks pretty cool.

How are you getting on with Rust? I have been getting into Rust, slowly, for nearly a year. It's been fascinating if somewhat frustrating at times. It's amazing how one can get code to run as fast as C and C++ whilst being sure you have no weird memory usage errors creeping in.

One thing that sold me on Rust, again, a few days ago was the ease with which one could get code to distribute work over many cores and get a commensurate performance boost. For example:

Code: Select all

    pub fn dot_product(xs: &[f32], ys: &[f32]) -> f32 {
        xs.iter()
            .zip(ys)
            .fold(Fast(0.), |acc, (&x, &y)| acc + Fast(x) * Fast(y))
            .get()
    }

    pub fn convolution_serial(sample: &[f32], coeff: &[f32]) -> Vec<f32> {
        sample
            .windows(coeff.len())
            .map(|window| dot_product(window, coeff))
            .collect()
    }

    pub fn convolution_parallel(sample: &[f32], coeff: &[f32]) -> Vec<f32> {
        sample
            .par_windows(coeff.len())
            .map(|window| dot_product(window, coeff))
            .collect()
    }

Can you spot the difference between the serial and parallel versions of convolution there?
Magic!

What does Fast mean in the code? Would it be possible to use an FFT to perform that convolution? I wonder what a parallel bubble sort looks like.

[Heater]

What does Fast mean in the code?

A good question. It's not totally clear to me.

It's something to do with setting LLVMs "fast-math" flags which allows the compiler to make optimizations it otherwise would not: http://llvm.org/docs/LangRef.html#fast-math-flags
https://docs.rs/crate/fast-floats/0.1.2

It's also something to so with the fact that floating point operations are not associative, (((a + b) + c) + d) /= (a + (b + (c + d))). It allows the compiler to rearrange the order of operations if that is an optimizations. Of course your results may then be a tiny bit different. Certainly my results are a bit different sometimes.
https://doc.rust-lang.org/std/intrinsic ... _fast.html

Would it be possible to use an FFT to perform that convolution? I wonder what a parallel bubble sort looks like.

I have heard rumor that such things are possible. I have no idea what that is about or how.

Hmm... that reminds me, I should have a go at rewriting my home made FFT in Rust.

The challenge originally posted on the rust-lang forum involved a guy converting some C code to Rust and whining that it was so slow. It runs a 500 element convolution kernel over a 20 million element data set. That solution I posted above matches the speed of the original C as a single thread gets 3.9 times faster on 4 cores just by adding the "par_". Sweet.

[jahboater]

The challenge originally posted on the rust-lang forum involved a guy converting some C code to Rust and whining that it was so slow. It runs a 500 element convolution kernel over a 20 million element data set. That solution I posted above matches the speed of the original C as a single thread gets 3.9 times faster on 4 cores just by adding the "par_". Sweet.

Then it doesn't match the original C - because its a different algorithm. You could add threading to the C version and then compare them.
It may be that the threading code is easier and cleaner in Rust, which is a good point, but it has nothing to do with direct speed comparisons.

Language comparison is only valid with exact same functionality, the exact same algorithm, the same level of optimization (code and compiler flags). Otherwise its meaningless. Like saying sorting in language A is faster than in language B because a quick sort coded in A runs faster than a bubble sort in language B.

Also for compiled languages claiming performance, I would also want to compare equivalent examples on godbolt.

[Heater]

Then it doesn't match the original C - because its a different algorithm.

On the contrary it is exactly the same algorithm. Maybe that is clear if I do the dot_product part in-line. This is the original C code:

Code: Select all

void convolution_c(float *out, int *out_length, const float *sample, int samplelen, const float *coeff, int coefflen) {
    int outlen = samplelen - coefflen + 1;
    for (int i=0; i<outlen; i++) {
        float acc = 0.;
        for (int j=0; j<coefflen; j++) {
            acc += sample[i + j] * coeff[j];
        }
        out[i] = acc;
    }
    *out_length = outlen;
}

This is the same in Rust but in a functional style:

Code: Select all

    pub fn convolution_serial(sample: &[f32], coeff: &[f32]) -> Vec<f32> {
        sample
            // Get sequence of windows that "slide" over the sample data
            .windows(coeff.len())
            // Form the dot product of every window in the sequence
            .map(|window| {
                window
                    .iter()
                    .zip(coeff)
                    .fold(Fast(0.), |acc, (&x, &y)| acc + Fast(x) * Fast(y))
                    .get()
            })
            // Map produces an iterator so we have to assemble a vector from that.
            .collect()
    }

If you put them side by side and squint hard you will see that the same calculations in the same order are called for.

You could add threading to the C version and then compare them.
It may be that the threading code is easier and cleaner in Rust, which is a good point, but it has nothing to do with direct speed comparisons.

OK, let's ignore threading for now. Serial code only as above.

Language comparison is only valid with exact same functionality, the exact same algorithm,...

That is exactly what we have here.

..the same level of optimization (code and compiler flags). Otherwise its meaningless...

Good point. Luckily it's easy to call C functions from Rust and make the comparative timings. Both Rust and C end up going through the same LLVM backend and being subject to the same compiler flags. Which oddly enough I had already done. Here is an example result on my PC:

Code: Select all

$ cargo build --release
$ ./target/release/convolution
Original  C:          Duration 1334ms
119.04485  127.62263
Rust - serial:   Duration 1289ms
119.04485  127.62263

Like saying sorting in language A is faster than in language B because a quick sort coded in A runs faster than a bubble sort in language B.

No, not like that at all. Not like comparing a Fast Fourier Transform to a naive Fourier Transform either. The same algorithm is used in both cases.

Also for compiled languages claiming performance, I would also want to compare equivalent examples on godbolt.

A good idea. I will leave that as an exercise for the reader.

Also if anyone wants to make a parallel version of the C example with OpenMP or whatever that would be great.

[jahboater]

OK, let's ignore threading for now. Serial code only as above.

I saw in your original post

original C as a single thread gets 3.9 times faster on 4 cores just by adding the "par_"

You can see why I thought threading had been added to the Rust version !! Algol68 had the "par" keyword to convert a normal serial clause (sequence of statements in curly brackets) into a parallel clause.

I compiled the C function for interest (once I had finally persuaded the compiler to compile it rather than simply removing it), it compiled down to 10 instructions (Intel AVX). Not sure how anything could be faster to be honest, there was no redundant code and the indexing was clever.

[Heater]

Modern compilers are slippery beasts, they love deleting your code. I initialize a 20 million element sample and 500 element kernel from a pcg pseudo random number generator.

Sadly I don't have a machine around here with any new fangled AVX instructions.

Any chance you could try my Rust test bench

convolution.tgz

(23.61 KiB) Downloaded 26 times

on your machine?

Just a simple "cargo run --release"

[Heater]

Yeah, it is so easy to lose track of what is really happening to code when people move one level up...

True.

But then in the modern world it is true even if one does not move up a level.

The model of a computer embodied in C and used by C programmers does not reflect the architecture of modern CPUs.

Modern optimizers do amazing things to ones code. What runs is not the same shape as what one wrote.

If you are lucky you may get your loops un-rolled, functions in-lined, array operations vectorized. Or not.

Even a simple thing like a division can end up being done by a multiplication and some funky adjustments.

It's impossible to guess what will come out of a compiler. Which is why Godbolt has become so famous and popular.

[jahboater]

Any chance you could try my Rust test bench convolution.tgz on your machine?

Just a simple "cargo run --release"

Just a simple .....
Well I installed rustc, cargo, rust-gdb, rust-doc - all sorts of dependencies, non-existent packages ("lld-9" what package is that?) and missing dependencies.
Eventually it installed 345MB of stuff (without rust-doc which relies on a missing font package) and finally rustc seems to run OK !
Anyway ..

Code: Select all

/tmp/convolution $ cargo run --release
    Updating crates.io index
  Downloaded instant v0.1.4
  Downloaded fast-floats v0.1.2
  Downloaded rayon v1.3.0
  Downloaded cc v1.0.54
  Downloaded crossbeam-deque v0.7.3
  Downloaded either v1.5.3
  Downloaded simdeez v1.0.6
  Downloaded crossbeam-utils v0.7.2
  Downloaded maybe-uninit v2.0.0
  Downloaded crossbeam-epoch v0.8.2
  Downloaded cfg-if v0.1.10
  Downloaded rayon-core v1.7.0
  Downloaded lazy_static v1.4.0
  Downloaded paste v0.1.16
  Downloaded memoffset v0.5.4
  Downloaded autocfg v1.0.0
  Downloaded scopeguard v1.1.0
  Downloaded crossbeam-queue v0.2.3
  Downloaded num_cpus v1.13.0
  Downloaded paste-impl v0.1.16
  Downloaded proc-macro-hack v0.5.16
  Downloaded proc-macro2 v1.0.18
  Downloaded quote v1.0.7
  Downloaded syn v1.0.31
  Downloaded libc v0.2.71
  Downloaded unicode-xid v0.2.0
   Compiling autocfg v1.0.0
   Compiling proc-macro2 v1.0.18
   Compiling maybe-uninit v2.0.0
   Compiling cfg-if v0.1.10
   Compiling unicode-xid v0.2.0
   Compiling lazy_static v1.4.0
   Compiling syn v1.0.31
   Compiling libc v0.2.71
   Compiling scopeguard v1.1.0
   Compiling proc-macro-hack v0.5.16
   Compiling rayon-core v1.7.0
   Compiling cc v1.0.54
   Compiling either v1.5.3
   Compiling fast-floats v0.1.2
error[E0554]: `#![feature]` may not be used on the stable release channel
  --> /home/jah/.cargo/registry/src/github.com-1ecc6299db9ec823/fast-floats-0.1.2/src/lib.rs:18:1
   |
18 | #![feature(core_intrinsics)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `fast-floats`.
warning: build failed, waiting for other jobs to finish...
error: build failed

I guess fast-floats is like GCC's -ffast-math which may yield faster code at the expense of correctness, or at least of IEEE compliance.

[jahboater]

Heater,
For fun, I tried on an 8GB Pi4 running the beta 64-bit Raspberry Pi OS.
The rustc/cargo etc installed on the Pi went very well, but the testbed doesn't run:-

Code: Select all

pi@raspberrypi:/tmp $ tar xf convolution.tgz
pi@raspberrypi:/tmp $ cd convolution/
pi@raspberrypi:/tmp/convolution $ cargo run --release
error: failed to parse lock file at: /tmp/convolution/Cargo.lock

Caused by:
  invalid serialized PackageId for key `package.dependencies`
pi@raspberrypi:/tmp/convolution $ 

[clicky]

Hm. All my rust plays were on Pi4, 8GB on 64bit PiOS (hence Eclipse). Here's what it has done with convolution.tgz:

Code: Select all

pi@desktop-pi:~/temp/t/convolution (master) $ cargo run --release
  Downloaded cfg-if v0.1.10
  Downloaded lazy_static v1.4.0
  Downloaded memoffset v0.5.4
  Downloaded proc-macro2 v1.0.18
  Downloaded unicode-xid v0.2.0
  Downloaded num_cpus v1.13.0
  Downloaded simdeez v1.0.6
  Downloaded crossbeam-utils v0.7.2
  Downloaded syn v1.0.31
  Downloaded proc-macro-hack v0.5.16
  Downloaded quote v1.0.7
  Downloaded rayon-core v1.7.0
  Downloaded crossbeam-queue v0.2.3
  Downloaded cc v1.0.54
  Downloaded paste v0.1.16
  Downloaded crossbeam-deque v0.7.3
  Downloaded instant v0.1.4
  Downloaded scopeguard v1.1.0
  Downloaded either v1.5.3
  Downloaded crossbeam-epoch v0.8.2
  Downloaded autocfg v1.0.0
  Downloaded paste-impl v0.1.16
  Downloaded maybe-uninit v2.0.0
  Downloaded fast-floats v0.1.2
  Downloaded rayon v1.3.0
  Downloaded 25 crates (880.5 KB) in 1.65s
   Compiling autocfg v1.0.0
   Compiling cfg-if v0.1.10
   Compiling proc-macro2 v1.0.18
   Compiling maybe-uninit v2.0.0
   Compiling unicode-xid v0.2.0
   Compiling lazy_static v1.4.0
   Compiling libc v0.2.71
   Compiling syn v1.0.31
   Compiling scopeguard v1.1.0
   Compiling rayon-core v1.7.0
   Compiling proc-macro-hack v0.5.16
   Compiling cc v1.0.54
   Compiling either v1.5.3
   Compiling fast-floats v0.1.2
error[E0554]: `#![feature]` may not be used on the stable release channel
  --> /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/fast-floats-0.1.2/src/lib.rs:18:1
   |
18 | #![feature(core_intrinsics)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0554`.
error: could not compile `fast-floats`.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed

[Heater]

Hmm... how are you guys installing Rust?

Just a simple:

Code: Select all

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
$ source $HOME/.cargo/env
$ rustup install nightly
$ cargo run --release

I guess I should have mentioned I don't use the Debian/Raspbian packages for such things, they are always way out of date. And I use Rust nightly builds, because that is the way I roll.

The above procedure installs Rust for the user only so if you really want to keep any old system wide install from Debian packages they can co-exist.

[jahboater]

Hmm... how are you guys installing Rust?

I just did:-

sudo apt install rustc cargo rust-gdb rust-doc

[Heater]

I suspected as much. It's only recently I found out that was even possible.

Ain't going to work I'm afraid. I have used experimental features that are only available in the nightly builds of Rust.

That "Fast" float stuff being one of them.

We are cutting the edge here

[jahboater]

We are cutting the edge here

Adds to the fun!

If the nightly builds are stable that's pretty good.

I am running your nightly install script now on the Pi4.
If it all works, I'll install it on the Intel PC next.

[jahboater]

Still fails fast float ?
I deleted the old Debian compiler first by the way (with sudo apt purge rustc cargo ...) and I freshly untarred the convolution directory.

Code: Select all

   Compiling either v1.5.3
   Compiling instant v0.1.4
   Compiling fast-floats v0.1.2
error[E0554]: `#![feature]` may not be used on the stable release channel
  --> /home/pi/.cargo/registry/src/github.com-1ecc6299db9ec823/fast-floats-0.1.2/src/lib.rs:18:1
   |
18 | #![feature(core_intrinsics)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error