Eclipse Corrosion (Rust IDE) on RPi

[Heater]

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.

"stable" or "stable"?

I have been running nightly builds since I discovered Rust almost a year ago. I even have nightly builds running services in production at our company. It's all been stable in that I have not found any bugs and nothing has randomly crashed.

On the other hand there is a chance that experimental features change their API's or even get removed, so there might be some instability in what you actually get. So far I have not seen that either.

[ejolson]

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

According to the dog developer, Rust needs a memory-safe preprocessor that is also Turing complete to solve all the compile-time version incompatibilities. It could also be used to pregenerate tables of prime numbers for factoring areas into Tatami-free rectangles.

What happens if you delete references to the Fast floating point operations?

[Heater]

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

It clearly says there that you are still using the "stable release channel".

I don't have a Pi nearby to test on but I tried it on my Jetson Nano which is running 64 bit Ubuntu.

Code: Select all

$ tar -xvzf convolution.tgz 
$ cd convolution/
$ rustup default nightly 
$ rustup update
$ cargo run --release

BUT, I had to remove one test that used SSE instructions. It was horribly complex and slow as hell so good riddance to it.


Try this:

convolution.tgz

(23.13 KiB) Downloaded 20 times

[Heater]

Ah, just one little thing comes to mind now...

I have not run a 32 bit Rust on a 32 bit OS on a Pi for about a year. I always run it on sakaki's nspwan 64 bit environment.

I have no idea if that is the problem. My apologies if it is.

[jahboater]

It clearly says there that you are still using the "stable release channel".

It does, you are right.
I don't know what else I can do to "clean" the old Debian stuff from the system.
Maybe the apt purge didnt work, who knows.

I'll try the new convolution anyway.

I have not run a 32 bit Rust on a 32 bit OS on a Pi for about a year. I always run it on sakaki's nspwan 64 bit environment.

On the Pi I am running the 64-bit beta Raspberry Pi OS (64-bit kernel and 64-bit userland).

Edit:
Failed again for fast-floats, sorry.

[Heater]

Hmmm.. weird, it does sound like your packaged Rust is still there. What does "which cargo" say?

What does your "echo $PATH" say?

If all your rustup stuff worked then you should be able to run that nightly cargo as:

~/.cargo/bin/cargo build --release

[jahboater]

If all your rustup stuff worked:

It did, at least it ran through with no warnings or errors.

Code: Select all

pi@raspberrypi:~ $ 
pi@raspberrypi:~ $ which cargo
/home/pi/.cargo/bin/cargo
pi@raspberrypi:~ $ echo $PATH
/home/pi/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games
pi@raspberrypi:~ $ cd convolution/
pi@raspberrypi:~/convolution $ ~/.cargo/bin/cargo build --release
   Compiling cc v1.0.54
   Compiling fast-floats v0.1.2
   Compiling crossbeam-utils v0.7.2
   Compiling memoffset v0.5.4
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
pi@raspberrypi:~/convolution $ 

[Heater]

But but, you still have that "stable release channel" message there.

Are you sure you did the

Code: Select all

$ rustup install nightly
$ rustup default nightly

What does

Code: Select all

$ cargo version

say?

[jahboater]

Well spotted. I didn't do the default nightly because your script missed that line off

It has compiled the fast-float stuff now and here are the results for a 1800MHz 8GB Pi4 with the 64-bit Raspberry Pi OS:-

Code: Select all

    Finished release [optimized] target(s) in 43.65s
     Running `target/release/convolution`
zso::convolution:            Duration 22588ms
119.04489  127.622635
zso::convolution_ffi:        Duration 4419ms
119.04483  127.62262
bjorn3::convolution:         Duration 21996ms
119.04483  127.62263
dodomorandi::convolution:    Duration 17053ms
119.04489  127.622635
pcpthm::convolution:         Duration 5511ms
119.04485  127.62263
zicog::convolution:          Duration 5205ms
119.04485  127.62263
zicog::convolution_fast:     Duration 5206ms
119.04485  127.62263
zicog::convolution_safe:     Duration 17030ms
119.04489  127.622635
alice::convolution_serial:   Duration 5510ms
119.04485  127.62263
alice::convolution_parallel: Duration 1391ms
119.04485  127.62263
pi@raspberrypi:~/convolution $ 

[Heater]

Phew. It works!

Now this is something amazing. Your Pi is running faster than my Nvidia Jetson Nano. By quite a margin!

Code: Select all

$ uname -a
Linux jetson-2 4.9.140-tegra #1 SMP PREEMPT Wed Apr 8 18:10:49 PDT 2020 aarch64 aarch64 aarch64 GNU/Linux
cargo run --release
...
     Running `target/release/convolution`
zso::convolution:            Duration 34407ms
119.04489  127.622635
zso::convolution_ffi:        Duration 7333ms
119.04483  127.62262
bjorn3::convolution:         Duration 28837ms
119.04483  127.62263
dodomorandi::convolution:    Duration 34090ms
119.04489  127.622635
pcpthm::convolution:         Duration 7580ms
119.04485  127.62263
zicog::convolution:          Duration 7110ms
119.04485  127.62263
zicog::convolution_fast:     Duration 7164ms
119.04485  127.62263
zicog::convolution_safe:     Duration 34495ms
119.04489  127.622635
alice::convolution_serial:   Duration 7633ms
119.04485  127.62263
alice::convolution_parallel: Duration 2193ms
119.04485  127.62263

Interestingly my Rust solution, zicog::convolution_fast, beats the C code, zso::convolution_ffi, on the Jetson.

But on your Pi the C comes out faster!

[jahboater]

Interestingly my Rust solution, zicog::convolution_fast, beats the C code, zso::convolution_ffi, on the Jetson.

But on your Pi the C comes out faster!

How does the C part get compiled?
On my Pi4, GCC 10.1 is installed which does seem to produce better code for ARM than earlier versions did.
Or does rustc use LLVM for C.

Trying the Intel PC ...

[jahboater]

Now this is something amazing. Your Pi is running faster than my Nvidia Jetson Nano. By quite a margin!

Perhaps because the Pi CPU cores are Cortex-A72, the Jetson cores are Cortex-A57 ?

Anyway, here are the results for my Intel PC

Code: Select all

$ uname -a
Linux jah64 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
....
    Finished release [optimized] target(s) in 8.86s
     Running `target/release/convolution`
zso::convolution:            Duration 22078ms
119.04489  127.622635
zso::convolution_ffi:        Duration 1053ms
119.044846  127.622635
bjorn3::convolution:         Duration 5630ms
119.04483  127.62263
dodomorandi::convolution:    Duration 7389ms
119.04489  127.622635
pcpthm::convolution:         Duration 1110ms
119.04485  127.62263
zicog::convolution:          Duration 1127ms
119.04485  127.62263
zicog::convolution_fast:     Duration 1134ms
119.04485  127.62263
zicog::convolution_safe:     Duration 7434ms
119.04489  127.622635
alice::convolution_serial:   Duration 1083ms
119.04485  127.62263
alice::convolution_parallel: Duration 318ms
119.04485  127.62263

[Heater]

The C part is built by a cargo pre-build script: "build.rs"

It contains:

Code: Select all

fn main() {
    cc::Build::new()
        .file("src/conv.c")
        .flag("-Ofast")
        .flag("-march=native")
        .flag("-funroll-all-loops")
        .compile("libconv.a");
}

I presume it is using clang/llvm.

There is also the file convolution.c that you can build normally. It has some build instructions in it's comments.

My Jetson is only running at 1500MHz. But that does not seem to account for all the differences.

[jahboater]

My Jetson is only running at 1500MHz. But that does not seem to account for all the differences.

To save your arithmetic, here are the results for the Pi running at 1500MHz (stock speed).

Code: Select all

     Running `target/release/convolution`
zso::convolution:            Duration 27092ms
119.04489  127.622635
zso::convolution_ffi:        Duration 5333ms
119.04483  127.62262
bjorn3::convolution:         Duration 26408ms
119.04483  127.62263
dodomorandi::convolution:    Duration 20433ms
119.04489  127.622635
pcpthm::convolution:         Duration 6607ms
119.04485  127.62263
zicog::convolution:          Duration 6257ms
119.04485  127.62263
zicog::convolution_fast:     Duration 6259ms
119.04485  127.62263
zicog::convolution_safe:     Duration 20395ms
119.04489  127.622635
alice::convolution_serial:   Duration 6602ms
119.04485  127.62263
alice::convolution_parallel: Duration 1676ms
119.04485  127.62263
pi@raspberrypi:~/convolution $ 

[ejolson]

Now this is something amazing. Your Pi is running faster than my Nvidia Jetson Nano. By quite a margin!

Is Rosetta at Home still folding cures for coronavirus on your Jetson?

[Heater]

No Rosetta here. This is a whole new SD card in the Jetson with a fresh OS installation. I was watching top during the benchmark, nothing seems to be getting in the way.

[ejolson]

No Rosetta here. This is a whole new SD card in the Jetson with a fresh OS installation. I was watching top during the benchmark, nothing seems to be getting in the way.

The post

viewtopic.php?t=249577&start=50#p1549613

reports a Pi pie chart run for the Jetson Nano with the results

Code: Select all

jcyr@Jetson:~/pichart-30$ ./pichart-openmp -t jetson-nanno
pichart -- Raspberry Pi Performance OPENMP version 30

Prime Sieve          P=14630843 Workers=4 Sec=0.623114 Mops=1499.45
Merge Sort           N=16777216 Workers=8 Sec=1.22402 Mops=328.959
Fourier Transform    N=4194304 Workers=8 Sec=0.917132 Mflops=503.061
Lorenz 96            N=32768 K=16384 Workers=4 Sec=0.707082 Mflops=4555.66

The jetson-nanno has Raspberry Pi ratio=28.9537
Making pie charts...done.

My run for the 4B is

Code: Select all

$ ./pichart-openmp 
pichart -- Raspberry Pi Performance OPENMP version 32

Prime Sieve          P=14630843 Workers=4 Sec=0.552507 Mops=1691.07
Merge Sort           N=16777216 Workers=8 Sec=0.742115 Mops=542.575
Fourier Transform    N=4194304 Workers=8 Sec=1.33157 Mflops=346.487
Lorenz 96            N=32768 K=16384 Workers=4 Sec=0.630267 Mflops=5110.89

My Computer has Raspberry Pi ratio=31.7025
Making pie charts...done.

as reported in the post

viewtopic.php?f=63&t=227177&start=100#p1657704

The 4B outperforms the Nano on three out of four tests. Since the FFT is very memory intensive, it makes sense that the Nano has an advantage there.

Do you get the same results that jcyr did with your Jetson Nano?

[clicky]

Hmm... how are you guys installing Rust?

I've just done what is written on https://www.rust-lang.org/learn/get-started

- no extras...

[Heater]

You mean you did this:

Code: Select all

$ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Did you then do this (as suggested in the output of the above)

Code: Select all

$ source $HOME/.cargo/env

Did you then do this:

Code: Select all

$ rustup install nightly
$ rustup default nightly
$ cargo run --release

What is the output of that last command?

[jahboater]

The 4B outperforms the Nano on three out of four tests. Since the FFT is very memory intensive, it makes sense that the Nano has an advantage there.

Yes.
The Pi4 has 1300MHz DDR4, the Nano has 1600MHz DDR4. The Pi4's memory is much much faster than older Pi models.
I don't know anything about the relative speeds of the memory controller or the bus.

I 'think' the Pi4 CPU's should run 64-bits better because they are the more modern out-of-order designs that aarch64 was designed for.

[jahboater]

I see Rust entered the TIOBE index top twenty this month ...

https://www.tiobe.com/tiobe-index//

[Heater]

Yeah I noticed.

It's odd times with C on the top of the list.

The Rust guys are clever. They invented such a confusing language (for those Java/C# and interpreted language refugees) that they overloaded stack exchange and the web with newbie questions. And hence shot up the language ratings.

Brilliant

[clicky]

It clearly says there that you are still using the "stable release channel".

I don't have a Pi nearby to test on but I tried it on my Jetson Nano which is running 64 bit Ubuntu.
...
BUT, I had to remove one test that used SSE instructions. It was horribly complex and slow as hell so good riddance to it.
Try this:

convolution.tgz

Code: Select all

$ rustup install nightly
$ rustup default nightly
$ cargo run --release

What is the output of that last command?

Here it is (now I'm set up nightly version):

Code: Select all

pi@desktop-pi:~/temp/t/convolution (master) $ cargo run --release
   Compiling autocfg v1.0.0
   Compiling maybe-uninit v2.0.0
   Compiling cfg-if v0.1.10
   Compiling lazy_static v1.4.0
   Compiling libc v0.2.71
   Compiling scopeguard v1.1.0
   Compiling rayon-core v1.7.0
   Compiling cc v1.0.54
   Compiling either v1.5.3
   Compiling fast-floats v0.1.2
   Compiling instant v0.1.4
   Compiling crossbeam-utils v0.7.2
   Compiling memoffset v0.5.4
   Compiling crossbeam-epoch v0.8.2
   Compiling num_cpus v1.13.0
   Compiling crossbeam-queue v0.2.3
   Compiling crossbeam-deque v0.7.3
   Compiling rayon v1.3.0
   Compiling convolution v0.1.0 (/home/pi/temp/t/convolution)
warning: unused import: `rayon::prelude::*`
 --> src/lib.rs:4:5
  |
4 | use rayon::prelude::*;
  |     ^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: unnecessary parentheses around assigned value
   --> src/lib.rs:143:24
    |
143 |                 acc += (window[j] * coeff[j]);
    |                        ^^^^^^^^^^^^^^^^^^^^^^ help: remove these parentheses
    |
    = note: `#[warn(unused_parens)]` on by default

warning: 2 warnings emitted

warning: associated function is never used: `rand`
  --> src/pcg.rs:34:12
   |
34 |     pub fn rand(&mut self) -> u32 {
   |            ^^^^
   |
   = note: `#[warn(dead_code)]` on by default

warning: 1 warning emitted

    Finished release [optimized] target(s) in 48.54s
     Running `target/release/convolution`
zso::convolution:            Duration 27198ms
119.04489  127.622635
zso::convolution_ffi:        Duration 5344ms
119.04483  127.62262
bjorn3::convolution:         Duration 26427ms
119.04483  127.62263
dodomorandi::convolution:    Duration 20512ms
119.04489  127.622635
pcpthm::convolution:         Duration 6651ms
119.04485  127.62263
zicog::convolution:          Duration 6334ms
119.04485  127.62263
zicog::convolution_fast:     Duration 6269ms
119.04485  127.62263
zicog::convolution_safe:     Duration 20467ms
119.04489  127.622635
alice::convolution_serial:   Duration 6630ms
119.04485  127.62263
alice::convolution_parallel: Duration 1726ms
119.04485  127.62263

On Pi4 8GB with 64bit PiOS...

[jahboater]

It's odd times with C on the top of the list.

C increased this month by 10 times as much as Rust (3.89%). I don't know why.

I have to say I do find Rust hard to read.
If you compare the two code snippets for the convolution/dot product you posted above, I suspect that if you presented them both to someone new to the languages, they would find the C version easier to understand. No comments were needed for the C version.

Is it possible to write code like that in Rust in such a way that a mathematician with no experience of coding could read and have some idea what the algorithm used was?

Its not good if arcane tweaks are required all the time to get performance.

[clicky]

...
Is it possible to write code like that in Rust in such a way that a mathematician with no experience of coding could read and have some idea what the algorithm used was?

Its not good if arcane tweaks are required all the time to get performance.

I don't think people who designed Rust had readability in mind as primary problem what they tried to solve. (Not that they might have had done really good job given constraints they had given to themselves).

There are other languages that tried to provide 'comfortable' environment for such class of problems. (Have they succeeded or not is different thing). Back to Rust - fact that we are talking about it is already small victory for it.