Re: What's so great about lisp?

Pascal Costanza wrote:
> Jon Harrop wrote:
>> If that were available then I'd want the final statically-checked code to
>> be compiled efficiently, i.e. without unnecessary run-time checks and
>> with optimised pattern matches and so on.
>
> That doesn't make sense.

I think it makes sense. Moreover, I think it is widely accepted and there is
a lot of evidence that it is true. For example, SBCL tries to remove
run-time checks where possible in order to improve performance.

> The majority of a program is executed very
> rarely, typically only few parts are executed most of the time. It's one
> of those 80:20 things: 80% of the time only 20% of the code is executed.
> (These are, of course, not the exact numbers, but that's the idea.)

Yes. Removing run-time checks speeds up all of the code, including the ~20%
where most of the time is spent. The advantage is significantly faster
programs.

> This means that the "efficiency" of the resulting code doesn't really
> pay off in the majority of the code - you wouldn't actually notice any
> difference. On the other hand, the removed run-time checks are areas
> where potential problems can occur.
> Think about security leaks or lack of information in case the program
> fails in unexpected ways.

No. In ML, the run-time checks are only removed when it is statically proven
to be safe to do so. SBCL can remove run-times checks without requiring
such proof, leading to unsafe programs, but only when instructed to do so.

> The only reasonable way to get efficient programs is to try to identify
> the "hot spots" and optimize them and only them. The best way to
> optimize them is to completely get rid of them. This boils down to
> finding better algorithms / execution stratetegies rather than
> fine-tuning what are essentially bad algorithms, etc.

While that is certainly true, it has nothing to do with the compiler
removing run-time checks for you.

When I want to optimise a C++ program, for example, I start by requesting
compiler optimisations on the command line (e.g. -O2) because it is easy to
do. Automated removal of run-time checks falls into the same category.

> Common Lisp implementations are allowed to ignore these declarations,
> but many do a pretty good job at interpreting them in useful ways. CMUCL
> and SBCL are especially interesting because they have a type inferencer
> that interacts with these settings (IIUC). (This doesn't mean that I
> generally recommend to focus just on those two implementations - their
> compiler is relatively slow because it apparently spends quite some time
> on optimizing code, and sometimes it is more important to a have fast
> compiler rather than have fast code.)

Does that mean that "eval" is slow to invoke with CMUCL and SBCL?

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
.