Turbocall – Just-in-time compiler for Deno FFI
1–10 of 14 posts
Re: Turbocall – Just-in-time compiler for Deno FFI
#2This is one of the approaches for FFI taken by other runtimes, however it has the issue that without binding generators (jextract, P/Invoke code generators, ctypesgen), the type declarations are a pain to write.
Thus something like this would need a similar tool.
Re: Turbocall – Just-in-time compiler for Deno FFI
#3it is refreshing to witness deno surpasses bun in a benchmark!
Re: Turbocall – Just-in-time compiler for Deno FFI
#4Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?
Re: Turbocall – Just-in-time compiler for Deno FFI
#5Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?
This feature and these APIs have been in Demo for a few years at this point.
Re: Turbocall – Just-in-time compiler for Deno FFI
#6This is one of the approaches for FFI taken by other runtimes, however it has the issue that without binding generators (jextract, P/Invoke code generators, ctypesgen), the type declarations are a pain to write. Thus something like this would need a similar tool.
deno_bindgen exists which can be used to do this from Rust.
I have written a partial solution for C, though it is bespoke for my libclang bindings, and a very rough one for C++. Both of these require more work to really be ready-to-use tools however.
[1] libclang C binding generator: https://github.com/aapoalas/libclang_deno/blob/main/build/bu...
[2] C++ binding generator: https://github.com/aapoalas/txx
Re: Turbocall – Just-in-time compiler for Deno FFI
#7This is one of the approaches for FFI taken by other runtimes, however it has the issue that without binding generators (jextract, P/Invoke code generators, ctypesgen), the type declarations are a pain to write. Thus something like this would need a similar tool.
deno_bindgen exists which can be used to do this from Rust. I have written a partial solution for C, though it is bespoke for my libclang bindings, and a very rough one for C++. Both of these require more work to really be ready-to-use tools however. [1] libclang C binding generator: https://github.com/aapoalas/libclang_deno/blob/main/build/bu... [2] C++ binding generator: https://github.com/aapoalas/txx
I see, thanks for the heads up.
Re: Turbocall – Just-in-time compiler for Deno FFI
#8We built something similar for pypy! See the blog post: https://bernsteinbear.com/blog/typed-c-extensions/ and paper: https://arxiv.org/abs/2403.02420
TL;DR: similar speedups! It works well
Re: Turbocall – Just-in-time compiler for Deno FFI
#9There have been a lot of security bugs in Chrome related to this layer of V8, most of them caused by some form of type confusion. Is there worry about increasing the size of Deno's attack surface by adding this capability?
Re: Turbocall – Just-in-time compiler for Deno FFI
#10Honestly I feel like they should work first on API compatibility with NodeJS just so that it can be easier to adopt/migrate seamlessly, then try more improvements in the runtime. It's nice that they have performance optimizations but what are they good for when I can't use Deno because it's not compatible/missing APIs?
This is only one strategy to get adoption. The other is to have better apis/more features so that new projects gradually move to your runtime.
In this hypothetical, eventually being on node would become like still being on java 8 is today.