61–66 of 66 posts
Earlier quoted context omitted.
It speeds up interpreted languages.
I get that, but what interpreted language do you want to write iOS apps in when there's Swift and Obj-C right there, with bespoke support and tooling from Apple? And if you care about performance, why aren't you writing that code in native to begin with?
The issues with branch prediction aren't really as much of a thing in modern interpreters, I can really recommend reading https://inria.hal.science/hal-01100647/document
The paper is 10 years old. While the gap between a threaded an interpreter (a dispatch at the end of every handler) versus non-threaded (loop over switch) isn't as big as it used to be, it's still 15-30% on modern very fast interpreters. For example, I measured between 14 and 29% performance improvement for threading Wizard's interpreter[1]. [1] https://dl.acm.org/doi/10.1145/3563311
Earlier quoted context omitted.
The paper is 10 years old. While the gap between a threaded an interpreter (a dispatch at the end of every handler) versus non-threaded (loop over switch) isn't as big as it used to be, it's still 15-30% on modern very fast interpreters. For example, I measured between 14 and 29% performance improvement for threading Wizard's interpreter[1]. [1] https://dl.acm.org/doi/10.1145/3563311
Interesting paper :) I've kept choosing threaded myself, but would have put the gap in a 5-10% range. I guess the branch predictor hasn't kept up. (Also trying to resist getting nerdsniped into measuring it myself 0_0)
Compare the running speed of the two binaries built with different options:
% V3C_OPTS=-redef-field=FastIntTuning.threadedDispatch=true ./build.sh wizeng x86-64-linux
% bin/wizeng.x86-64-linux --mode=int test/microbench/100ms/fib.wasm
% V3C_OPTS=-redef-field=FastIntTuning.threadedDispatch=false ./build.sh wizeng x86-64-linux
% bin/wizeng.x86-64-linux --mode=int test/microbench/100ms/fib.wasmEarlier quoted context omitted.
JIT compilation can be faster for compiled languages too, as it allows data driven inlining and devirtualization, as well as "effective constant" propogation and runtime architecture feature detection
It can be but it never is.
Earlier quoted context omitted.
It speeds up interpreted languages.
I get that, but what interpreted language do you want to write iOS apps in when there's Swift and Obj-C right there, with bespoke support and tooling from Apple? And if you care about performance, why aren't you writing that code in native to begin with?
Earlier quoted context omitted.
I get that, but what interpreted language do you want to write iOS apps in when there's Swift and Obj-C right there, with bespoke support and tooling from Apple? And if you care about performance, why aren't you writing that code in native to begin with?
Why would you care about faster cars when planes exist?
