5 ms·

Here is an extremely unscientific benchmark using the Takeuchi function and Trealla Prolog: $ make wasm $ wasmer create-exe tpl.wasm -o tpl-wasm $ tim

by grose 4y ago

Here is an extremely unscientific benchmark using the Takeuchi function and Trealla Prolog: $ make wasm $ wasmer create-exe tpl.wasm -o tpl-wasm $ time ./tpl-wasm --consult < tak.pl -g 'time(run)' --ns '<https://josd.github.io/eye/ns#tak>'([34,13,8],13). % Time elapsed 1.39s real 0m1.403s user 0m1.333s sys 0m0.070s $ time tpl tak.pl -g 'time(run)' --ns '<https://josd.github.io/eye/ns#tak>'([34,13,8],13). % Time elapsed 0.448s real 0m0.473s user 0m0.463s sys 0m0.010s WASM is about 3x slower. In general I've found it to be 2-3x slower, at least for my use cases. I also tried the LLVM compiler instead of Cranelift but it was slightly slower.

coder543 4y ago
Certainly interesting, but I'm not sure how well the performance of a prolog interpreter maps to other use cases. That benchmark looks too short to be a useful measure of how JIT influences performance, otherwise I would ask how the regular Wasmer does in that benchmark too (since it seems like create-exe doesn't include a JIT).
- kevingadd 4y ago
  Wasm also can't do computed goto for interpreters, so it's at a disadvantage for this benchmark in general
  - still_grokking 4y ago
    Is the used interpreter built with computed goto?
    - guipsp 4y ago
      Switch tables tend to be computed goto based
      - still_grokking 4y ago
        Is the interpreter we're talking about built this way?
        guipsp 4y ago
        Even if you write if...else a smart compiler will turn it into a switch table.
        still_grokking 4y ago
        Could you show an example? A Godbolt link would be nice!
        grose 4y ago
        Honestly I can't really say (I just ported it to WASM :-)), but here's more or less the start of the query loop: https://github.com/guregu/trealla/blob/main/src/query.c#L1733 https://github.com/guregu/trealla/blob/main/src/query.c#L173... I believe it's a bytecode but I know that function pointers are involved at least with the built-in predicates (see predicates.c).
h4x0rr 4y ago
In my tests (simple rust benchmarks) it was about 30% slower. Ab large part of the 1.4 is probably startup time. So it's not that bad either.
- grose 4y ago
  Oh yeah, it's definitely not bad. I'm quite happy with it. I imagine I'm hitting on some corner cases here that aren't really indicative of the average user. Thanks for the comparison. My reading of the numbers is that the startup overhead is about 13ms in my example, quite fast. Shout out to Wizer for greatly reducing the startup time.

by grose 4y ago

coder543 4y ago

Certainly interesting, but I'm not sure how well the performance of a prolog interpreter maps to other use cases. That benchmark looks too short to be a useful measure of how JIT influences performance, otherwise I would ask how the regular Wasmer does in that benchmark too (since it seems like create-exe doesn't include a JIT).

kevingadd 4y ago
Wasm also can't do computed goto for interpreters, so it's at a disadvantage for this benchmark in general
- still_grokking 4y ago
  Is the used interpreter built with computed goto?
  - guipsp 4y ago
    Switch tables tend to be computed goto based
    - still_grokking 4y ago
      Is the interpreter we're talking about built this way?
      - guipsp 4y ago
        Even if you write if...else a smart compiler will turn it into a switch table.
        still_grokking 4y ago
        Could you show an example? A Godbolt link would be nice!
      - grose 4y ago
        Honestly I can't really say (I just ported it to WASM :-)), but here's more or less the start of the query loop: https://github.com/guregu/trealla/blob/main/src/query.c#L1733 https://github.com/guregu/trealla/blob/main/src/query.c#L173... I believe it's a bytecode but I know that function pointers are involved at least with the built-in predicates (see predicates.c).

h4x0rr 4y ago

In my tests (simple rust benchmarks) it was about 30% slower. Ab large part of the 1.4 is probably startup time. So it's not that bad either.

grose 4y ago
Oh yeah, it's definitely not bad. I'm quite happy with it. I imagine I'm hitting on some corner cases here that aren't really indicative of the average user. Thanks for the comparison. My reading of the numbers is that the startup overhead is about 13ms in my example, quite fast. Shout out to Wizer for greatly reducing the startup time.