I just wrote a small Rust program to solve an Euler Project problem. We are talking about 29 lines of code. On an Arch Linux system, using Rust 1.6, the compiled executable, compiled with rustc -O --crate-type bin is 627KB. The same program in C is 8.8 KB. The C version runs in .155 seconds on a…

Strange. I am not seeing that variance: dca@igor:~/Euler/rust$ cd ../c dca@igor:~/Euler/c$ ls problem_20 problem_20.c problem_20_in_c dca@igor:~/Euler/c$ time ./problem_20 31626 real 0m0.160s user 0m0.157s sys 0m0.000s dca@igor:~/Euler/c$ time ./problem_20 31626 real 0m0.16…

Please, format your code and output... It's a lot easier to read for us. Enclose your code in triple back ticks like this: ``` // Code goes here ``` For me there is almost no difference between C and Rust (with iterators) execution time: C: 0.21s user 0.00s system 99% cpu 0.209 total Rust: 0.…

Thanks for the formatting tip; I hadn't taken the time to figure out how to use this site and saw that the code was pretty ugly.. Even though the code I submitted earlier gets the right answer in all versions, there's some confusion, vestiges of changes in how I wrote it as I was solving the proble…

In your C code you're using ints, while in the Rust version you're using i32, that is a 32 bit signed integer. Are those two types equal on your system? Above I've used int32_t in the C code to be sure it's a more correct comparison.

(A tip I didn't know until fairly recently is perf stat -r 10 ./program, which will run a program repeatedly and summarize the time it takes.)

Nice! Okay, so here's a full run from me: steve@warmachine:~/tmp$ cat hello.rs fn d(n: i32) -> i32 { (2..(n / 2 + 1)). filter(|m| n % m == 0). fold(0, |result, i| result + i) } fn amicable(n: i32) -> i32 { let dn = d(n); let ddn = d(dn); if ddn == n && n != dn && …

@steveklabnik and @donallen just for the sake of correctness, in your last Rust implementations you get the wrong final answer printed because you start the fold accumulator at zero instead of one. fold(0, |result, i| result + i) gives 41274 as final result fold(1, |result, i| result + i) gives …

Whoops! At least that shouldn't affect the speed :sweat_smile:

31626 is correct, confirmed by my submission to the Euler Project website last night.

Executable size and performance vs. C?

Topic		Replies	Views
Clippy driving me to insanity, insisting on iterators	41	5484	January 14, 2020
Unexpected performance from array bound tests and more	12	2366	July 21, 2016
Std library inclusion policy, and a data point of compilation times	51	7491	July 26, 2022
How to explain slowdown with Sieve of Eratosthenes versus Nim and C? help	11	3537	January 25, 2016
Sometimes using Rust is really annoying	20	1267	October 6, 2025

Executable size and performance vs. C?

Related topics