ARM build

[gavofyork]

No description provided.

[MagaTailor]

A fully functional parity can now be built on ARM.

What's needed are these changes:

• nix 0.5
• mio patch thkaw/mio@8add138
• fixed Makefile

Here's an example 1.0 build. or a 1.1 build for slow networks.

[MagaTailor]

Why does it need rustc to even start? Shurely shome mishtake!

[gavofyork]

cool - any chance we could get PRs for the required alterations?

[MagaTailor]

The nix/mio issue will probably solve itself over the coming days. If it drags on, however, or you wanted to have it compile right now, we'd have to use an "official" fork of mio in Cargo.toml

As for the rocksdb Makefile bug, I'll open an issue with https://github.com/arkpar/rust-rocksdb/ as I'm not sure about the cleanest way to backport the change.

EDIT:
Or rather I'd do it if the repo allowed issues :)

[arkpar]

rocksdb is sorted now

[MagaTailor]

Indeed, builds out of the box.

Someone has tried cross-compilation targeting ARM:

rust-lang/rust#32272 (comment)

I suspect rocksdb is being built natively instead of cross-compiled.

[phonikg]

This is all a little over my head as it is my first time in Rust-land, and I am very much a beginner developer. I have been able to install Multirust on a RasPi3, and indeed I no longer have any rocksdb issues, however I am also(obviously) running into the [308] Could not compile nix issue.

@petevine Am I best off to wait for it to sort itself out? Or would you be so kind as to post a step-by-step to replacing old_nix with new_nix?

[MagaTailor]

Luckily for you, I already did that :)

rust-lang/rust#32272 (comment)

Don't forget to add your benchmark results here.

[tomusdrw]

Recently #629 has been merged to master (and I believe to beta also). @petevine could you try to re-run the benchmarks to compare the results?

[phonikg]

@petevine Thanks for this, I will play around with it. Would you be opposed to me using your binary to create a Raspberry Pi image a distribute on www.ethembedded.com? Credit will be given of course...

[MagaTailor]

@phonikg Sure, go ahead if the binary works for you.

[phonikg]

its syncing now... block # 163,000 ...ill ensure it fully syncs without issue before releasing a fresh .img into the wild. Also Ill add benchmark for Raspi3 & Odroid XU3 (Octacore & 2GB ram) shortly.

[General-Beck]

started this build on Rasp p2 B (Ubuntu Core ). syncing now
"parity Pi 2 B" on ethstats

[phonikg]

So other than the fact that I had to start re-syncing fresh due to a power outage(parity --pruning --fast would not just continue) Both my RasPi2 & RasPi3 have been getting hung up often on blocks due to 0/0 peers... syncing for over 24hrs now and getting there, but.

@General-Beck I'm curious how are you making out with yours? I cannot find a "parity Pi 2 B" on ethstats...

[General-Beck]

@phonikg ethstats periodically disappears, the client statistics on an external server
http://screencloud.net/v/4NWV
use direct run ./parity-armv7 --rpc --rpcaddr "0.0.0.0" --cache "500" --port "30304"
I will do soon snappy

[MagaTailor]

@phonikg I'd updated the build maybe a day or two later, and that's the one @General-Beck is using judging from ethstats. In case you're actually bumping into some old bugs, I advise using the later build too.

Or maybe it's just slow internet connection.

[phonikg]

@petevine I think I have the latest as well... not buggy so much as drops cannot connect to peers. Restart parity and off it goes. More likely lack of resources(see free stats below), and the fact that I normally have 2GB of swap, but forgot to apt-get install dphys-swapfile

I am at block #1184890... getting close:)

[phonikg]

@General-Beck Yeah ethstats is memory intensive as well... historically when I was posting my devices to stats.ethdev.com I would let the Pi sync first before running ethstats. Greatly reduced the time-to-full-sync. Also see message above re: swap... doesn't hurt to have a little.

[MagaTailor]

@phonikg You should be using ZRAM!

BTW, you mentioned owning a XU3 - you seem to have no problem using rust tools, so maybe you could run a little benchmark on it, to help llvm ARM guys tweak some unrolling settings? That could benefit code generation, with parity in mind, as unrolling is currently off during autovectorization.

(I usually compile with the interleave value set to 4)
If you can spare a moment, see you in that thread. Thx.

[phonikg]

@petevine For sure... Ill give it a go, with zram installed;)

[phonikg]

@petevine how do I adjust for this:

main.rs:16:9: 16:15 warning: variable does not need to be mutable, #[warn(unused_mut)] on by default
main.rs:16 let mut dq: VecDeque<> = (0..1024).collect();
^~~~~~
main.rs:37:9: 37:15 warning: variable does not need to be mutable, #[warn(unused_mut)] on by default
main.rs:37 let mut dq: VecDeque<> = (0..1024).collect();

[phonikg]

OK NVM... ignore warnings RIGHT?

n=1

running 2 tests
test sum_deque ... bench: 3,133 ns/iter (+/- 38)
test sum_deque_2 ... bench: 400 ns/iter (+/- 3)

N=2

running 2 tests
test sum_deque ... bench: 3,133 ns/iter (+/- 42)
test sum_deque_2 ... bench: 259 ns/iter (+/- 4)

N=4

running 2 tests
test sum_deque ... bench: 3,133 ns/iter (+/- 38)
test sum_deque_2 ... bench: 238 ns/iter (+/- 3)

N=8

running 2 tests
test sum_deque ... bench: 3,133 ns/iter (+/- 37)
test sum_deque_2 ... bench: 238 ns/iter (+/- 3)

[MagaTailor]

Thanks! I'll repost the result in the LLVM bugtracker then.

[MagaTailor]

rust-lang/rust#33189

[arkpar]

There is an ARM docker build image, so closing this. There is separate issue for musl/static build (#999)

[MagaTailor]

From a purely Rust/Cargo perspective it still doesn't build cleanly but at least the nix/mio situation should get fixed soon in the ecosystem.

EDIT:
A few hours later it got fixed indeed.