Re: Very poor Lisp performance

Förster vom Silberwald <chain_lube@xxxxxxxxxxx> wrote:

> When I was younger (now I am 31) I also believed benchmarking is a
> must. However, in the meantime it is even this: if your ray-tracer in
> OCaml were 100000 times faster than the Bigloo-Scheme version I would
> not opt for OCaml quickly. Perfromance is important, no question, but
> in a code project it is a rather tiny part.

Depends on the code project, doesn't it? If you're doing primarily
heavy duty (but medium complexity) mathematical manipulations, then
speed is a big factor.

I agree that in most problem domains, constant time speed factors are
pretty much irrelevant for 95% of code, and we should be very skeptical
about judging "language speed" by simple benchmarks like this, because
an easier to program language, often leads to better algorithms, as well
as a lot less programming time (and less downside variation in program
speed -- cf: Erann's lisp-java-c experiment: the fastest C programs just
beat the fastest lisp programs, but many of the C programs were *much*
slower than the slowest lisp programs).

But those tradeoffs aren't the same for all problem domains. In those
rare problem domains where there's always lots time to optimize relative
to the runtime available, bare speed matters.

The problem is that it's still hard to tell the difference between a
faster language and better writers of optimized code, as the almabench
thread demonstrates. How much time do you spend on optimization before
you abandon the project and say "It's easier to make this fast in X".
And obviously some things will be easier to optimize in language Y than
others. All this makes any given benchmark or set of benchmarks suspect
as an absolute measure of speed, but it doesn't completely invalidate
their potential usefulness, as long as one understands what they mean
and what they do not mean.


Michael
.

Relevant Pages

  • Re: Statically AND Dynamically Typed Language ??
    ... I think it's only fair to give a language points for making development easier, ... They should be selecting a few benchmarks ... If you want single core measurements look at the single core ...
    (comp.lang.misc)
  • Re: New Computer Language Shootout?
    ... I'd say you end up comparing the ways that programmers and language ... If you want to compare solutions then its fine. ... Benchmarks are trivial and even boring to code but not trivial to ...
    (comp.lang.lisp)
  • Re: Java or C++?
    ... Fortran vs C on some array benchmarks is probably a good bet. ... compilers often do a lot of platform-specific cache-based optimisation that ... compiler will generate efficient code for you. ... That language isn't C/C++. ...
    (comp.programming)
  • Re: New Computer Language Shootout?
    ... the correct approach is to have a battery of simple benchmarks ... functional language with first-class lexical closures that can interpret ... | "equal" LEFTA ... let rec eval vars = function ...
    (comp.lang.lisp)