[racket-dev] my '312' this semester, how we compare to others

From: D Herring (dherring at tentpost.com)
Date: Sun May 1 02:58:42 EDT 2011

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



Posted on the dev mailing list.