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

wasm speed are no faster than js #558

Closed
gliheng opened this issue Feb 28, 2019 · 3 comments
Closed

wasm speed are no faster than js #558

gliheng opened this issue Feb 28, 2019 · 3 comments

Comments

@gliheng
Copy link

gliheng commented Feb 28, 2019

🐛 Bug description

I did some algorithm performance comparision with js, but wasm built are no faster than js.
Same nqueen algorithm, wasm version took 4450 ms, js version took 4633ms.
rust native version only took round 2sec.

There's some other algorithm I took from https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/rust.html.
wasm fannkuch: 5579ms
js fannkuch: 4322ms

🤔 Expected Behavior

wasm should be faster than js version

👟 Steps to reproduce

git clone https://github.com/gliheng/wasm-perf
cd wasm-perf
wasm-pack build wasm --release
npm install
npm run dev

Open http://localhost:8080, see the console print

🌍 Your environment

Include the relevant details of your environment.
wasm-pack version: 0.6.0
rustc version: 1.32.0 (9fda7c223 2019-01-16)

@alexcrichton
Copy link
Contributor

Thanks for the report! Always a good idea to keep a close eye on performance. One thing I'd recommend initially is that the default template optimizes for code size, but in your use case it looks like you're optimizing for speed. This difference has historically caused significant slowdown, so I'd recommend deleting that [profile.release] section or even removing opt-level and turning on lto = true. In general we don't have a lot of guides yet of tweaking compile settings for speed, but it'd be good to have them!

Once I made that change and ran the benchmarks myself locally in Firefox Nightly on a mac I got:

wasm binary tree: 573ms
js binary tree: 1269ms 
wasm regex: 11ms       
js regex: 7ms          
wasm fannkuch: 8165ms  
js fannkuch: 3177ms    
wasm nqueen: 2629ms    
js nqueen: 3382ms      
wasm fibonacci: 51ms   
js fibonacci: 135ms    

which I think shows a significant improvement across the board from when I was looking at opt-level=s!

It still shows that wasm isn't so great at fannkuch with respect to the JS implementation. Taking a look at a profile in Gecko it doesn't look like anything is too awry, it may just be a missing optimization in either LLVM or the wasm engine itself.

I'm not too familiar with the various engines here, but I'll try passing this along to some Gecko folks to see if they have ideas about optimizations

@gliheng
Copy link
Author

gliheng commented Mar 1, 2019

Alex, Thanks for looking into it. Your method works. With opt-level=3 and lto=true, binary size went from 810377 to 868998. Not much increase in size I think.

It would be nice if rustwasm book have a Optimize for speed section to make it clear, in case people don't understand. If speed of wasm is not fast, why would people use it? : )

@alexcrichton
Copy link
Contributor

A good point! I've opened up rustwasm/book#154 to track that for addition to the book itself. With that I think this issue is largely solved, so I'm going to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants