On Jan 25, 2008 2:19 PM, Christopher Smith <[EMAIL PROTECTED]> wrote: > Chuck Esterbrook wrote: > > You can > > use the slow languages (Python, Ruby, LISP, Smalltalk) to a certain > > degree until you start pushing parts out to C, using them only for > > glue, or simply waiting a long time to get your results. > > > So, I'll let the slings and arrows for this hit Python and Ruby, but I > take offense to them being applied to LISP and Smalltalk. Cincom > Smalltalk is pretty darn zippy, and as for LISP... you have to be > kidding me. When CMU CL was presented to the world more than a decade > (sheesh, is it *two* decades now?) ago, it at the time was highly > competitive with Fortran for performance. Other LISPs have moved forward > such that CMU CL is no longer considered to be a speed demon. > > Which just goes to prove: languages aren't slow/fast, implementations are.
I've heard repeatedly that the fastest FORTRAN implementations are always faster than the fastest C implementations due to the aliasing problems that David Brown mentioned. So there's an example of the language influencing the run-time performance. Is it hard to imagine that the design of a language impacts its run-time performance? Does that sound absurd? Also, are you really claiming that Smalltalk is going to benchmark as fast as C or Java? It doesn't: http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=vw Dynamic languages are inherently slow because they are dynamic. Also, great speedups in dynamic languages, as seen in Self, are often accomplished by gobbling up RAM for various caching techniques. In other words, there is "some fundamental stuff" in the "dynamic" and that "stuff" has to go somewhere: CPU cycles and/or RAM. -Chuck -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
