On 04/21/2011 01:07 PM, Matthias Felleisen wrote:
-B- When it comes to raw computational performance (ignore loading Racket, start from
REPL and run a single game -- 10 seconds), my implementation is faster than Python
(but barely) and one of the Java implementations. But one Java implementation is 10x
faster. My hunch is that our OO system is significantly slower than Java's because we
lack types to reduce dispatch overhead. Then again I might be wrong. -- Another
possibility is that my extremely heavy use of our wonderful (!) contracts may impose
a large overhead. I use mostly ->i and ->m.
I'd be curious what your timings are with the contract checking disabled.
As for lacking types, types are only useful for primitive
optimizations; partial evaluation and code profiling and "inlining"
sequential dispatches have the potential to outperform C++ vtables,
etc. C/C++ must rely on link-time optimization frameworks and Java is
hampered by doing everything at runtime... I think this is a big area
of opportunity for lisp systems to regain the performance lead.
As to the wider issue, "glue languages" will probably win in the long
run; there are huge masses of legacy code, but everybody wants to use
a newer language. If you could fairly seamlessly employ a C++ or Java
library in lisp... C is dominant largely because it has a simple
calling convention. Lisp systems do not... They tend to be
frameworks, not externally extensible tools.
- Daniel
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
