Re: RAD vs. performance
- From: Jon Harrop <usenet@xxxxxxxxxxxxxx>
- Date: Tue, 20 Jun 2006 10:53:11 +0100
Robbert Haarman wrote:
On Mon, Jun 19, 2006 at 11:05:16PM +0100, Jon Harrop wrote:
There's no substitute for actual testing.
I disagree. Static checking is a substitute for some "actual" testing.
If you had said: formal verification, I would have agreed. But then,
only on the parts that are being formally verified. If that's only the
type-safety, I wouldn't see that as a substitute for functional testing.
Pretending that if a program gets through the type checker, it must be
correct is foolish; at least when the type checker doesn't verify
dependent types.
You're beating a straw man. I am not assuming that my code is correct
because it passes the static type checker. I am saying that code which
passes a static type checker tends to pass unit tests, whereas code written
in dynamically typed languages like Lisp tends to fail lots of unit tests
and require a lot more work before you have something that you can have
faith in.
For example, I wrote 5,000 LOC of OCaml last week and then spent a day
running it through unit tests. It passed all tests first time. It is now in
use and we have found (and fixed) only one bug, which was actually more of
a missing feature. That never happened to me when I was coding in
dynamically-typed languages.
http://www.ffconsultancy.com/free/ray_tracer/languages.html
Very nice! I'll read it in more detail later. For now, I have a number
of questions. Which parts of a language does this actually benchmark?
The benchmark is pretty evenly split between floating point arithmetic
(inside the ray_sphere function), data structure traversal (inside the
intersect function) and garbage collection. SBCL-compiled Lisp is severely
limited by the GC.
What about memory consumption?
Some of the side pages (e.g. C++ vs SML) mention the larger memory
consumption of other languages but I haven't quantified it on the main
benchmark.
How do I add my favorite language?
Provided it is a popular enough language that there's a Debian package
that'll install it, and it is fast enough to compete with the current crop
of languages, you can send me the code and I'll try to include it.
Lisp wasn't designed with classes and objects in mind, either, and yet
it supports them nowadays. Lisp got many things right by accident,
others by clever design, and yet others by fixing what was wrong
initially. In that light, the fact that it wasn't designed with
performance in mind doesn't seem a good reason for not having
performance. IMO, when it's about performance, it's always down to
features and implementation: if the features rule out certain
optimizations, performance is going to suffer. Likewise, if the
implementation is inefficient, performance is going to suffer. So, the
question is, is the poor performance of Common Lisp due to features or
implementation?
Neither, I'd say. As you say, Lisp has had many things (like OOP)
retrofitted to it. However, there is no substitute for careful design. You
can't expect a language with a multitude of ad-hoc supplemental features to
work as well as a language designed from the ground up to support them.
Dynamic typing for one thing.
I don't think so. If you write your program in such a way that types can
be determined statically,
That would require you to manually monomorphise your code, which is a
non-trivial step taken by whole program optimising compilers. I'm not about
to start executing compiler optimisations by hand.
it's possible to elide all run-time type
checks and method dispatches, completely eliminating any overhead from
dynamic typing.
Statically-determined type information (e.g. immutability) is used by
compiler optimisers, so you have not regained the lost ground.
If the compiler doesn't do that, it's an implementation issue.
No, it isn't. It is a design issue. It is silly to assume that you can take
an ancient language and bolt on an uber-optimiser to get the performance of
a modern language. There are sound theoretical reasons why that is silly
(they underpin the design of languages like ML) and there is an
overwhelming amount of practical evidence that it simply doesn't work. What
more do you want?
What if Lisp is also more verbose, error-prone and slower to develop in
than other languages? To be honest, I can't think of a single practical
use for Lisp.
That would be a lot more serious, seeing that Lisp's main claim to fame
is that it's supposed to be nice to developers. If it's verbose, error
prone, and slow to develop in, that claim obviously doesn't fly. It
could still be useful if it had lots of useful libraries, but I'm
doubtful that Lisp does better there than, say, Java or Perl; at least
in today's environment.
There is one main advantage of Lisp as I see it: EVAL. This could let you
write a compiler/interpreter that is simpler and gives better performance
than you could in a language without EVAL. That's a tiny niche though.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/ocaml_for_scientists/chapter1.html
.
- Follow-Ups:
- Re: RAD vs. performance
- From: Robbert Haarman
- Re: RAD vs. performance
- References:
- RAD vs. performance
- From: Yet Another Dan
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Robbert Haarman
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Robbert Haarman
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- From: Robbert Haarman
- RAD vs. performance
- Prev by Date: Re: RAD vs. performance
- Next by Date: Re: RAD vs. performance
- Previous by thread: Re: RAD vs. performance
- Next by thread: Re: RAD vs. performance
- Index(es):
Relevant Pages
|
