Chuck Esterbrook wrote: > 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. It's a nice thing to hear, and FORTRAN folks hold on to it like its golden, but in practice it isn't true. There are certainly some types of applications for which FORTRAN compiler writers really suit up for, but it is hardly true in general. Additionally, the Blitz++ guys actually finally figured out a way to beat FORTRAN at some of the things FORTRAN implementations tend to be best at. > So there's an example of the language influencing the run-time performance. > There is no question that there is an influence. Denying this is how you end up in the "Sufficiently Smart Compiler/VM" trap. It's just wrong to make short declarative statements like "X is fast" or "X is faster than Y". > 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 > Ugh. Synthetic language benchmarks are awful, but you'll note that while the overall picture shows VisualWorks taking a beating, it did run faster in two of the benchmarks. I'd also point out that it is running against Sun's JDK 6. Try running against JDK 1.0, 1.1 or even JDK 2, and you'll notice different outcomes. ;-) So yes, implementations do tend to trump language (indeed, Sun recognized this and during the initial hype hired/acquired a bunch of the top people working on high performance Smalltalk solutions... hard to know how fast Smalltalk would be if history had gone differently). > Dynamic languages are inherently slow because they are dynamic. Java is also dynamic, it's just statically typed. In practice its static typing provides more of a benefit in terms of security/stability/debugging etc., than in actual performance. > 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. > In practice, programs tend to be very dynamic as they get more complex, so much so that as per Greenspun's 10th law, you end up building elements of dynamic dispatch, at which point you start competing with dynamic languages, and losing because they've been able to invest far more effort in getting it right. Sure, you can win lots of synthetic benchmarks, but once you are tackling the hard problems out there, dynamic vs. non-dynamic languages becomes much less of a concern, at least from a performance standpoint. This is one of the few good reasons (aside from all the bad ones) why APL could achieve popularity for a lot of number crunching type problems, despite FORTRAN's existence.
--Chris --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
