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

Performance #85

Closed
geloizi opened this issue Mar 28, 2019 · 3 comments
Closed

Performance #85

geloizi opened this issue Mar 28, 2019 · 3 comments

Comments

@geloizi
Copy link

geloizi commented Mar 28, 2019

I've tried several simple cpu bounded benchmarks. It seems that in general wasmtime is twice slower than V8 or Spider Monkey.

@sunfishcode
Copy link
Member

Wasmtime uses Cranelift, which we know doesn't yet have all the optimization features we're planning for it to have, and we know it's not competitive with browser wasm engines yet. That said, I also do recommend caution when interpreting microbenchmarks.

@bjorn3
Copy link
Contributor

bjorn3 commented Feb 3, 2021

This issue is not actionable. In addition a lot has changed since this issue was created, so it may already be fixed.

@cfallin
Copy link
Member

cfallin commented Feb 3, 2021

We've had a number of significant performance improvements since this issue was filed (most notably: new backend, with new register allocator), and while we're still not quite as fast as V8 or SpiderMonkey, we're getting closer. We're hoping to have some continuous performance measurement infrastructure working soon (bytecodealliance/rfcs#3, bytecodealliance/rfcs#4) so we should prefer that for tracking over this general issue, I think.

@cfallin cfallin closed this as completed Feb 3, 2021
pchickey pushed a commit to pchickey/wasmtime that referenced this issue May 16, 2023
mooori pushed a commit to mooori/wasmtime that referenced this issue Dec 20, 2023
dhil added a commit to dhil/wasmtime that referenced this issue Jan 30, 2024
)

This patch makes the interfaces and implementations of continuation-related libcalls safer as they now handle traps/failures.

In addition, this patch increases the default fiber stack size to 2MB.
---------

Co-authored-by: Frank Emrich <git@emrich.io>
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

4 participants