@rwxrwxrwx Common Lisp is still pretty new to me, so I did not know about this CFFI. Thanks for letting me know! This will definitely make it easier for me to interface with various libraries.
I wonder if GCC can do something similar with libffi? I should look into that.
@ramin_hal9001
I never used seriously ECL and CLASP, but only started some session and read some documentation.
IRRC: ECL and CLASP are in worst case condition also 20x times slower than SBCL on some pure Common Lisp code; ECL functions can be called directly from C, because the ECL run-time is very C-friendly and with minimal or non-existent overhead; CLASP is doing the same but with C++, thanks to its integration with the LLVM compiler; interaction between SBCL and C code has always some overhead because the two run-times are very different; I don't know if this overhead of SBCL can be reduced if you interact mainly with vectors of fixed-size integers and similar data-structures, but if you have an API with a lot of calls, you had to pay a price.
BTW, it's impressive starting an ECL or CLASP environment, with all access to C/C++ code, but having a friendly REPL. Python is slower and it does not give this interactivity.
@emacs.ch @rwxrwxrwx
Summing up, my impression is that ECL and CLASP are better than SBCL when you want to use CL for "orchestrating" the calling of C or C++ libraries, because the overhead is nearly zero.
The business logic will be in Common Lisp, and thanks to macro you can reduce the boilerplate, also creating DSL. But all the hard algorithms will be in C/C++.
Instead, if you had to write an hard algorithm in Common Lisp, SBCL is faster.
