Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The code runs slower when optimised #5949

Closed
vi opened this issue Apr 19, 2013 · 3 comments
Closed

The code runs slower when optimised #5949

vi opened this issue Apr 19, 2013 · 3 comments

Comments

@vi
Copy link
Contributor

vi commented Apr 19, 2013

fn main() {
    let mut va = [0.0, .. 102];
    let mut vb = [0.0, .. 102];
    let mut p=0.0;
    va[51]=1.0;

    do int::range(1,300001) |k| {
        do int::range(2,101) |i| {
            vb[i] = (1.0/6.0)*va[i-1] + (4.0/6.0)*va[i] + (1.0/6.0)*va[i+1];
            true
        }
        let n = (1.0/6.0)*va[2] + (1.0/6.0)*va[100];
        p += n * (k as float);
        vb[0] += n;
        va=vb;
        if k % 5000 == 0 {
            io::println(fmt!("%.10f %.10f %d", va[0], p, k));
        }
        true
    }
    io::println(fmt!("%.10f %.10f", va[0], p));
}

Built with rustc --opt-level 0, it runs fast.
With any other --opt-level, it runs slow.

Checked on c2f5a87 and 5f13e9c.

@luqmana
Copy link
Member

luqmana commented Apr 19, 2013

It seems to be because of stack switching.

With -O:

-> % env RUST_MIN_STACK=8000000 time ./foo >/dev/null
        0.12 real         0.12 user         0.00 sys
-> % time ./foo >/dev/null
./foo > /dev/null  0.80s user 0.00s system 99% cpu 0.801 total

@vi
Copy link
Contributor Author

vi commented Apr 19, 2013

Maybe it can print some warning that suggest me to set RUST_MIN_STACK?

@luqmana
Copy link
Member

luqmana commented Apr 21, 2013

Now that pcwalton's improvements have landed, building with optimizations doesn't run slower than without optimizations.

@luqmana luqmana closed this as completed Apr 21, 2013
flip1995 pushed a commit to flip1995/rust that referenced this issue Aug 28, 2020
…le_const, r=oli-obk

Fix fp in `borrow_interior_mutable_const`

fixes rust-lang#5796

changelog: fix false positive in `borrow_interior_mutable_const` when referencing a field behind a pointer.
arcnmx pushed a commit to arcnmx/rust that referenced this issue Jan 9, 2023
Add action to expand a declarative macro once, inline. Fixes rust-lang#13598

This commit adds a new r-a method, `expandMacroInline`, which expands the macro that's currently selected. See  rust-lang#13598 for the most applicable issue; though I suspect it'll resolve part of rust-lang#5949 and make rust-lang#11888 significantly easier).

The macro works like this:

![rust-analyser-feature](https://user-images.githubusercontent.com/10906982/208813167-3123e379-8fd5-4206-a4f4-5af1129565f9.gif)

I have 2 questions before this PR can be merged:

1. **Should we rustfmt the output?** The advantage of doing this is neater code. The disadvantages are we'd have to format the whole expr/stmt/block (since there's no point just formatting one part, especially over multiple lines), and maybe it moves the code around more in weird ways. My suggestion here is to start off by not doing any formatting; and if it appears useful we can decide to do formatting in a later release.
2.   **Is it worth solving the `$crate` hygiene issue now?** -- I think this PR is usable as of right now for some use-cases; but it is annoying that many common macros (i.e. `println!()`, `format!()`) can't be expanded further unless the user guesses the correct `$crate` value. The trouble with solving that issue is that I think it's complicated and imperfect. If we do solve it; we'd also need to either change the existing `expandMacro`/`expandMacroInline` commands; provide some option to allow/disallow `$crate` expanding; or come to some other compromise.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants