[pypy-dev] Re: Fwd: michele.simionato at gmail.com: ACCU conference aftermath

Samuele Pedroni pedronis at strakt.com
Thu Apr 28 14:33:25 CEST 2005


Steven H. Rogers wrote:

>
>
> Michael Hudson wrote:
>
>> "Steven H. Rogers" <steve at shrogers.com> writes:
>>
>>
>>> Michael Hudson wrote:
>>>
>>>> Armin Rigo <arigo at tunes.org> 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.



More information about the Pypy-dev mailing list