[Ecls-list] ECL shootout

[Gabriel Dos Reis]

On Tue, Jun 23, 2009 at 9:42 AM, Juan Jose
Garcia-Ripoll<juanjose.garciaripoll at googlemail.com> wrote:
> On Tue, Jun 23, 2009 at 4:33 PM, Matthew Mondor<mm_lists at pulsar-zone.net> wrote:
>> You might want to make sure your CFLAGS environment variable uses
>> -march=i686 -O2 at least, possibly -O3 to allow inlining.  Although I
>> still noticed with objdump -dS on compiled files the high frequency of
>> function calls (perhaps some of them can be auto-inlined with -O3
>> though, but this is unlikely for calls to the ecl shared library, it
>> might be worth trying static binaries as well).
>
> Well, C flags are definitely going to help, but there are deeper
> issues. For instance, if you build a multithreaded ECL there's going
> to be a non-negligible overhead due to locating thread-local data. On
> all platforms I know of (even using __thread), this involves a large
> amount of function calls and it is unavoidable.
>
> Another thing is that those benchmarks have been reversed optimized
> for SBCL. Let me explain this. Long time ago, Lisp benchmarks included
> a lot of declarations. It was for instance assumed that AREF required
> declaring the type of the argument, surrounding it with THE, etc.
> There were many other things. Nowadays, due to SBCL's good type
> inference engine, everybody gives that for granted and declarations
> have disappeared.

My personal opinion is: the fact that the compiler can take care of many of the
declarations as posisble is a Good Thing.  Ideally, users should not
have to write more
than is necessary when the rest of the work can be reasonably automated.
Over the years, I've found SBCL's approach to types and declarations quite an
impressive improvements over what used to be the practice.  The
practical interpretation
of declarations is implementation-dependent, so I'm not unhappy that they are
disappearing (or more accurately, as central as they used to be).  Due
to Lisp nature,
there are declarations that will stay.

>
> Unfortunately the current architecture does not help in doing type
> propagations beyond the very same expression. Or reverse type
> inference: given the arguments of a function infer the type of a
> variable and backpropagate this. Since this is not possible, ECL does
> worse. But if you added THE and DECLARE statements, I bet it would
> compare much better.

In general, it would be a good thing for ECL to use backward data flow analysis
to generate codes.  That takes time and resources to build, I know.
A while ago, you mention that you were moving toward use of SSA as basic
representation for many transformations.  Do you still consider that?

-- Gaby