7 ms·
One thing is that the "C stuff" can actually be, like, fortran stuff, because of LAPACK and BLAS and what have you, depending on the implementation your numpy i
by makmanalp 10y ago
One thing is that the "C stuff" can actually be, like, fortran stuff, because of LAPACK and BLAS and what have you, depending on the implementation your numpy is using.
- chrisseaton 10y agoNo problem - let's interpret FORTAN too. What we actually do is interpret LLVM IR, so if you can compile your language to that we can interpret it.
- DanWaterworth 10y agoThis is more difficult than you might think. LLVM IR more like a family of closely related, but poorly-specified languages, than a language of its own. There is an interpreter in the LLVM codebase, but this is essentially only possible because it is part of the codebase and so tracks the rest of the project very closely.
- cygx 10y agoThis is more difficult than you might think. Note that chris is not talking in the abstract, but about an existing codebase: https://github.com/graalvm/sulong https://github.com/graalvm/sulong
- DanWaterworth 10y agoOK, that's impressive.
- dagss 10y agoOne of the main BLAS implementations (where lots of numerical computation spends 99% of its time) is OpenBLAs, hand-crafted assembly per CPU. Main competitor is Intel MKL, closed source. Even if you could interpret that code, your JIT-ing is not going to create exactly the same assembly and will thus perform worse. You can very easily get a C implementation that you can interpret easily but at least as output by a C compiler, that performance is nowhere near where you want to be. (I realize this is not a problem though, just have the JIT call the libraries, as long as the wrapper can be interpreted you are good.)