3 ms·

You can expose objects. Here's how it is done in Bun: https://github.com/facebookresearch/shumai/blob/main/shumai/tensor/tensor.ts#L277 https://github.com/faceb

• cogman10 4y ago
  > I think you are vastly overestimating the complexity associated with this No, I think you are misunderstanding the problem. I'm not saying that, with a good 3rd party lib, generating FFI APIs can't be easy and slick. I'm saying that non-python languages have more complicated FFI APIs that practically necessitate these sorts of generation libraries (like bun). When you grab a bit of memory out of an object in C with python, you are reaching directly into python's internal representation of the object and tickling the bits there. When you do that with deno/javascript/others, there's a layer of abstraction introduced to keep our native method from directly tickling the bits that the VM is aware of. That's the problem. From C, you can create a new python object, store it off in a global variable, send it back to the python vm, and later in a thread go tickle some of the bits and see that tickling in the Python VM. Because that object is the same one used by Python and C. The complication that arises with CPython is many very popular librarys (numpy, tensorflow, pandas) rely HEAVILY on the fact that the objects they are working with in C are the same ones python uses. That's why they've been so slow to port to pypy if at all. And that ability for C libraries to very deeply interact with the VM is exactly the problem that makes it hard to improve CPython's JIT. That's the reason other python JITs, like pypy, either don't or have very limited support for CPython's FFI capabilities. The reason FFI works so well with other languages is they drew very tight and clear boundaries around how interactions work and who owns what when. So please, stop spamming "bun". It's a non sequitur.
  • brrrrrm 4y ago
    I'll concede that Python has more nuanced bits of complexity exposed, but I suspect a willingness to break compatibility for the sake of performance would benefit the language a lot more than it would hurt it. I personally hope the hacker mentality and the immensely perf-driven nature of JavaScript is one day adopted by Python. For those following, I want to make it clear that the "bits" being discussed are extremely nuanced and won't get in the way of doing obviously useful things in JavaScript. Here's how you create a JS Object from C using Node-API: https://nodejs.org/api/n-api.html#napi_create_object https://nodejs.org/api/n-api.html#napi_create_object It conforms to ECMAScript 6.1.7 Object Types and is very much the same internal representation used by the VM. Here's how one might tickle the internal representation used by Node.js (V8 in this case) to change the value of the underlying property of a JavaScript object from C: https://nodejs.org/api/n-api.html#napi_set_element https://nodejs.org/api/n-api.html#napi_set_element
    • cogman10 4y ago
      > but I suspect a willingness to break compatibility for the sake of performance would benefit the language a lot more than it would hurt it. That's already happen in the form of graalpy and pypy. The community has voted and they want compatibility more than they want performance.
    • HenriTEL 4y ago
      > I suspect a willingness to break compatibility for the sake of performance would benefit the language a lot more than it would hurt it It took a long time for the community to recover from the python3 incompatibility with python2. I don't think we are ready for another round.