Re: [j-devel] patch for intepreter, for making fixnums and bignums equal by value

[Ville V. <vil...@gm...>]

On Tue, Mar 31, 2009 at 8:24 PM, Don Cohen
<don...@is...> wrote:
> First, I worry about the mention of interpreter in the subject.
> I hope these changes affect compiled code as well as interpreted.

They don't, yet. The only case where that patch would affect the compiler
is when the compiler decides not to inline eq.

> The idea that a bignum and a fixnum could be = therefore comes as a
> surprise to me.

They aren't. I was merely mentioning that even if someone would concoct
a small bignum, that wouldn't be considered eq to any fixnum.

> Your implementation of EQ therefore surprises me since it seems to
> have significant overhead (dispatching on argument types).

Well, I could check with an instanceof, but I doubt that's much/any faster.
EQ would be fast if we had the fixnum cache (see below), because then
we can rely on object identity, except for integer ranges that are outside
the cache.

> Perhaps this is an inevitable consequence of using java as the
> implementation language.

I'd say it's a consequence of having to box numeric values inside instances
of classes derived from LispObject. When I only have LispObjects at hand,
I'll have to dispatch. We can consider making LispObject have multiple
representations(1) that can be null or some such solution, we'll have to see.

> Similarly, I expect fixnum arithmetic (when the results as well as the
> inputs are fixnums) to be very fast, so I'm somewhat taken aback at
> the idea of an "interned fixnum cache" - that suggests that when you
> add 2 to 3 you have to look up 5 in the cache in order to figure out
> what to return.  The traditional lisp implementation is that fixnums

The cache is most likely going to be a linear array of 16k-32k integers
or in that ballpark. Any lookup will be O(1). There's no comparison needed
to get to the correct value. The values can also be readily boxed, I'm
not sure about that at this point.

(1) That would mean having some representations directly available as
members of LispObject. I have used such a pattern in some things I've
done, I'm not yet sure if it would be applicable here.