| Antonio Menezes Leitao 2004-06-25, 8:06 pm |
| Kenny Tilton <ktilton@nyc.rr.com> writes:
> Antonio Menezes Leitao wrote:
>
> Me, too, and kudos for the effort to produce those numbers. but still...
>
> It seems that Java compilers and virtual machines are
>
> ...CMIIAW, but is it not true that the Boyer benchmark involves only
> types which would be Java (what's the term) built-ins?
Well, as I said, I minimized the changes to Lisp code to the absolute
minimum, and this causes several annoying effects in the resulting
Java code. As you can see in the Java code I posted, there are two
important, non built-in, types, namely linj.Cons and linj.Symbol.
These are very simplistic implementations of the Lisp cons a symbol
datatypes and they haven't been optimized at all. They were made
initially just to demonstrate that you could use Lisp style in Java
and they are toy implementations. Moreover, there are also some extra
non built-in types such as linj.Function, linj.Predicate2 that are
used as base classes to some annonymous inner classes implementing the
Java equivalent of Common Lisp lambdas. Finally, albeit less
important, even arithmetic operations in the Java code are being done
using reference types, via the linj.Bignum class (a toy implementation
of Common Lisp rationals). This is evident when we look at the
translation from Common Lisp (eql x y) to Java:
(x == y) || ((x instanceof Number) && (y instanceof Number) && x.equals(y))
Even the Common Lisp form
(do (...
(n n (1- n)))
((zerop n) ...))
becomes:
for (Object n0 = n;
! (((Bignum)n0).compareTo(Bignum.valueOf(0)) == 0);
..., n0 = ((Bignum)n0).subtract(Bignum.valueOf(1))) {
}
So, I think that the code is not taking advantage of Java built-ins.
One built-in type that is heavilly used, however, is the
java.util.Hashtable where symbols are stored. This is the equivalent
to a Common Lisp package, so they are both built-in in the respective
languages. Anyway, they are not accounted on the final benchmarks
because, in Common Lisp, the overhead is removed at load-time. This
was what made me remove the setup operation (where most interns are
done) from the timings. However, just to increase the unfairness of
the Java benchmarks, there are still a few interns being done on the
test function, as well as list constructions that, I believe, CMUCL
can optimize away.
> Let's get some real OO into the game. Perhaps a silly exercise would
> be to take boyer and create class wrappers for Number and Float with
> methods like add and multiply.
That's what is being done but the performance bottleneck is not on
numerical operations.
> I guess the class hierarchies should have some depth to best
> exercise the dynamic dispatch. Unless of course there is a nice OO
> benchmark out there (but mebbe some global editing of what you have
> now is actually easier).
If someone wants to make the boyer benchmark more object-oriented,
I'll try to find some time to translate it again to Linj. Only single
dispatch and no fancy method combinations, please :-)
Thanks,
António Leitão.
|