Suspicious timing when running Rust Book example

1

I'm running the example from the "Rust Inside Other Languages" section in Rust Book.

I noticed that when I embed the code into Python and execute it, the execution time does not depend on the counter size (initially set to 5 million in the book).

However, if I modify the code to return, say, the count in the spawned thread (and later do .join().unwrap(), the execution time starts depending on the number of iterations.

This seems not to depend on the number of iterations:

pub extern fn process() {
    let handles: Vec<_> = (0..10).map(|_| {
        thread::spawn(|| {
            let mut _x = 0;
            for _ in (0..900_000_001) {
                _x += 1
            }
        })
    }).collect();

    for h in handles {
        h.join().unwrap();
    }
}

This seems to get slower with more iterations (as it should):

pub extern fn process() {
    let handles: Vec<_> = (0..10).map(|_| {
        thread::spawn(|| {
            let mut _x = 0;
            for _ in (0..900_000_001) {
                _x += 1
            }
            _x
        })
    }).collect();

    for h in handles {
        h.join().unwrap();
    }
}

Why is this so? Is this some sort of compiler optimisation that removes the loop execution altogether? Should the code in the book be updated?

2

Sounds like it's optimized away. The compiler may reason that _x is completely useless, even if you add to it, and just remove it. Just a guess.

3

Yep - removing unused variables and corresponding dead code is a basic compiler optimization for compiled languages; the example should be updated. Actually, I'm surprised LLVM did not optimize the closure in your second example into "return 900000001"; what optimization settings are you using? (Incidentally, dead code elimination is not as common for dynamic languages, which is why, several years back, Microsoft was accused of "cheating" on SunSpider for using such an optimization to avoid actually executing some benchmark.)

4

I thought _x would be enough to not optimize it out, guess I was wrong :confused: