wabt
                                
                                 wabt copied to clipboard
                                
                                    wabt copied to clipboard
                            
                            
                            
                        Fix interpreter to run opcodes consecutively
For better performance, I fixed the interpreter to run opcodes consecutively rather than single execution for each opcode.
From a simple evaluation below, this patch showed a significant performance improvement.
// fibonacci calculation
#include <stdio.h>
int fib(int n) {
  if (n == 1) return 1;
  if (n == 2) return 1;
  return fib(n-1) + fib(n-2);
}
int main()
{
    fib(30);
    return 0;
}
Performance Result
- This patch : 22.1 sec
- Origin : 25.1 sec
@sbc100
I'm using wasm-c-api to run wasm codes in my project. And AFAIK wabt is the only wasm engine built by c/c++ that fully supports the wasm-c-api standard.
I'm also happy to contribute to this project and I'll upgrade the interpreter as much as possible not harming the overall sustainability or readability. Thanks :)
@sbc100 I'm using
wasm-c-apito run wasm codes in my project. And AFAIKwabtis the only wasm engine built by c/c++ that fully supports thewasm-c-apistandard.I'm also happy to contribute to this project and I'll upgrade the interpreter as much as possible not harming the overall sustainability or readability. Thanks :)
I though that v8 supported that API? Does it not? What about wasmtime?
In any case, its great that you are using wabt and we will happily accept your patches, but please bear in mind that the wabt is probably not the best choice for a production runtime.. at least not in the long term.
@sbc100
I need a lightweight wasm engine for several reasons now, so I choose wabt.
wasmtime is also one of good alternatives, but unfortunately it is based on rust language 😢
I'll keep in mind your advice Thanks :)
it might be possible to simply add an appropriate inline attribute instead?
Hi -- is there still interest in merging this (in which case I think the diff should probably be cleaned up to avoid re-formatting those big sections), or should we close as dormant?
This has been inactive for a long time, so I close it.