···@best.com writes:
#
# ······@lavielle.com (Rainer Joswig) writes:
#
# At the "Dynamic Objects Event" (Object World 96 in Boston) there
# was a talk by Olin Shivers. He talked about the problems of running
# Lisp-like languages on the Java VM. Seems like there is a serios
# performance penalty.
#
# Do you remember specifics (Olin, can you speak up)? I don't see why
# there should be a serious performance penalty, at least for the
# essential Lisp features: dynamic typing, structural type information,
# and closures with unlimited extent. They seem to me to map pretty
# nicely onto JavaVM constructs. The constraints the Java VM imposes
# are largely the same that any safe Lisp runtime has to conform to
# anyway.
You can read the paper at
http://www.ai.mit.edu/people/shivers/javaScheme.html
There are two parts to his argument. One is that the Java VM does
*not* support dynamic typing well---it was designed to support Java
which is statically typed. In particular, things like immediate
integers are not type tagged. Olin suggests an immediate type tagging
scheme for the Java VM.
My interpretation of the second part of the argument is that the Java
VM is too high a level to efficiently support certain dynamic language
features like closures and proper tail calls. His suggestion is to
have a two level virtual machine with a low level RISC level, and
provably safe macro layer. Implementors targeting the VM could
propose new macros that could eventually be accepted by the user
community.
I'm not holding my breath for any large changes to the Java VM by Sun
(although Guy Steele in his talk at MIT last summer said that Bill Joy
had asked him to figure out what was needed efficiently implement
Scheme on top of the Java VM).
--
Brent Benson
Concentra Corporation
From: Stefan Monnier
Subject: Re: Lisp-to-JavaVM compiler
Date:
Message-ID: <4nis8g$5q9@info.epfl.ch>
In article <·················@best.best.com>, . <···@best.com> wrote:
] crutch for too long. The world has settled on 32 bit and 64 bit
] integers and pointers, there is little or no architectural support for
] the tagging/untagging in most processors, and APIs require full,
] untagged data. That means that immediate tagging just keeps causing
] unpleasant problems with APIs and undesirable overhead.
I admit that immediate tagging is a pain when you need to interact with other
packages and it might be possible to reduce its usefulness by clever analyses.
But clever compilers are rare. And the analysis' effectiveness often depends
critically on the availability of the whole program (separate compilation is
not appreciated in such cases, nor is incremental changes). Finally dealing with
tags is not necessarily as expensive as you seem to think, even with processors
who don't have built-in tag-support.
Furthermore immediate tagging is also useful to reduce memory usage (and I
generally consider that reducing memory usage is more important than CPU usage)
when dynamic typing is used.
Stefan
In article <··········@info.epfl.ch>, "Stefan Monnier" <··············@lia.di.epfl.ch> writes:
>> In article <·················@best.best.com>, . <···@best.com> wrote:
>> ] crutch for too long. The world has settled on 32 bit and 64 bit
>> ] integers and pointers, there is little or no architectural support for
>> ] the tagging/untagging in most processors, and APIs require full,
>> ] untagged data. That means that immediate tagging just keeps causing
>> ] unpleasant problems with APIs and undesirable overhead.
>>
>> I admit that immediate tagging is a pain when you need to interact with other
>> packages and it might be possible to reduce its usefulness by clever analyses.
It really isn't possible to eliminate. General container structures MUST HAVE
tagged data. A hashtable, array, list, object slot must be able to contain
generalized objects. Boxing of integers is a huge loss.
Just look at the boxing of floats in CommonLisp.
It causes great pain and suffering, and after all these years it still
isn't an issue that has been "solved" by fancy compilers, type declarations, etc.
In fact, the only real solution is the new 64bit machines and using
immediate type-tagged 64bit floats.
>> not appreciated in such cases, nor is incremental changes). Finally dealing with
>> tags is not necessarily as expensive as you seem to think, even with processors
>> who don't have built-in tag-support.
It yeilds a great degree of benefit for very little cost.
-Kelly Murray ···@franz.com
From: Stefan Monnier
Subject: Re: Lisp-to-JavaVM compiler
Date:
Message-ID: <4nj87p$747@info.epfl.ch>
In article <··········@sparky.franz.com>, Kelly Murray <···@franz.com> wrote:
] In fact, the only real solution is the new 64bit machines and using
] immediate type-tagged 64bit floats.
We've been through that already. But remember that immediate tagged-floats
are not trivial or even useful. They have problems since every bit of a float is
useful and furthermore the tag-check is an integer operation, so you need to
load the float into an integer register as wellas a float register. In the end,
you're not much better off than with a tagged-pointer to a float.
Especially if you consider that many float vars don't need dynamic typing
and that datastructures holding floats are usually arrays, so you can just
special case arrays of floats by tagging the array rather than each individual
float.
In other words, the cases where you need boxed and tagged floats can be made
infrequent, and immediate tagged-floats are not even obviously better in those
"rare" cases.
It's probably not a good example of the usefulness of immediate tags.
Stefan