[Ecls-list] Is ECL really interpreted ?

[ecky at ecky.fr]

Ok then,

I think I found "my" language because I retained of this discussion the following :
1. ECL has a simple simple interface to C, especially it is possible to load compiled libraries dynamically and use them within ECL code.
2. ECL is able to compile functions (or a bunch of) if necessary and integrate the result to the systems code-base.

The fact that it is time-consuming to compile functions and load them is not a problem, it will get applied only if the function is time-critical, ie if the system detects that some loop is operating too slowly and extensively used (auto-profiling). This last point will not be important in the beginning but I don't want to get locked up later ... for the beginning I'll have to implement some proofs of concept that won't use this feature.

Thanks to all
CU later
ecky

----- Mail original -----
De: "Pascal J. Bourguignon" <pjb at informatimago.com>
À: ecky at ecky.fr
Cc: "Juan Jose Garcia-Ripoll" <juanjose.garciaripoll at gmail.com>, ecls-list at lists.sourceforge.net
Envoyé: Mardi 17 Juillet 2012 01:28:54
Objet: Re: [Ecls-list] Is ECL really interpreted ?

ecky at ecky.fr writes:

> Hi,
>
> Thanks for all your replies, I think I'll end up getting my ideas
> straight ;-).
>
>> Note however that ECL does not do native compilation on demand.  It
>> does not have a JIT compiler to machine code if that is what you are
>> looking for. 
>>
> @Juan : Well now that is an interesting remark, as what I read (unless
> I'm mixing something up) I thought that ECL uses several steps to
> produce executable code (see
> http://ecls.sourceforge.net/ecldev/devel_5.html) and naively I figured
> that the compile function would trigger that process and somehow
> insert the machine-code compiled from generated c-code to the
> lisp-interpreter in order to replace the bytecode in order to speed
> up.
>
> Up to now I thought it was possible with LISP to have a program
> construct some arbitrary list and then just call EVAL on it in order
> to try to run that 'program' (should probably call it function to be
> exact) ... as for example (eval (append '(* 2) '(3 4))) actually does.
>
> What I plan to do is actually to construct a list like that : (defun f
> (...) ...) and call eval on that list ... this will certainly generate
> some function that may be used later on. Some of the functions
> generated that way will be fast enough for some general
> purpose. However I imagined that it was possible to use the compile
> command on some of these generated functions in order to transform
> that bit into machine code ... and have the byte-code replaced by
> it. I feel that this must be possible somehow with ECL perhaps I'm
> just trying to do it the wrong way ...

It's possible, but as Juan said, that calling COMPILE with the C
compiler on individual functions will be costly, since each call would
have to write some C source file, to fork a gcc process to generate a
binary, to fork a linker process to generate a shared library, the
dynamicall load that library wich will take at least a couple of pages
for perhaps 30 bytes of compiled code.

This is only an inefficiency due to the implementation choices of ECL,
other implementations include a built-in native code compiler that is
able to generate the compiled code directly in memory (but those
implementations have problems with systems preventing the execution of
data memory pages, such as secure linux or iOS…).


You still have various choices, such as writing the defun forms
generated to a .lisp file and using COMPILE-FILE to compile them all at
once, so that the cost of compiling them is O(1) instead of O(n).

If you can't generate all the functions at once, you can collect their
source sexp in a list, and when you want to compile them, write the
element of that list to the .lisp file to be COMPILE-FILE'd.

I would also advise you to do some profiling.  Byte-code virtual
machines can be very efficient, foremost on modern x86 processors  (but
of course, it depends on the architecture of the byte code, and on the
implementation of the VM).  The reason are the cache lines and the
pipelines. With a VM, the program is easily entirely in cache, and the
VM loop may be well pipeline optimized so that executing the byte code
is almost as fast as executing native code.  At least theorically.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.