rustc apparently optimizes away the loop in 3.3

[lojic]

I just implemented the code in section 3.3 to compare Ruby to Rust. It appears that rustc optimizes away the inner loop of the thread, because I kept increasing the limit and the completion time remained constant. I introduced a simple if statement in the loop, and then I got expected timings.

It might be worth modifying the loop so it's not optimized away for a fairer comparison. Here's what I ended up with:

pub extern fn process() {
  let handles: Vec<_> = (0..10).map(|_| {
    thread::spawn(|| {
      let mut x = 0u64;
      for i in (0..7_700_000_000u64) {
        if i < 1 {
          x += 2
        } else {
          x += 1
        }
      }
      x
    })
  }).collect();

  for h in handles {
    println!("Thread finished with count={}",
             h.join().map_err(|_| "Could not join a thread!").unwrap());
  }
  println!("done!");
}

[lojic]

sorry - I thought I was following the link to submit an issue with the Rust Book, but it appears I've submitted an issue to the Rust language proper :(

[steveklabnik]

@lojic the book issues are part of the repo here, yes.

[steveklabnik]

Also, I believe that we either 1) did something to fix this, or 2) there's already an issue open, would you mind checking the nightly book and the other issues?

[lojic]

The example in the book still exhibits the "optimized away" problem. I scanned through all the "A-docs" issues and didn't see anything that matched, but I may have missed something.

[lojic]

Sorry, missed "nightly" above - I'll check that...

[lojic]

Nightly appears to be the same as stable - just a simple loop that rustc is smart enough to collapse.

[steveklabnik]

Roger. Thanks for checking, maybe I'm imagining things.