Re: RAD vs. performance
- From: Robbert Haarman <comp.lang.misc@xxxxxxxxxxxxx>
- Date: Mon, 19 Jun 2006 09:28:07 +0200
On Mon, Jun 19, 2006 at 01:10:50AM +0100, Jon Harrop wrote:
My impression is that a dynamically typed
interpreter is good for RAD, and a statically typed compiler generates
good performance.
Static typing also finds bugs. If you want your rapidly-developed
application to work then this is important.
This is very true, and most theoreticians I've asked about the issue
told me that this (and not optimization) is the most important benefit
of static typing.
Of course, there are counterarguments as well: static typing as a
measure of correctness is both an overapproximation and an
underapproximation. Just because the type checker accepts a program
doesn't mean it's correct, and type checkers will also make it
impossible to write programs that would have worked flawlessly in the
absence of static typing (of course, these programs aren't _correct_,
because they violate the typing rules). It's true that both of these
issues can be mitigated by having more sophisticated type systems.
Some pet examples (in ML syntax):
let rec fac n = match n with
1 -> 1
| n -> n * (fac n)
in
print_int (fac 12); print_newline ();;
Most type checkers will happily accept this program, yet it contains a
number of bugs.
(* Suppose that foo and bar are instances of two different classes,
but both support the print method. *)
let rec print_all xs = match xs with
[] -> ()
| x::xs -> x#print; print_newline (); print_all xs
in
print_all [foo; bar];;
Most type checkers will reject this program, because they won't allow
you to put objects of different types in a single list. However, under
dynamic typing, this program would have worked fine.
CL can be either interpreted or compiled, and is
dynamically typed but has static "advisory" typing for final optimization.
Yet CLs performance is far worse than that of most modern, statically-typed
languages (e.g. MLs). Putting more effort into optimisation is no
substitute for designing a language that will run fast.
What is "far worse"? According to the Shootout, the difference in speed
between the fastest open source Common Lisp implementation and the
fastest C compiler is about a factor 2 (or so it was last I checked). Is
that a lot? Java is statically typed, but most Java implementations
score a lot worse. On the other hand, a lot of effort and money has been
put into optimizing the C compilers and Java implementations at the top
of the ranking. Maybe optimization matters more than you think. Of
course, the Shootout allows everyone to see what they want to see.
Is there any other language that does something like that?
All languages do "something like that". The problem with your question is
really that there is a blurry line between dynamic and static typing. There
are only "conventional beliefs". For example, dynamic typing is a special
case of static typing where no type checking is done at compile time.
Consequently, there is a range of static typing going from almost-dynamic
to very static. Java and SML are both considered to be "statically typed"
and, yet, Java code does a lot more run-time checking.
Besides static vs. dynamic typing, there's also the issue of type
safety. Contrary to what you would think intuitively, these are
orthogonal issues: there are statically typed languages that are type
safe and statically typed languages that aren't type safe, and the same
goes for dynamically typed languages. For an example of static typing
without safety, consider the following C code:
int foo = 1234;
*((int*) foo) = 5678;
The type checker will eat it, yet it completely bypasses the type
system, and probably crashes.
Java has to perform run-time checks for two reasons: first of all, it
has to determine the real class of an object when a virtual method
(which virtually all methods are, in Java) is called, and secondly, it
has to verify that when an object is cast to some type, that type is
actually the objects real type or one of its supertypes (to maintain
type safety).
Is Lisp the only language with adjustabe typing and execution?
All languages have adjustable typing and execution. AFAIK, it is
prohibitively difficult to reap the rewards of static typing (particularly
performance) with an implementation within Lisp. Consequently, I suspect
such things are also an academic curiosity.
I don't see why getting could performance out of a Lisp program with
type declarations should be a problem.
If I write, in Ocaml:
let rec fac_rec n r =
if n <= 1 then r
else fac_rec (n - 1) (n * r);;
The compiler will infer that n and r are integers, and fac_rec returns
an integer.
If I write, in Common Lisp:
(declaim (ftype (function (fixnum fixnum) fixnum) fac-rec))
(defun fac-rec (n r)
(if (<= 1 n) r (fac-rec (- n 1) (* n r))))
The compiler will have the exact same type information. Why wouldn't it
be able to generate code that was just as fast?
Regards,
Bob
---
I'm warning you; I have a Macintosh and an attitude to match it.
Attachment:
pgpGHQJkLZjoJ.pgp
Description: PGP signature
- Follow-Ups:
- Re: RAD vs. performance
- From: Jon Harrop
- Re: RAD vs. performance
- References:
- RAD vs. performance
- From: Yet Another Dan
- Re: RAD vs. performance
- From: Jon Harrop
- RAD vs. performance
- Prev by Date: Object Systems (Was: 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
|
