Fwd: michele.simionato@gmail.com: ACCU conference aftermath
Hi all, I took the liberty to forward here the following e-mail from Michele Simionato, as it contains interesting links. ----- Hi Armin! I much enjoyed your talks and I have posted my impressions about them on c.l.py. (http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/72446...) 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. Relevant projects I know of are: - SBCL, a JIT compiler for Common Lisp; - Bigloo, a high performance Scheme->C compiler; - Chicken, another easy Scheme->C compiler. All these projects are free software and they are actually working products, not just experimental stuff. SBCL is mostly developed in the US I think (it is the successor to the Carnegie Mellon Common Lisp), Bigloo is developed in France by Manuel Serrano whereas Chicken is developed in Germany by Felix Winkelman. I am an user of Chicken and I think Felix is a extremely nice and helpful guy. Here are a few links: http://sbcl.sourceforge.net/ http://www-sop.inria.fr/mimosa/fp/Bigloo/ http://www.call-with-current-continuation.org/ <cut end of mail>
Armin Rigo <arigo@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). Also, very few serious common lisp implementations go via C (the only one I can think of that does is GCL). Armed Bear Common Lisp is essentially Jython for CL (it compiles to bytecodes, not Java).
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.
- Bigloo, a high performance Scheme->C compiler; - Chicken, another easy Scheme->C compiler.
I don't know much about bigloo. Chicken is surely interesting, but I don't know how much type inference it does. I think it has a cute GC implementation (the "cheney on the mta" trick).
All these projects are free software and they are actually working products, not just experimental stuff. SBCL is mostly developed in the US I think (it is the successor to the Carnegie Mellon Common Lisp),
Actually I think most current work is done by Dan Barlow, Christophe Rhodes (who both live in London) and Alexey Dejneka (who is Russian), althought the project lead William Newman is indeed American.
Bigloo is developed in France by Manuel Serrano whereas Chicken is developed in Germany by Felix Winkelman. I am an user of Chicken and I think Felix is a extremely nice and helpful guy.
I remember him that way from way back when I used to read comp.lang.scheme. Cheers, mwh -- Hey, if I thought I was wrong, I'd change my mind. :) -- Grant Edwards, comp.lang.python
Michael Hudson wrote:
Armin Rigo <arigo@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. SBCL uses this in it's REPL to give the illusion of an interpreter; each expression is compiled as it is read. AFAIK, run time optimizations are the responsibility of the application.
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.
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? -- Steven H. Rogers, Ph.D., steve@shrogers.com Weblog: http://shrogers.com/weblog "Reach low orbit and you're half way to anywhere in the Solar System." -- Robert A. Heinlein
"Steven H. Rogers" <steve@shrogers.com> writes:
Michael Hudson wrote:
Armin Rigo <arigo@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?
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? Cheers, mwh -- NUTRIMAT: That drink was individually tailored to meet your personal requirements for nutrition and pleasure. ARTHUR: Ah. So I'm a masochist on a diet am I? -- The Hitch-Hikers Guide to the Galaxy, Episode 9
Michael Hudson wrote:
"Steven H. Rogers" <steve@shrogers.com> writes:
Michael Hudson wrote:
Armin Rigo <arigo@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. Regards, Steve -- Steven H. Rogers, Ph.D., steve@shrogers.com Weblog: http://shrogers.com/weblog "Reach low orbit and you're half way to anywhere in the Solar System." -- Robert A. Heinlein
Steven H. Rogers wrote:
Michael Hudson wrote:
"Steven H. Rogers" <steve@shrogers.com> writes:
Michael Hudson wrote:
Armin Rigo <arigo@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.
Michele Simionato wrote:
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.
Michael Hudson wrote:
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).
This surprises me too.
Also, very few serious common lisp implementations go via C (the only one I can think of that does is GCL).
Yes, GCL compiles to C, and there's also ECL (which I found to be interesting recently): http://ecls.sourceforge.net/ In general, all KCL(Kyoto Common Lisp)-derived CL implementations go via C, and they all share the common root. Seo Sanghyeon
Sanghyeon Seo <sanxiyn@gmail.com> writes:
Michael Hudson wrote:
Also, very few serious common lisp implementations go via C (the only one I can think of that does is GCL).
Yes, GCL compiles to C, and there's also ECL (which I found to be interesting recently): http://ecls.sourceforge.net/
Oh yes, I'd forgotten about that one. Thanks.
In general, all KCL(Kyoto Common Lisp)-derived CL implementations go via C, and they all share the common root.
Yes, but GCL is the only one of these that's still around in a meaningful sense, isn't it? Cheers, mwh -- You sound surprised. We're talking about a government department here - they have procedures, not intelligence. -- Ben Hutchings, cam.misc
Not Common Lisp, but Lush (http://lush.sf.net) is a Lisp dialect that compiles natively using using C as an intermediate language. It was developed as a scripting language for machine learning research and has been used in commercial applications. It also alows inline use of C. Linj (Lisp is not Java, http://www.evaluator.pt/downloads/tutorial.html) translates from idiomatic Lisp to idiomatic Java and back, allowing Lisp programmers to work on Java projects without writing any Java code. Haven't tried it, so I don't know how well it lives up to this goal, but you might find it interesting/useful. Michael Hudson wrote:
Sanghyeon Seo <sanxiyn@gmail.com> writes:
Michael Hudson wrote:
Also, very few serious common lisp implementations go via C (the only one I can think of that does is GCL).
Yes, GCL compiles to C, and there's also ECL (which I found to be interesting recently): http://ecls.sourceforge.net/
Oh yes, I'd forgotten about that one. Thanks.
In general, all KCL(Kyoto Common Lisp)-derived CL implementations go via C, and they all share the common root.
Yes, but GCL is the only one of these that's still around in a meaningful sense, isn't it?
Cheers, mwh
-- Steven H. Rogers, Ph.D., steve@shrogers.com Weblog: http://shrogers.com/weblog "Reach low orbit and you're half way to anywhere in the Solar System." -- Robert A. Heinlein
On 28 Apr 2005, at 12:31, Michael Hudson wrote:
Yes, but GCL is the only one of these that's still around in a meaningful sense, isn't it?
ECL is very much meaningful. If anything, I think that it has been more meaningful than GCL for quite some time, though GCL seems to have experienced a bit of a revival. Not being an active user of either, my impressions could be a bit warped, though.
Hi Michael, On Wed, Apr 27, 2005 at 11:56:20AM +0100, Michael Hudson wrote:
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...
Thanks to Michael and others for reminding us that -- althought my own nose is very much stuck in the details of C code generation at the moment -- this is not the goal of PyPy per se but just an intermediate phase before we can do much better. I know the last talks I gave about PyPy were about that, but that's because that's where we are now working, and it's the first tangible result we can demonstrate (the alternative being yet another "we-can-do-it" talk "supported" by prototypes 2000 times slower than CPython...). There are lots interesting projects out there about various forms of compilation and optimization, and PyPy looks quite similar to some of them, particularly the "elegant" ones, which makes the analogy all the more tempting. But to compete with these systems we'd have to put a real lot of efforts into generating the best possible C code. Looking at extremely powerful static compiler, even if the "math" part in me thinks about how nice and elegant they are, another part in me ends up feeling like it's all wasted efforts... A bientôt, Armin.
participants (6)
-
Armin Rigo -
Jacek Generowicz -
Michael Hudson -
Samuele Pedroni -
Sanghyeon Seo -
Steven H. Rogers