Hi All,
it is a lot of years already as Lisp (with other
interpreter-based languages) implementations are blaimed
for performance. Those Lisp implementations, which are not
blaimed for performance have shortcomings with dynamic
definitions.
Are there any (opensource) project about creating JIT
compilers suited for dynamic languages?
However what I could find normaly is JIT-compilers
oriented for Java.
The only flavour I've managed to find was:
http://www.ai.mit.edu/research/abstracts/abstracts2002/dynamic-languages/07sullivan.pdf
in advance, thank you for your remarks, Dear All, and sorry
if my reply will be considerably delayed.
kind regards,
Valery
From: Joe Marshall
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <el17bt5m.fsf@ccs.neu.edu>
········@mail.ru (Valery) writes:
> Hi All,
>
> it is a lot of years already as Lisp (with other
> interpreter-based languages) implementations are blaimed
> for performance. Those Lisp implementations, which are not
> blaimed for performance have shortcomings with dynamic
> definitions.
It is true that for many years Lisp implementations were interpreter
only, but that changed in the early 60s. By the early 70s compiled
Lisp was competitive with FORTRAN. The notion that Lisp is slow
because it is interpreted has been wrong for close to 40 years.
Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
> It is true that for many years Lisp implementations were interpreter
> only, but that changed in the early 60s. By the early 70s compiled
> Lisp was competitive with FORTRAN. The notion that Lisp is slow
> because it is interpreted has been wrong for close to 40 years.
there were a lot of statements like yours in this thread.
And I do believe in what you say.
But I am speaking about compilation to native code of dynamically
created functions in run-time. Only. That's the point.
From: Joe Marshall
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <r8519ik3.fsf@ccs.neu.edu>
········@mail.ru (Valery) writes:
> Joe Marshall <···@ccs.neu.edu> wrote in message news:<············@ccs.neu.edu>...
>
> > It is true that for many years Lisp implementations were interpreter
> > only, but that changed in the early 60s. By the early 70s compiled
> > Lisp was competitive with FORTRAN. The notion that Lisp is slow
> > because it is interpreted has been wrong for close to 40 years.
>
> there were a lot of statements like yours in this thread.
> And I do believe in what you say.
>
> But I am speaking about compilation to native code of dynamically
> created functions in run-time. Only. That's the point.
So am I.
Several years ago I was working on a Lisp program that did a lot of
parsing of output from old FORTRAN programs. It turned out that this
text parsing was the major bottleneck in the program. The parser had
to do things like find a particular string, go to some numeric
field after that string and parse the number expected there. (It
would, for example look for the string `Total: '). The string
searched for would vary by application, but any particular run of the
program would only be looking for a small number of fixed strings.
What I did was construct the appropriate tables for a Boyer-Moore
string search. But rather than use those tables as a parameter in a
generic Boyer-Moore program, I generated lisp source code that
used the tables directly. This source code was fed to the compiler
which generated optimized machine code. Both the source code and the
machine code were in-memory constructs only, and were never placed in
a file or transmitted out of the process. When time came to search
for the string, a simple jump to the generated code would return the
appropriate string index.
I believe this is what you are referring to.
----
In detail, given the string "Total: ", the resulting lisp code would
be something like below. One trick was to encode the matching leading
character as a fake `mismatch' with a huge shift value so that the
main loop was as tight as possible.
(defun search-for-total (string)
(let ((l (length string)))
(and (>= l 6)
(let ((current-position 6)
(l1 (- l 6)))
(loop
(cond ((< current-position l1)
(incf current-position
(svref #(...) ;; inlined shift table
(char-code (schar string current-position)))))
;; Either
;; 1. We fell off the end. And are done.
((< current-position l) (return nil))
;; 2. We hit a space character.
(t (decf current-position *match-first-char-hack*)
(if (char= (schar string (- current-position 6)) #\T)
... check other positions ...
(incf current-position 6)))))))))
········@mail.ru (Valery) writes:
> Hi All,
>
> it is a lot of years already as Lisp (with other
> interpreter-based languages) implementations
It may not be your intent. Perhaps it's just a cross-cultural issue where
you feel like you need to enter with a bold statement, but you're making
your initial mark badly. The form of this statement is what is often
referred to as "flame bait". To use the standard legal terminology,
"it presupposes facts not in evidence".
Sometimes in English we refer to these as "Have you stopped beating
your wife?" questions. The question cannot be addressed directly
because it has built into it a dangerous presupposition that must be
addressed first.
Common Lisp, for which the first specification was published in 1984
(19 years ago) is defined in a way that permits either an interpreter
or compiler to execute with identical semantics.
Scheme, if you count it as part of the same language family, was
created in the late 1970's, and one of its primary uses was to demonstrate
the efficient compilation of Lisp.
MACLISP, INTERLISP, and numerous other earlier dialects of Lisp going
back another decade or more into the mid to late 1960's were routinely
compiled even though there were glitchy differences between
interpreted and compiled code back then, primarily because computer
science was bootstrapping itself and the importance of a language
definition separated from implementation behavior was
less-well-understood at that time; languages at that time were
frequently were more like evolving toolboxes than contracts.
Even the earliest versions of Lisp, such as Lisp 1.5 addressed issues
of compilation, although it was weirder and weirder as you get to the
early days where there just was not an organized pervasive paradigm
around which the field organized its needs and uses.
Compiled MACLISP on the PDP10 in the early 70's was as fast as (I
think maybe even faster than) DEC FORTRAN on the same machine.
Ironically, at the time that many professors were standing up to
lecture halls full of eager CS students in the 1970's creating the
stupid myths about Lisp being interpreted-only that would haunt us for
literally generations, Lisp was ALREADY being compiled, including
incremental compilation, laying the essential foundation for modern
buzzwords like JIT, which Lisp has had for a long time. Those CS
students became the IT directors of the major corporations for decades
and carried their confused notions about what Lisp was and wasn't
right along with them, assuring that Lisp would be locked out of the
mainstream.
It's been 30 or 40 years since Lisp was what you say, an
interpreted-only language, if it can in fact be established that it
was EVER an interpreted-only language. Please do not propagate
this myth.
> Those Lisp implementations, which are not blaimed for performance
> have shortcomings with dynamic definitions.
I don't know what this is about, but I'll just say that if you have a
specific personal concern of your own, raise it. Do not assert as
fact what others say in general terms, because there is no way to
cross-examine those people to find out what on earth they could even
mean by this. To answer your apparent question/challenge in its
presented form would require defending all possible aspects of the
language against all possible nutty claims.
If there is one of those claims that you personally are worried by,
take personal responsibility for that by saying "I am worried that xxx"
and let someone help you be less worried. Or say "I have been unable
to get Lisp accepted because people say it is xxx. What do I tell them?"
and we can help you with that. But we need more specifics on the xxx
part and the ability to ask detailed questions or we will go nowhere.
Kent M Pitman wrote:
> ...
> Scheme, if you count it as part of the same language family, was
> created in the late 1970's, and one of its primary uses was to
> demonstrate the efficient compilation of Lisp.
>
> MACLISP, INTERLISP, and numerous other earlier dialects of Lisp going
> back another decade or more
> ...
> Ironically, at the time that many professors were standing up to
> lecture halls full of eager CS students in the 1970's creating the
> stupid myths about Lisp being interpreted-only that would haunt us for
> literally generations,
> ...
So here you perpetuate the stupid myth that Scheme is not or might not
be Lisp. Not only is that obviously wrong, but you contradict yourself
in the very next sentence. Considering that both CL and Scheme use
static scope, the adherents of MACLISP and INTERLISP (which use dynamic
scope) who split hairs in the particular fashion that you do would not
regard either of them "Lisp".
A very thorough and well-informed history on Lisp compilation:
http://www.paulgraham.com/thist.html
Your criticism of the professors is equally illogical as you fault them
for doing the same thing that you say their students do, which is to
apply what they learned while they were students. As for their
responsibility to stay current with the state-of-the-art, same goes for
the titans of industry.
Jim
From: Kenny Tilton
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <3F076808.9070209@nyc.rr.com>
Jim White wrote:
> Kent M Pitman wrote:
>
>>...
>>Scheme, if you count it as part of the same language family, was
>>created in the late 1970's, and one of its primary uses was to
>>demonstrate the efficient compilation of Lisp.
>>
>>MACLISP, INTERLISP, and numerous other earlier dialects of Lisp going
>>back another decade or more
>>...
>>Ironically, at the time that many professors were standing up to
>>lecture halls full of eager CS students in the 1970's creating the
>>stupid myths about Lisp being interpreted-only that would haunt us for
>>literally generations,
>>...
>
>
> So here you perpetuate the stupid myth that Scheme is not or might not
> be Lisp. Not only is that obviously wrong, but you contradict yourself
> in the very next sentence.
Point of information: all the OP was acknowledging was that /some
people/ do not place Scheme in the same language family, and is that not
simply a fact? However extreme that position might be?
And if what he said next then treats Scheme as a Lisp, that just implies
he is not one of those exclusionists. So there is no contradiction, and
it sounds as if you two agree on the issue.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> It may not be your intent. Perhaps it's just a cross-cultural issue where
> you feel like you need to enter with a bold statement, but you're making
> your initial mark badly. The form of this statement is what is often
> referred to as "flame bait". To use the standard legal terminology,
> "it presupposes facts not in evidence".
(first of all thank you for your long interesting post.)
Well, you pointed out my worst property. I know I am not the best
diplomat in the world. However I hope it comes a bit with years :)
But this is rather for private correspondence :)
> It's been 30 or 40 years since Lisp was what you say, an
> interpreted-only language, if it can in fact be established that it
> was EVER an interpreted-only language. Please do not propagate
> this myth.
never ever and never before!
it is not an interpreted-ONLY language, but it is an
interpreted-ALSO language. In particular, it means that
source code might be created or imported in run-time and
executed. (Sorry for this free statement).
I'd say you forget to mention about another (opposite)
bad tendency concerning Lisp:
Lisp developers are very eager to show that their
implementations can be as fast as C. For this goal
they shift prioreties to "compile before run" and
forget about all dynamics coming with Lisp.
Of course it is not for this thread/topic but:
Lisp should not compete with C-like languages at the
*same* domain.
Read it like that: "C-like languages shouldn't compete with
Assembler in Assembler's domain"
Actually focus of my attention today at properties with
"dynamic" flavour coming with Lisp family. It is exactly
what I can't get even from C# with its reflections.
The problem is that dynamically created code is still
slow, because of no compilation to a native code.
If you know a good implementation please give me a hint.
> > Those Lisp implementations, which are not blaimed for performance
> > have shortcomings with dynamic definitions.
> I don't know what this is about,
I've given a lot of reformulations for what I need from
"dynamics". If I could make some additional clarifications
please let me know.
> but I'll just say that if you have a
> specific personal concern of your own, raise it. Do not assert as
> fact what others say in general terms, because there is no way to
> cross-examine those people to find out what on earth they could even
> mean by this. To answer your apparent question/challenge in its
> presented form would require defending all possible aspects of the
> language against all possible nutty claims.
> If there is one of those claims that you personally are worried by,
> take personal responsibility for that by saying "I am worried that xxx"
> and let someone help you be less worried. Or say "I have been unable
> to get Lisp accepted because people say it is xxx. What do I tell them?"
> and we can help you with that. But we need more specifics on the xxx
> part and the ability to ask detailed questions or we will go nowhere.
smart. But who could help us/me be less ambiguous? :)
One more point, from post number 100, I've started to skip
saying "I am sorry for any wrong flavours in my post,
because it is not my native language". However it is not
for public discussion as well :)
thank you for your nice post,
best regards,
Valery
········@mail.ru (Valery) writes:
> never ever and never before!
> it is not an interpreted-ONLY language, but it is an
> interpreted-ALSO language. In particular, it means that
> source code might be created or imported in run-time and
> executed. (Sorry for this free statement).
>
> I'd say you forget to mention about another (opposite)
> bad tendency concerning Lisp:
>
> Lisp developers are very eager to show that their
> implementations can be as fast as C. For this goal
> they shift prioreties to "compile before run" and
> forget about all dynamics coming with Lisp.
It seems you've been missing part of what people have tried to tell
you here: the above is completely false. For the moment, let's
consider only one implementation of CL, Macintosh CL. Just like C,
Fortran, et al, you can write a source file, compile it, then load it.
*Also*, you can type code into the toplevel, construct code at
runtime, etc. MCL compiles this code as well. It doesn't even have
an interpreter. This is the reason we don't need JITs, because we
have an equivalent system. It's sort of like asking the French if
they have gallons; no, they don't, but only because gallons are part
of the imperial measuring system, and they have a different system
(metric) that does the same thing.
Common Lisp *allows* the existence of an interpreter, but you're
perfectly able to work without one, because it *requires* a compiler
that's available at runtime.
> Of course it is not for this thread/topic but:
>
> Lisp should not compete with C-like languages at the
> *same* domain.
>
> Read it like that: "C-like languages shouldn't compete with
> Assembler in Assembler's domain"
If you concede that C has no appropriate domain outside of the
construction of Unix kernels, I'll agree :-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@famine.OCF.Berkeley.EDU (Thomas F. Burdick) wrote in message news:<···············@famine.OCF.Berkeley.EDU>...
> ········@mail.ru (Valery) writes:
> > Lisp developers are very eager to show that their
> > implementations can be as fast as C. For this goal
> > they shift prioreties to "compile before run" and
> > forget about all dynamics coming with Lisp.
>
> It seems you've been missing part of what people have tried to tell
> you here: the above is completely false.
Should I confirm that it is clear for me now (and before
writing the post above) that compile-to-native-in-run-time
is present in a big number of CL-implementations?
Now let's consider my statement again.
It is about 5 years as I am tracking Lisp. No, I am not
really involved in Lisp developments of any kinds. (It's
a pity, because I'd like). What I'd like to say now:
even after 5 years of looking in Lisp implementations
there is a conservative opinion (about Lisp implementations
performnce) still induced on me.
Could we assume that "false/out-of-date opinions" is
not really my exclusive/personal/unique problem?
Could we assume that Lisp community fails to bring
some facts even into ears positively open for Lisp
successes? (not just in *my* ears)
However it is rather for anther topic.
> > Read it like that: "C-like languages shouldn't compete with
> > Assembler in Assembler's domain"
>
> If you concede that C has no appropriate domain outside of the
> construction of Unix kernels, I'll agree :-)
I am not that extremal.
/Valery
In article <····························@posting.google.com>,
········@mail.ru (Valery) wrote:
> Could we assume that "false/out-of-date opinions" is
> not really my exclusive/personal/unique problem?
>
> Could we assume that Lisp community fails to bring
> some facts even into ears positively open for Lisp
> successes? (not just in *my* ears)
There are essentially two forces that stand in the way: One is that the
Lisp community is relatively small and the other is that wrong notions
about Lisp are wide spread.
None of the vendors has the big money to spend in marketing campaigns
like Sun and Microsoft do, and Lisp is not as fashionable as the
scripting languages of our times.
> If I am not mistaken, Allegro is nice, but very expensive.
> LispWorks has some restrictions in freely available version.
There is a free trial version of Allegro Common Lisp available that
doesn't have any restrictions for personal use. You need to renew your
licence key every 60 days, but this is an automated procedure.
One of the fashions of today is that everything has to be free. Consider
that it might be worthwhile to buy one of the Common Lisp
implementations. You get excellent support in return. (And Corman Lisp
is another implementation for Windows that is quite affordable.)
Of course, you might come to the conclusion that buying is not an option
for you, but don't dismiss it right away.
> > It's been thought about. I don't think Parrot is nearly mature enough
> > yet though. And I'm not really expecting much out of Parrot, because
> > it's designed by Perl people.
>
> Look, at least they were clever enough to consider success shown
> by JVM. I hope "Lisp's fathers" (i.e. those who create Lisp
> impl.) will consider this as well. Especially those who work
> for open source--there it is as twice as important to share.
Common Lisp is a big language and places some strong requirements on
implementations. If it turns out that Parrot is not suited for Common
Lisp it might turn out as a waste of time to port to Parrot as well.
Languages are not all alike except for syntactical differences. Most of
the mainstream languages are - and that's one of the reasons Microsoft
can claim that .NET is language neutral - but some language constructs
from different languages just don't play very well together. Don't
underestimate such problems.
> > There will probably be Lisp/Scheme ports for Parrot sooner or later, as
> > was the case for JVM and for .NET in the past.
>
> I hope. So much Lisp implementations could obtain a nice
> possibility to share optimization/codegeneration/VM layer.
> People who invest their in code optimization/generation
> in different Lisp implementations could join their effort
> for creating something better.
It's really far from being as simple as you seem to believe.
> > However, many people will
> > stick to their favorite Common Lisp / Scheme implementations that are
> > hard to beat. They have had sufficient time to mature over years, in
> > some cases decades, and newer implementations will need considerable
> > time to catch up.
>
> Are you speaking about developers who create Lisp
> implementations or about those who just use Lisp?
I am talking about those that use Lisp. Switching to a new Lisp
implementations is likely to be a step backwards, and it takes years for
an implementor to gain the same level of maturity as that of current
Common Lisp implementations.
> Only developers who create Lisp do matter concerning
> original question. Other could stuck even to their
> lovely Intel 386 -- nothing bad in that.
These two groups depend on each other. If users are not likely to switch
then vendors are not likely to switch either, and vice versa.
Pascal
Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
> I am talking about those that use Lisp. Switching to a new Lisp
> implementations is likely to be a step backwards, and it takes years for
> an implementor to gain the same level of maturity as that of current
> Common Lisp implementations.
sounds very bad.
I use C++ about 10 years. C++ is standardized about 5 year ago.
I'd never say something about C++ like you've
said about CL. Of course different C++ implementations have
their different strong and weak sides, but I'd hardly say
that I have difficulties to switch C++ implementation.
More then that, I do: not a full list is: gcc, icc,
watcom/open watcom, MS cl.exe, bcc, ... With any C++
implementation I'd rather have to speak about conformance
to a standard.
Pascal, you are well known person in a Lisp world. When guys
like you say something like that it is like a bomb. I hope
I've just misunderstood your point :)
/Valery
Valery wrote:
> Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
>
>>I am talking about those that use Lisp. Switching to a new Lisp
>>implementations is likely to be a step backwards, and it takes years for
>>an implementor to gain the same level of maturity as that of current
>>Common Lisp implementations.
>
> sounds very bad.
[...]
> Pascal, you are well known person in a Lisp world. When guys
> like you say something like that it is like a bomb. I hope
> I've just misunderstood your point :)
Indeed, I think you have misunderstood my point. Of course, switching
between different Common Lisp implementations is practical. This
shouldn't be any harder than in the C++ world.
However, the thread was about completely new implementations of Lisp,
for example based on Parrot. I just wanted to say that it is very
unlikely that a new Lisp implementation will soon become as mature as
the well-known and already existing Common Lisps.
So if you want an efficient, speedy and mature Lisp on Windows now,
don't hold you breath for something based on Parrot, .NET or the JVM. Go
for Allegro, LispWorks, Corman or CLISP now. :)
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
········@mail.ru (Valery) writes:
> Pascal Costanza <········@web.de> wrote in message news:<······························@news.netcologne.de>...
>
>> I am talking about those that use Lisp. Switching to a new Lisp
>> implementations is likely to be a step backwards, and it takes years for
>> an implementor to gain the same level of maturity as that of current
>> Common Lisp implementations.
>
> sounds very bad.
imagine yourself spending an hour extolling the virtues of your new
Lada car to somebody, who responds: hey, thanks, but I believe my
10-year-old Mercedes is perfectly fine.
now, it may sound bad to you (after all, you've just wasted a whole
hour of your life without even enjoying the process), but that would
be your own problem, not his, wouldn't it?
> I use C++ about 10 years. C++ is standardized about 5 year ago.
> I'd never say something about C++ like you've
> said about CL. Of course different C++ implementations have
> their different strong and weak sides, but I'd hardly say
> that I have difficulties to switch C++ implementation.
if you want me to explain Pascal's point (which you've missed
spectacularly) to you in small Russian words, feel free to drop me an
e-mail.
peace,
--m
--
Non-determinism means never having to say you're wrong.
From: Eduardo Muñoz
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <uel0zsb9j.fsf@terra.es>
* ········@mail.ru (Valery)
| The problem is that dynamically created code is still
| slow, because of no compilation to a native code.
| If you know a good implementation please give me a hint.
Compile code creates compiled code:
[2]> (defun main ()
(format t "~%Type a number: ")
(let* ((number (parse-integer (read-line)))
(fn (lambda (x) (+ number x))))
(if (compiled-function-p fn)
(format t "Running a compiled function!~%")
(format t "Running an interpreted function!~%"))
(dotimes (i 5)
(format t "~A " (funcall fn i)))))
MAIN
[9]> (main)
Type a number: 5
Running an interpreted function!
5 6 7 8 9
NIL
[10]> (compile 'main)
MAIN ;
NIL ;
NIL
[11]> (main)
Type a number: 7
Running a compiled function!
7 8 9 10 11
NIL
[12]>
--
Eduardo Mu�oz | (prog () 10 (print "Hello world!")
http://213.97.131.125/ | 20 (go 10))
Oops! ········@mail.ru (Valery) was seen spray-painting on a wall:
> Hi All,
>
> it is a lot of years already as Lisp (with other
> interpreter-based languages) implementations are blaimed
> for performance. Those Lisp implementations, which are not
> blaimed for performance have shortcomings with dynamic
> definitions.
>
> Are there any (opensource) project about creating JIT
> compilers suited for dynamic languages?
>
> However what I could find normaly is JIT-compilers
> oriented for Java.
>
> The only flavour I've managed to find was:
>
> http://www.ai.mit.edu/research/abstracts/abstracts2002/dynamic-languages/07sullivan.pdf
>
> in advance, thank you for your remarks, Dear All, and sorry
> if my reply will be considerably delayed.
I'm not aware of ANY implementations of Common LISP that were ever
purely interpreted. The notion that Lisp systems are
"interpreter-based" has largely been a fallacy for _YEARS_.
Probably the best set of information on the subject would be for you
to look at the implementation of the Python compiler that comprises a
vital component of CMU's Common Lisp implementation.
And you should also take a look at the fact that they don't _mandate_
using code compiled to machine code. Sometimes it is more beneficial
to merely "byte compile" the code, as that allows the code to be
vastly more compact since the byte code interpreter can take care of
details like memory access alignment and saving/restoring registers
where, if you compile to machine code, all of the bookkeeping code has
to be pushed into each and every function you compile.
I found, for instance, that when I compiled the "Calendrica" code
base, bytecode was about 1/6 the size of "machine code." For
infrequently-used code or code that is otherwise really memory hungry,
it can be a _win_ to not compile to machine code.
--
(reverse (concatenate 'string "gro.gultn" ·@" "enworbbc"))
http://cbbrowne.com/info/bytecode.html
"And the next time you consider complaining that running Lucid Emacs
19.05 via NFS from a remote Linux machine in Paraguay doesn't seem to
get the background colors right, you'll know who to thank."
-- Matt Welsh
Christopher Browne <········@acm.org> wrote in message news:<·············@ID-125932.news.dfncis.de>...
> I found, for instance, that when I compiled the "Calendrica" code
> base, bytecode was about 1/6 the size of "machine code." For
> infrequently-used code or code that is otherwise really memory hungry,
> it can be a _win_ to not compile to machine code.
well, I have no illusions concerning efficiency of
native code size, say, for Pentium. It is extremely
"overblowed". I do remember what one could do in 64K
of Intel 8080 or even in Z80.
But this is not the point at all here.
I am interested simply in a speed of calculation,
which is ALWAYS better in native code.
········@mail.ru (Valery) writes:
> Christopher Browne <········@acm.org> wrote in message news:<·············@ID-125932.news.dfncis.de>...
>
> > I found, for instance, that when I compiled the "Calendrica" code
> > base, bytecode was about 1/6 the size of "machine code." For
> > infrequently-used code or code that is otherwise really memory hungry,
> > it can be a _win_ to not compile to machine code.
>
> well, I have no illusions concerning efficiency of
> native code size, say, for Pentium. It is extremely
> "overblowed". I do remember what one could do in 64K
> of Intel 8080 or even in Z80.
>
> But this is not the point at all here.
>
> I am interested simply in a speed of calculation,
> which is ALWAYS better in native code.
Well, CMU Lisp will do both. It will compile to native code and to
byte code. The byte code compiler was a later add-on (the native code
compiler came first). The idea was to decrease the size of the Lisp
images for machines in the Sparstation 1, 1+, 2 era, which were
limited in memory.
Careful use of byte coding can produce a Lisp image which will run
faster under memory limited conditions because it won't have to swap
so much. This is, by the way, a counterexample to your claim that
speed of calculation is always better in native code. Caching effects
can sometimes produce similar effects even now.
I still set the :small feature in my CMUCL builds to build the
smaller, partially byte-coded cores, and from what I recall the
regression benchmarks show little or no loss of raw speed.
To sum up the state of the argument,
1) Lisp is a compiled language.
2) Most Lisp implementations use native-code compilers.
3) Some are completely byte-coded (elisp, CLISP), and one (that I know
of) has a native code compiler supplemented by a byte-code compiler
that can be used where size is more important than speed. (Note
that Lisp has an optimizer flag that lets you tell the complier
what code qualities you care about, and size is one of the
qualities that you can optimize for.)
4) JIT compilation for Lisp is kind of a "Huh, why do you care about
that?" issue, because you can compile whenever you want in Lisp.
Even more, you can create functions whenever you want. Compiled
functions; native code functions (if that's what you want).
5) The only legitimate question remaining is "If Lisp is so great why
isn't everyone using it?" to which I can only say, "Well, I am!" :-)
--
Fred Gilham ······@csl.sri.com
"I'm an expert at installing free software. I've installed software
packages that had 412 steps, the first two of which were 'Remove small
children and animals from the premises' and 'Don protective gloves and
mask'. If you made a mistake you had to go back to the very
beginning, including getting the kids and pets back in the house."
········@mail.ru (Valery) wrote:
> Christopher Browne <········@acm.org> wrote in message news:<·············@ID-125932.news.dfncis.de>...
>
>> I found, for instance, that when I compiled the "Calendrica" code
>> base, bytecode was about 1/6 the size of "machine code." For
>> infrequently-used code or code that is otherwise really memory hungry,
>> it can be a _win_ to not compile to machine code.
>
> well, I have no illusions concerning efficiency of native code size,
> say, for Pentium. It is extremely "overblowed". I do remember what
> one could do in 64K of Intel 8080 or even in Z80.
>
> But this is not the point at all here.
>
> I am interested simply in a speed of calculation, which is ALWAYS
> better in native code.
.. But if there is code that is not run very often, such as code for
initializing things, it may be a TOTAL WIN to run some bytecode for
the stuff that's NOT a performance bottleneck, whilst compiling to
native code the bits that are run all the time.
If having some of the program loaded in as bytecode allows you to add
an 8MB cache for frequently re-used objects, it would be very easy for
that to be more of a win than consuming the 8MB for code that wasn't a
bottleneck in the first place.
Having a CHOICE is better.
--
(reverse (concatenate 'string "gro.mca" ·@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/lsf.html
Coming Soon to a Mainframe Near You! MICROS~1 Windows NT 6.0,
complete with VISUAL JCL...
From: Kenny Tilton
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <3F04286C.6030301@nyc.rr.com>
Valery wrote:
> Hi All,
>
> it is a lot of years already as Lisp (with other
> interpreter-based languages)...
This is no longer true, and has not been true for (guessing) twenty
years. Almost all Common Lisp implementations compile to native code.
>.. implementations are blaimed
> for performance. Those Lisp implementations, which are not
> blaimed for performance have shortcomings with dynamic
> definitions.
I am not sure any self-respecting CL implementation had problems with
dynamic definitions. That is one of Lisp's strengths. What specific
shortcomings did you have in mind?
>
> Are there any (opensource) project about creating JIT
> compilers suited for dynamic languages?
>
> However what I could find normaly is JIT-compilers
> oriented for Java.
The good news is that you are making this way too hard for yourself.
Just get a decent CL implementation and go with it, yer done. Note
however that one very popular implementation is CLisp, which I believe
compiles to byte-codes, not native.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
> > it is a lot of years already as Lisp (with other
> > interpreter-based languages)...
> This is no longer true, and has not been true for (guessing) twenty
> years. Almost all Common Lisp implementations compile to native code.
on-fly? I mean, is it really so, that one could generate
function in run-time, compile it and run immediately?
I am not speaking about compilation of the file before
execution time.
> > Those Lisp implementations, which are not
> > blaimed for performance have shortcomings with dynamic
> > definitions.
> I am not sure any self-respecting CL implementation had problems with
> dynamic definitions. That is one of Lisp's strengths. What specific
> shortcomings did you have in mind?
to be exact, I've meant not CL, I've meant Bigloo (Scheme).
Native code obtained with this Scheme implementation is
as quick as by gcc. However it has problems with "define"
where define's body is known at run-time only.
(Actually it is in relation to another topic: why in
"R5RS 6.5." eval might deny evalution of non-S-expressions
e.g. with "define"?)
> > However what I could find normaly is JIT-compilers
> > oriented for Java.
>
> The good news is that you are making this way too hard for yourself.
> Just get a decent CL implementation and go with it, yer done. Note
> however that one very popular implementation is CLisp, which I believe
> compiles to byte-codes, not native.
well, which CL implementation do you mean then?
I'd like to emphasize I am speaking about Lisp familiy language
implementation, where function might be created in
run-time, compiled to a native code and executed.
thank you
kind regards,
Valery A.Khamenya
---------------------------------------------------------------------------
Bioinformatics Department
BioVisioN AG, Hannover
From: Marco Antoniotti
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <3F0AD4E7.8080103@cs.nyu.edu>
Valery wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>
>
>>> it is a lot of years already as Lisp (with other
>>> interpreter-based languages)...
>>
>>This is no longer true, and has not been true for (guessing) twenty
>>years. Almost all Common Lisp implementations compile to native code.
>
>
> on-fly? I mean, is it really so, that one could generate
> function in run-time, compile it and run immediately?
Yes. This has been like this since time immemorial.
>
> I am not speaking about compilation of the file before
> execution time.
>
>
>
>>> Those Lisp implementations, which are not
>>> blaimed for performance have shortcomings with dynamic
>>> definitions.
>>
>>I am not sure any self-respecting CL implementation had problems with
>>dynamic definitions. That is one of Lisp's strengths. What specific
>>shortcomings did you have in mind?
>
>
> to be exact, I've meant not CL, I've meant Bigloo (Scheme).
That is your problem. Maybe you should just drop Scheme and use real
languages with parenthesis. Or are you a quiche eater? :)
> Native code obtained with this Scheme implementation is
> as quick as by gcc. However it has problems with "define"
> where define's body is known at run-time only.
>
> (Actually it is in relation to another topic: why in
> "R5RS 6.5." eval might deny evalution of non-S-expressions
> e.g. with "define"?)
You are quoting a document whose main goal is to maintain itself short.
:) You should read something longer and more complete, like the CL
ANSI speck.
>
>
>>> However what I could find normaly is JIT-compilers
>>> oriented for Java.
>>
>>The good news is that you are making this way too hard for yourself.
>>Just get a decent CL implementation and go with it, yer done. Note
>>however that one very popular implementation is CLisp, which I believe
>>compiles to byte-codes, not native.
>
>
> well, which CL implementation do you mean then?
> I'd like to emphasize I am speaking about Lisp familiy language
> implementation, where function might be created in
> run-time, compiled to a native code and executed.
That is your problem again. There is no point nowadays not to use a
Common Lisp implementation. IMHO the issue of "Lisp family of
languages" is historically useful, but not all that relevant
pragmatically. If you are on Linux CMUCL is a good candidate. If you
are on Windows, you will need one of the commercial versions. If you
are on the Mac you are pretty much in the same boat. If you do not care
about "native" compilation, CLisp will do, regardless of platform.
Code written for one CL is far more portable than across any of the
godzillion Scheme implementations.
Cheers
--
Marco Antoniotti
Marco Antoniotti <·······@cs.nyu.edu> writes:
> You are quoting a document whose main goal is to maintain itself
> short. :) You should read something longer and more complete, like
> the CL ANSI speck.
Now, I know that languages like C++ and Java have pretty much caught
up with and surpassed CL in language size, but I'm still not sure I'd
call the ANSI spec a "speck" ;-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Marco Antoniotti
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <3F0B0577.50009@cs.nyu.edu>
Thomas F. Burdick wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
>
>>You are quoting a document whose main goal is to maintain itself
>>short. :) You should read something longer and more complete, like
>>the CL ANSI speck.
>
>
> Now, I know that languages like C++ and Java have pretty much caught
> up with and surpassed CL in language size, but I'm still not sure I'd
> call the ANSI spec a "speck" ;-)
Well. The ANSI standard is a prosciutto (di Parma). The Java and C++
ones are just "ham". :) (pun over pun intended :) )
Cheers
--
Marco
PS. Speck (or spek) is a kind of smoked and peppered prosciutto common
in the Italian Alpine North East. :)
········@mail.ru (Valery) writes:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>
> > > it is a lot of years already as Lisp (with other
> > > interpreter-based languages)...
> > This is no longer true, and has not been true for (guessing) twenty
> > years. Almost all Common Lisp implementations compile to native code.
>
> on-fly? I mean, is it really so, that one could generate
> function in run-time, compile it and run immediately?
Yes. One can do this, in a portable and convenient fashion.
> I am not speaking about compilation of the file before
> execution time.
Of course not! :-)
You can generate functions at run-time, compile them, and run them
immediately, without ever going through a file.
And you can substitute functions in running code, provided their
bodies have not been inlined (and I think some CL implementations even
keep track of what has been inlined and redo the inlining with the new
definition).
Regards,
Mario.
········@mail.ru (Valery) writes:
> > This is no longer true, and has not been true for (guessing) twenty
> > years. Almost all Common Lisp implementations compile to native code.
>
> on-fly? I mean, is it really so, that one could generate
> function in run-time, compile it and run immediately?
To make it clear: you can compile such run-time generated functions to
native optimized fast streamlined machine language and run them
immediately. :-)
Check out for example CMUCL or SBCL. Or ACL, MCL, OpenMCL, LispWorks,
Corman Lisp, etc.
CLisp, and some other implementations, only use bytecode, so they are
not what you seem to want.
...and check out www.cliki.net for more implementations and libs,
docs, etc.
Regards,
Mario.
Valery wrote:
> Hi All,
>
> it is a lot of years already as Lisp (with other
> interpreter-based languages) implementations are blaimed
> for performance. Those Lisp implementations, which are not
> blaimed for performance have shortcomings with dynamic
> definitions.
What you are probably trying to say is that Lisp can either be
interpreted and fully dynamic _or_ compiled and restricted wrt to dynamics.
However, this is not quite true. Nowadays, Common Lisp implementations
are very efficient and provide a high level of dynamicity at the same
time (and the rest of the world is slowly catching up).
For some benchmarks, consider http://www.norvig.com/python-lisp.html and
http://www.weitz.de/cl-ppcre/
Furthermore note that there is a common misunderstanding that efficiency
comes from micro-efficiency. In fact, the micro and macro levels are
considerably different in this regard. See for example,
http://www.paulgraham.com/popular.html and
http://www.cs.ucsb.edu/labs/oocsb/papers/hotchips.html
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
> What you are probably trying to say is that Lisp can either be
> interpreted and fully dynamic _or_ compiled and restricted wrt to dynamics.
I don't know whether you look in related maillist, but
it is exectly the focus of my attention today!
:)
P.S. I am sorry that I am not able to response to other posts from
this thread right now.
········@mail.ru (Valery) wrote in message news:<····························@posting.google.com>...
> Hi All,
>
> it is a lot of years already as Lisp (with other
> interpreter-based languages) implementations are blaimed
> for performance. Those Lisp implementations, which are not
> blaimed for performance have shortcomings with dynamic
> definitions.
>
> Are there any (opensource) project about creating JIT
> compilers suited for dynamic languages?
What?
A running Lisp *application* can bang together some lists that
represent Lisp source code, and can pass them to the compiler to get
back a compiled, optmized, ready-to-execute function.
How much more Just In Time do you want?
········@mail.ru (Valery) writes:
> it is a lot of years already as Lisp (with other
> interpreter-based languages) implementations are blaimed
> for performance. Those Lisp implementations, which are not
> blaimed for performance have shortcomings with dynamic
> definitions.
most Lisp implementations dynamically compile Lisp programs to native
machine code. so it's quite fair that they are "blamed for
performance", because the resulting native machine code usually
performs quite well. (unless the Lisp program being compiled is badly
written -- but that routinely happens to programs in any language).
"JIT" is a new fancy name for a very old concept. they could have
called it "wheel", for all I know. the wheel in question (dynamic
native compilation) was, in fact, invented by Lisp (or maybe first by
Smalltalk? please correct me if I'm wrong) loooong ago.
--
All ITS machines now have hardware for a new machine instruction --
BAH
Branch And Hang.
Please update your programs.
After takin a swig o' Arrakan spice grog, Michael Livshin <······@cmm.kakpryg.net> belched out...:
> ········@mail.ru (Valery) writes:
>
>> it is a lot of years already as Lisp (with other
>> interpreter-based languages) implementations are blaimed
>> for performance. Those Lisp implementations, which are not
>> blaimed for performance have shortcomings with dynamic
>> definitions.
>
> most Lisp implementations dynamically compile Lisp programs to native
> machine code. so it's quite fair that they are "blamed for
> performance", because the resulting native machine code usually
> performs quite well. (unless the Lisp program being compiled is badly
> written -- but that routinely happens to programs in any language).
>
> "JIT" is a new fancy name for a very old concept. they could have
> called it "wheel", for all I know. the wheel in question (dynamic
> native compilation) was, in fact, invented by Lisp (or maybe first by
> Smalltalk? please correct me if I'm wrong) loooong ago.
I _think_ the Lisp implementation of this predates the equivalent in
Smalltalk.
I remember a talk by a Waterloo researcher who spent some time at
Xerox PARC implementing exactly this in about the 1986-1988 timeframe.
I _think_ there were Lisp implementations already doing dynamic
compilation by that time.
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ ·@" ^ tld;;
http://www.ntlug.org/~cbbrowne/unix.html
Rules of the Evil Overlord #191. "I will not appoint a relative to my
staff of advisors. Not only is nepotism the cause of most breakdowns
in policy, but it also causes trouble with the EEOC."
<http://www.eviloverlord.com/>
In article <··············@laredo.verisity.com.cmm>,
Michael Livshin <······@cmm.kakpryg.net> wrote:
>most Lisp implementations dynamically compile Lisp programs to native
>machine code.
Do they? I think most of them require you to call COMPILE or COMPILE-FILE
to produce machine code, otherwise they use an interpreter. There are some
that will automatically compile, like CMUCL, but I don't think most are
like this.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Barry Margolin <··············@level3.com> writes:
> In article <··············@laredo.verisity.com.cmm>,
> Michael Livshin <······@cmm.kakpryg.net> wrote:
>>most Lisp implementations dynamically compile Lisp programs to native
>>machine code.
>
> Do they? I think most of them require you to call COMPILE or COMPILE-FILE
> to produce machine code, otherwise they use an interpreter. There are some
> that will automatically compile, like CMUCL, but I don't think most are
> like this.
I suppose I meant "dynamic" as in "during the run-time" and not as in
"automatic".
even if you need to explicitly call #'compile, the big win is that
you (or your program) can do that whenever it is needed. which, I
think, is pretty dynamic. :)
--
Business thrives on inefficiency. Inefficiency makes jobs. Don't try
to defend technical superiority by showing how many jobs it can make
because that's practically an proof that you're wrong.
-- Kent Pitman, in comp.lang.lisp
Michael Livshin <······@cmm.kakpryg.net> writes:
> Barry Margolin <··············@level3.com> writes:
>
> > In article <··············@laredo.verisity.com.cmm>,
> > Michael Livshin <······@cmm.kakpryg.net> wrote:
> >>most Lisp implementations dynamically compile Lisp programs to native
> >>machine code.
> >
> > Do they? I think most of them require you to call COMPILE or COMPILE-FILE
> > to produce machine code, otherwise they use an interpreter. There are some
> > that will automatically compile, like CMUCL, but I don't think most are
> > like this.
>
> I suppose I meant "dynamic" as in "during the run-time" and not as in
> "automatic".
>
> even if you need to explicitly call #'compile, the big win is that
> you (or your program) can do that whenever it is needed. which, I
> think, is pretty dynamic. :)
It also depends on what you call compilation.
Lisp has traditionally blurred this.
For example, lots of Lisps (some CL implementations and some others)
macroexpand macros incrementally, so they get just-in-time semantic
analysis. (If you consult CL's definition of "minimal compilation",
you'll find this actually counts as compilation.)
But, additionally, MACLISP had a facility (called "uuolinks")
which allowed very complicated bookkeeping in compiled code so that
function lookup (which was definitionally very slow in Maclisp--definitions
had to be searched for on the property list and there were almost a
dozen possible indicators that could count as functions) would
be optimized by creating hardware indirection links that bypassed the
long lookup once a lookup had been done and a result was known.
I believe Teco (and hence Emacs) did JIT compilation of search strings.
It was common for people to write
0sfoo$ <:s$; !..body..!>
to precompile a search [0 searches for foo] and then repeatedly search
for the default item. I assume Stallman brought across a similar
capability into Lisp-based Emacs.
In any case, the hard bit of JIT compilation seems to me to be the
integration of interpreted and compiled elements in the same environment.
Whether JIT or not, the real thing Lisp has had forever is the ability to
gracefully mix interpreted and compiled functions. We've had two decades
of time during which anyone who wanted to implement JIT themselves for
critical code could have done it without even any special compiler magic.
In article <···············@shell01.TheWorld.com>,
Kent M Pitman <······@world.std.com> wrote:
>Michael Livshin <······@cmm.kakpryg.net> writes:
>
>> Barry Margolin <··············@level3.com> writes:
>>
>> > In article <··············@laredo.verisity.com.cmm>,
>> > Michael Livshin <······@cmm.kakpryg.net> wrote:
>> >>most Lisp implementations dynamically compile Lisp programs to native
>> >>machine code.
>> >
>> > Do they? I think most of them require you to call COMPILE or COMPILE-FILE
>> > to produce machine code, otherwise they use an interpreter. There are some
>> > that will automatically compile, like CMUCL, but I don't think most are
>> > like this.
>>
>> I suppose I meant "dynamic" as in "during the run-time" and not as in
>> "automatic".
>>
>> even if you need to explicitly call #'compile, the big win is that
>> you (or your program) can do that whenever it is needed. which, I
>> think, is pretty dynamic. :)
>
>It also depends on what you call compilation.
>
>Lisp has traditionally blurred this.
>
>For example, lots of Lisps (some CL implementations and some others)
>macroexpand macros incrementally, so they get just-in-time semantic
>analysis. (If you consult CL's definition of "minimal compilation",
>you'll find this actually counts as compilation.)
Well, I was responding to someone who said "to native machine code".
Minimal compilation doesn't count unless you have a CPU that implements
Lisp in hardware (even Lisp Machines don't).
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
From: Peter Seibel
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <m31xx779ry.fsf@javamonkey.com>
Kent M Pitman <······@world.std.com> writes:
> In any case, the hard bit of JIT compilation seems to me to be the
> integration of interpreted and compiled elements in the same
> environment. Whether JIT or not, the real thing Lisp has had forever
> is the ability to gracefully mix interpreted and compiled functions.
> We've had two decades of time during which anyone who wanted to
> implement JIT themselves for critical code could have done it
> without even any special compiler magic.
One of the techniques that the Java JIT writers are all hot about
these days are various kinds of "adaptive" optimization where
information is gathered at runtime and code that is found to be in the
hot spots is recompiled at higher optimization.
Another technique that the Java guys are experimenting with that seems
like it might be even a bigger win with a more dynamic language such
as Lisp is to make "optimistic" optimizations while keeping enough
information about the optimistic assumptions to be able to back out
the optimization and recompile when it becomes necessary.
For instance, in Lisp, you could imagine that there are a lot of
generic functions that only have a single method defined on them. If a
call to such a GF occurs in some inner loop it might be worth
compiling it to code that checks the types of the arguments and then
directly calls (or even inlines) the effective method (i.e. the one
method defined on the GF). At the call site, the code would also have
to check that the assumption that no more methods have been defined on
the GF hasn't been violated. If it had then that call site would have
to be recompiled. But since most of the time the assumption wouldn't
have been violated the call to the GF would be extremely efficient
without the programmer having to give up any potential dynamism.
Does anyone know of any Lisp implementations that do (or did) either
of these kinds of dynamic optimization?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Does anyone know of any Lisp implementations that do (or did) either
> of these kinds of dynamic optimization?
I don't know about Lisp, but it was the basis of the language Self. It was
more complicated there because the object system was prototypical rather
than class-based. The main problem that they had was that their heuristics
for deciding what to optimize were primitive (this was ~10 years ago, you
know) so their image size tended to balloon. Still, it performed better
than many of the JIT'ted implementations of its day.
faa
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> In any case, the hard bit of JIT compilation seems to me to be the
> integration of interpreted and compiled elements in the same environment.
exactly.
> Whether JIT or not, the real thing Lisp has had forever is the ability to
> gracefully mix interpreted and compiled functions.
I hope, we are not speaking about compilation to byte-code?
> We've had two decades
> of time during which anyone who wanted to implement JIT themselves for
> critical code could have done it without even any special compiler magic.
Decades of spreading efforts? -- That's the way of my thinking... but
I fail to find open source general purpose JIT-compiler taking some
byte-code on input. Just few entries for JIT-compiler dedicated for
Java.
opss, let me use term "JIT-compiler", because it is fancy and
clear enough :)
Well, you could say, open source subset of Lisp's family is not
representative enough and I could understand your point... But Java
has it somehow. BTW, I am far from being fan of anything, especially
Java :)
best regards,
Valery
On Fri, Jul 04, 2003 at 01:40:35PM -0700, Valery wrote:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
>
> > In any case, the hard bit of JIT compilation seems to me to be the
> > integration of interpreted and compiled elements in the same environment.
>
> exactly.
>
> > Whether JIT or not, the real thing Lisp has had forever is the ability to
> > gracefully mix interpreted and compiled functions.
>
> I hope, we are not speaking about compilation to byte-code?
Nope. Lisp environments have been mixing interpreted code, byte-code,
and native machine code for decades, while still retaining
interactivity.
> > We've had two decades
> > of time during which anyone who wanted to implement JIT themselves for
> > critical code could have done it without even any special compiler magic.
> Decades of spreading efforts? -- That's the way of my thinking... but
> I fail to find open source general purpose JIT-compiler taking some
> byte-code on input. Just few entries for JIT-compiler dedicated for
(defmacro defun-jit (name args &body body)
`(defun ,name ,args
(write-line "Compiling...")
(compile ',name
(lambda ,args
. ,body))
(,name . ,args)))
* (defun-jit foo (x) (1+ x))
FOO
* (foo 1)
Compiling...
2
* (foo 1)
2
Happy? =)
On a side note, do you know of the Parrot project? I believe they are
attempting to construct "JIT" compilers for a byte-code generated by future
Perl and other language implementations.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> wrote in message news:<······················@lain.mapcar.org>...
> Nope. Lisp environments have been mixing interpreted code, byte-code,
> and native machine code for decades, while still retaining
> interactivity.
CLTL2 has nothing to say about native code concerning (compile ...)
Therefore I do not understand what do you mean publishing your
example of your simplified JIT compiler in this post:
http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&selm=20030705211040.GN17568%40lain.mapcar.org
without any reference to a concrete CL implementation.
> On a side note, do you know of the Parrot project? I believe they are
> attempting to construct "JIT" compilers for a byte-code generated by future
> Perl and other language implementations.
wow, nice. They say the door is open for other languages.
And Lisp fathers are not really rushing to knock at
Parrot's door? Or?
/Valery
Valery wrote:
> Matthew Danish <·······@andrew.cmu.edu> wrote in message news:<······················@lain.mapcar.org>...
>
>>Nope. Lisp environments have been mixing interpreted code, byte-code,
>>and native machine code for decades, while still retaining
>>interactivity.
>
> CLTL2 has nothing to say about native code concerning (compile ...)
> Therefore I do not understand what do you mean publishing your
> example of your simplified JIT compiler in this post:
> http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&selm=20030705211040.GN17568%40lain.mapcar.org
>
> without any reference to a concrete CL implementation.
CLtL2 is not the definitive reference for Common Lisp - it was an
intermediate document, published in 1989. The final Common Lisp
specification was published in 1995.
See the HyperSpec for a document that has been prepared from the final
specs. You can find information about compile here:
http://www.lispworks.com/reference/HyperSpec/Body/f_cmp.htm
>>On a side note, do you know of the Parrot project? I believe they are
>>attempting to construct "JIT" compilers for a byte-code generated by future
>>Perl and other language implementations.
>
> wow, nice. They say the door is open for other languages.
> And Lisp fathers are not really rushing to knock at
> Parrot's door? Or?
There will probably be Lisp/Scheme ports for Parrot sooner or later, as
was the case for JVM and for .NET in the past. However, many people will
stick to their favorite Common Lisp / Scheme implementations that are
hard to beat. They have had sufficient time to mature over years, in
some cases decades, and newer implementations will need considerable
time to catch up.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
Pascal Costanza <········@web.de> wrote in message news:<············@f1node01.rhrz.uni-bonn.de>...
> Valery wrote:
> > CLTL2 has nothing to say about native code concerning (compile ...)
> > Therefore I do not understand what do you mean publishing your
> > example of your simplified JIT compiler in this post:
> > http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&selm=20030705211040.GN17568%40lain.mapcar.org
> >
> > without any reference to a concrete CL implementation.
>
> CLtL2 is not the definitive reference for Common Lisp - it was an
> [...]
> See [...] http://www.lispworks.com/reference/HyperSpec/Body/f_cmp.htm
there is nothing about native code as well. And it's OK.
(indeed, who could expect statements concerning "native code" in
lang speck?)
> There will probably be Lisp/Scheme ports for Parrot sooner or later, as
> was the case for JVM and for .NET in the past.
I hope. So much Lisp implementations could obtain a nice
possibility to share optimization/codegeneration/VM layer.
People who invest their in code optimization/generation
in different Lisp implementations could join their effort
for creating something better.
> However, many people will
> stick to their favorite Common Lisp / Scheme implementations that are
> hard to beat. They have had sufficient time to mature over years, in
> some cases decades, and newer implementations will need considerable
> time to catch up.
Are you speaking about developers who create Lisp
implementations or about those who just use Lisp?
Only developers who create Lisp do matter concerning
original question. Other could stuck even to their
lovely Intel 386 -- nothing bad in that.
On Tue, Jul 08, 2003 at 03:56:48AM -0700, Valery wrote:
> Matthew Danish <·······@andrew.cmu.edu> wrote in message
> news:<······················@lain.mapcar.org>...
>
> > Nope. Lisp environments have been mixing interpreted code,
> > byte-code, and native machine code for decades, while still
> > retaining interactivity.
>
> CLTL2 has nothing to say about native code concerning (compile ...)
> Therefore I do not understand what do you mean publishing your example
> of your simplified JIT compiler in this post:
> http://groups.google.de/groups?dq=&hl=de&lr=&ie=UTF-8&selm=20030705211040.GN17568%40lain.mapcar.org
>
> without any reference to a concrete CL implementation.
Very well. In Allegro, LispWorks, SBCL, Corman, MCL, OpenMCL, Scieneer
CL[*] and CMUCL[*] the COMPILE function will dynamically generate native
machine code which can be called immediately. Verify this with
DISASSEMBLE.
ECL and GCL may also do this, but I'm not sure.
> > On a side note, do you know of the Parrot project? I believe they are
> > attempting to construct "JIT" compilers for a byte-code generated by future
> > Perl and other language implementations.
> wow, nice. They say the door is open for other languages.
> And Lisp fathers are not really rushing to knock at
> Parrot's door? Or?
It's been thought about. I don't think Parrot is nearly mature enough
yet though. And I'm not really expecting much out of Parrot, because
it's designed by Perl people. I know that sounds bigoted, but Perl is
... well, shit =). So, I'm not holding my breath for it. If it turns
out to be decent, then I imagine you'll see a Lisp for it eventually.
But Lispers can already dynamically compile functions to native machine
code, so there's no big hurry. And many Lisp implementors (what are
``Lisp fathers?'') are busy enough as it is.
[*] (when the optimization quality for speed is greater than space)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> wrote in message news:<······················@lain.mapcar.org>...
> Very well. In Allegro, LispWorks, SBCL, Corman, MCL, OpenMCL, Scieneer
> CL[*] and CMUCL[*] the COMPILE function will dynamically generate native
> machine code which can be called immediately. Verify this with
> DISASSEMBLE.
>
> ECL and GCL may also do this, but I'm not sure.
thank you for this info. Any of those above is free available
for win32? (Sorry, majority of time I still spend under win32)
If I am not mistaken, Allegro is nice, but very expensive.
LispWorks has some restrictions in freely available version.
> It's been thought about. I don't think Parrot is nearly mature enough
> yet though. And I'm not really expecting much out of Parrot, because
> it's designed by Perl people.
Look, at least they were clever enough to consider success shown
by JVM. I hope "Lisp's fathers" (i.e. those who create Lisp
impl.) will consider this as well. Especially those who work
for open source--there it is as twice as important to share.
> I know that sounds bigoted, but Perl is
> ... well, shit =). So, I'm not holding my breath for it. If it turns
> out to be decent, then I imagine you'll see a Lisp for it eventually.
I've noticed that target group list for your email was
just comp.lang.lisp, not like I've made it originally :)
> But Lispers can already dynamically compile functions to native machine
> code, so there's no big hurry.
That's right in a way.
/Valery
Valery (········@mail.ru) wrote:
: Matthew Danish <·······@andrew.cmu.edu> wrote in message news:<······················@lain.mapcar.org>...
: thank you for this info. Any of those above is free available
: for win32? (Sorry, majority of time I still spend under win32)
CMUCL is Unix/Linux only.
I you want dynamically compiled native code Lisp you may look
at Poplog:
lynx http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
It has four languages in a single system (pop11, lisp, ml, prolog)
and runs on many systems, including MS Windows.
However, the compiler is not doing much optimisation, so the code
is only slightly faster then CLISP (CLISP has fast bytecode interpreter)
and on some programs CLISP may be faster (time critical functions
in CLISP library are coded in C).
By the way, if you really care about speed there is no substitute
to measering how fast a implementation perform on _your_ code.
And (to have balanced view), after measurment you may find that
you do not care about speed (if the speed is good enough, it is
good enough).
--
Waldek Hebisch
·······@math.uni.wroc.pl or ·······@hera.math.uni.wroc.pl
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> We've had two decades
> of time during which anyone who wanted to implement JIT themselves for
> critical code could have done it without even any special compiler magic.
could you expand your thought here?
Do you mean that the good JIT-compiler layer is not needed
for Lisp family languages?
In article <··············@laredo.verisity.com.cmm>,
Michael Livshin <······@cmm.kakpryg.net> wrote:
>Barry Margolin <··············@level3.com> writes:
>
>> In article <··············@laredo.verisity.com.cmm>,
>> Michael Livshin <······@cmm.kakpryg.net> wrote:
>>>most Lisp implementations dynamically compile Lisp programs to native
>>>machine code.
>>
>> Do they? I think most of them require you to call COMPILE or COMPILE-FILE
>> to produce machine code, otherwise they use an interpreter. There are some
>> that will automatically compile, like CMUCL, but I don't think most are
>> like this.
>
>I suppose I meant "dynamic" as in "during the run-time" and not as in
>"automatic".
"JIT" stands for "Just In Time", and doesn't that usually imply automatic,
on-the-fly compilation as the code is used? The only place where this is
likely to happen automatically in Common Lisp is when CLOS is creating
combined methods.
Although Common Lisp supports run-time compilation, it's not usually
needed. Many implementations include tree-shakers, and it's not uncommon
for COMPILE and COMPILE-FILE (and even sometimes EVAL) to be removed from
application runtime images.
--
Barry Margolin, ··············@level3.com
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <················@paloalto-snr1.gtei.net>,
Barry Margolin <··············@level3.com> wrote:
> "JIT" stands for "Just In Time", and doesn't that usually imply automatic,
> on-the-fly compilation as the code is used?
In the Java world, JIT is a surprisingly well-defined term, and means
compilation at load-time. The distinguishing feature of HotSpot or the
IBM Virtual Machine is that the latter compile at run time. (Urs
Hoelzle, one of the guys behind HotSpot, coined the cathphrase
"Just-In-Time is too early" ;)
AFAIK, the acronym "JIT" was first used for Java...
Pascal
Michael Livshin <······@cmm.kakpryg.net> wrote in message news:<··············@laredo.verisity.com.cmm>...
> ········@mail.ru (Valery) writes:
>
> most Lisp implementations dynamically compile Lisp programs to native
> machine code.
Could you give a hint about one or two mature implementations
able to dynamically compile?
(concerning Scheme, it would be also very interesting)
P.S. I got problem with Mozilla, sorry if this post is
doubled.
Thank you.
Valery.
Valery wrote:
> Michael Livshin <······@cmm.kakpryg.net> wrote in message news:<··············@laredo.verisity.com.cmm>...
>
>>········@mail.ru (Valery) writes:
>>
>>most Lisp implementations dynamically compile Lisp programs to native
>>machine code.
>
> Could you give a hint about one or two mature implementations
> able to dynamically compile?
See http://alu.cliki.net/Implementation for a list of Common Lisp
implementations, with links to more information. See
http://www.scheme.org and http://www.schemers.org for information about
Scheme.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
From: Nikodemus Siivola
Subject: Re: JIT for Lisp and dynamic languages in general.
Date:
Message-ID: <be3um2$ics$1@nyytiset.pp.htv.fi>
Valery <········@mail.ru> wrote:
> Are there any (opensource) project about creating JIT
> compilers suited for dynamic languages?
As you may have noticed you touched a nerve there with the remark about
lisp being interpreted... ;)
Since that issue has by now been amply and expertly addressed by others
I'll tackle a different point. I assume that you are not really
interested in what Lisp is or isn't, but are just looking for
information on the compilation of dynamic languages to machine code (JIT
or otherwise).
I would point you in the direction of free Common Lisp implementations.
For example:
CMUCL (several processor architectures, POSIX)
http://www.cons.org/cmucl/
SBCL (several processor architectures, POSIX)
http://sbcl.sourceforge.net/
OpenMCL (PPC, Mac)
http://openmcl.clozure.com/
(SBCL is actually a fork of CMUCL, so they share the same compiler:
Python -- that has nothing to do with the language of the same name.)
Cheers,
-- Nikodemus