Hello, As Stephan Eggermont said, you need to make some measurements.
There are a few big problems. In short, if the FFI call is going to do quite some computation (at least a few millisecond), assuming tinyC has performance similar to gcc or llvm, you may get faster, if the FFI call is going to do very little (calling Math.abs() for example as Pharo has no primitive for abs), the overhead of the call is going to be too big. Maybe you can make your runtime with C worth it, but for example it's clear that if you write tiny methods in C for reusability / modularity of your code and you bind each tiny method to the smalltalk runtime, using those tiny methods one by one is not going to be worth it. However, if you write a merge sort or another algorithm fully in C and do a single call to the algorithm to sort a collection, on large collection and large collections only, it's going to be worth it. In details, the main problems are: - the Smalltalk stack has specific constraints, like hand-written stack page management to support heavy stack manipulation (setting sender of a context from the image). Hence, a C stack cannot just grow inside the Smalltalk stack as in other languages directly integrated to C. The way FFI tackles this problem is by using the interpreter C stack to execute C code. This is problematic as the runtime needs to switch from assembly runtime (Smalltalk method generated from the jit) to C runtime for the FFI call and then switch back, which induces overhead in jitted code, i.e., performance critical code. Maybe you could change the way the jitted code activates C code by checking the stack size needed by the dynamic lib API and if there is enough room on the smalltalk stack, then call it on the Smalltalk stack, though it creates other problems (what if garbage collection happens from another native thread while the FFI call is performed in non blocking FFI ?). - you need to convert types between Smalltalk to C at each call inducing FFI call overhead or makes the C code aware of your data structures which you have to support for those Smalltalk data structure yourself and induces some overhead in the C runtime. In Smalltalk/X, the C runtime is directly integrated in the Smalltalk runtime. You can ask Jan Vrany how he does it. But I think he doesn't have our hand written stack management (I am not 100% sure). 2016-02-28 2:04 GMT+01:00 Stephan Eggermont <step...@stack.nl>: > On 26/02/16 20:30, Dimitris Chloupis wrote: > >> I was thinking it would still be cool to have some kind of library that >> will help us boost the speed of pharo . So I was thinking about a C >> inliner which is far easier than an Assembly inliner (see AsmJIT) I also >> found TinyC >> > > The first thing to test is if TinyC is actually faster than Pharo. > > Stephan > > > >
