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" <p...@informatimago.com> À: e...@ecky.fr Cc: "Juan Jose Garcia-Ripoll" <juanjose.garciarip...@gmail.com>, ecls-list@lists.sourceforge.net Envoyé: Mardi 17 Juillet 2012 01:28:54 Objet: Re: [Ecls-list] Is ECL really interpreted ? e...@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 {}. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
