Steven H. Rogers wrote:
Michael Hudson wrote:
"Steven H. Rogers" <[EMAIL PROTECTED]> writes:
Michael Hudson wrote:
Armin Rigo <[EMAIL PROTECTED]> writes:
Hi all,
I took the liberty to forward here the following e-mail from Michele Simionato, as it contains interesting links.
I think Michele is using a different definition of "JIT" to me...
As I told you in the conference, I think you should check in the Lisp/Scheme world where there is an astonishingly amount of knowledge about JIT and in general about compiling to C code fast.
While not disputing the general thrust of this, I would say that I am aware of *no* work on using run-time information to improve compilation in a Lisp or a Scheme system (this surprises me, and I have looked for it a bit, but I may have missed something).
While not automated like a Java JIT, the compiler is an integral part of the language in Lisp and may be used by the application programmer to compile code at run time.
Eh, this sounds too hostile, but: were you under the impression that I didn't know this?
No hostile intent, just curious. What made you think it hostile? You did give the impression that you were not aware of it, which seemed surprising.
Also, very few serious common lisp implementations go via C (the only one I can think of that does is GCL).
CLISP is written in largely in C. SBCL has replaced much of the assembler in CMUCL with C for greater portability.
That's not what I or Michele said, though: GCL translates the code the user supplies into C and calls gcc to compile it to object code (I understand; I've never used it).
Relevant projects I know of are:
- SBCL, a JIT compiler for Common Lisp;
SBCL is not a JIT compiler in the sense I understand the words.
What is your understanding of JIT compiler?
Well, at the minimum performing compiling-type activities at what the user would consider runtime, but unless this takes advantage of runtime information it's fairly pointless. I don't count typing code into the REPL for this -- do you?
Natively compiling Lisps can perform all compiling type operations at runtime, but it's up to the application programmer to specify this. Code typed into the REPL will be compiled using the information available in the environment at that point in time, so this should qualify as JIT compilation for this limited application.
given that is hard in that case to distinguish definition time from execution time and for just a defun what happens is mostly compilaton and not execution it is hard to pin that down. Conceptually I think compilation in that case happens before execution so it is not a JIT. JIT as terminology makes most sense when there is a some intermediate form which is not source code that is compiled as needed at runtime, and the intermediate form could be executed in some other way, and is produced in a phase that is distinguished from runtime (In Smalltalk IDEs traditionally bytecode is produced when modying methods and native compilation happens when those are run). So it makes most sense for VMs, for example a C++ compiler taylored for compilation speed to give fast tournaround in an IDE is not typically classified as JIT. Until considerations of dynamic optimization come into the picture there is nothing intrisically good or bad about JITs. Many Common Lisp sytstems have native compilers and nice interactive modes that in some impl can use just the native compiler and not interpretation, but using the term JIT seem more confusing than useful. I think the crucial point here is the linking model (through symbols) which allows functions to be easily self-contained compilation units.
_______________________________________________
[email protected]
http://codespeak.net/mailman/listinfo/pypy-dev
