Re: SBCL is now faster than Java, as fast as Ocaml, and getting better

Kaz Kylheku wrote:
On 2008-07-12, Jon Harrop <jon@xxxxxxxxxxxxxxxxx> wrote:
Note that the Lisp was written by Juho Snellman, one of the authors of
SBCL, and not by me.

Be that as it may, was he working with a requirement for speed, or
terseness?

Juho was trying to be concise. That code was quoted from the first version
of the ray tracer benchmark, which is the slowest and most concise.

Those types are implicit in the OCaml but they are both

Types are also frequently implicit in Lisp. '(1 2 3) is implicitly a list,
etc.

Still requires explicit deconstruction in Lisp but not in OCaml.

inferred and anonymous so they add no syntactic overhead at all.

But they do. Your pattern match for the list case requires three tokens:

lam' , []

this is longer than a single atom CONS in a TYPECASE. Though that CONS
constitutes an occurence of an explicit type, it's shorter.

I assume you are still neglecting the single most common and completely
superfluous component of the Lisp source code: the parentheses.

If the type here was simply CONS, then you wouldn't have to call the
accessor (GROUP-CHILDREN SCENE) to pull out the scene elements. So
that's one less abstract syntax tree node right away.

Your Lisp code would be littered with CAR and CDR instead.

I disagree. The GROUP object still contains a list made up of cons cells.

If that list were deconstructed within this source code that would be
relevant but it is not.

(values lam normal))
(sphere
(values lamt (unitise
(-v (+v orig (*v lamt dir))
center)))))))))
(aux infinity zero scene)))

62 tokens.

Only if you ignore the superfluous parentheses that make up most of the
Lisp code, which is absurd because they are essential in Lisp.

Parentheses are punctuation, not tokens.

So we cannot even agree on what a token is.

They are not part of the abstract syntax tree, though of course they
determine its shape.

So the parentheses are both visible and essential but you still want to
neglect them.

In reality, the Lisp has 125 tokens.

Abstract syntax tree size is the best measure of the raw size of an
expression in some language.

Absolutely not. The AST is compiler-dependent and invisible to the
programmer. So its size cannot be objectively quantified and would be
irrelevant anyway.

The Lisp is 2.3x longer by tokens if you count the (essential)
parentheses.

Fair enough.

It is true that the parentheses are an essential component of the program,
right? After all, (A (B (C)) is not the same thing as (((A) B) C).

Yes.

It takes bits to form the internal nodes which encode the shape of a tree,
independently of its size; if we count only the leaves, we ignore this
piece of information whose representation requires space.

The fallacy is in your assumption that programming languages with
associativity and precedence rules do /not/ also represent that
information in their programs. But of course they do!

Strawman argument.

If we count the Lisp as being 125 tokens, then likewise, to be perfectly
fair, we also have to count the corresponding information in the OCaml
program.

In Lisp, the information is plainly encoded in the program source, with
only the addition of some minimal, obvious, external rules required to
decode it.

Even though that information is not visible in the OCaml program, it is
still encoded in it, by means of a more complicated compression scheme,
which requires a considerably complex set of parsing rules.

Though the Lisp program's encoding of structure adds to its raw lexical
size, that encoding is easy to work with, and is an important property of
Lisp programs: not only is the information essential, as you note above,
but the explicit manner in which it is encoded is also essential. It is
not only helpful in metasyntactic programming, but it's a big help in
formatting and manipulating the program text itself.

By comparing the raw lexical size of two programs in these very different
languages, you are comparing something compressed to something
uncompressed. As an extreme example, would you compare, say, assembly
language which has been passed through GNU zip to uncompressed C source
code?

I would only compared human edited formats, i.e. OCaml source, Lisp source
but not gzipped assembler.

You may have noticed that almost all programmers disagree with you: huge

A couple of trolls in comp.lang.lisp don't constitute the entire
programmimg population.

Fortunately, the set of programmers who dislike superfluous parentheses
extends far beyond "a couple of trolls in comp.lang.lisp".

Be careful about making assertions about almost all programmers. By raw
headcount, most programmers prefer to work with Visual Basic.

Exactly.

numbers of superfluous parentheses being one of the most complained about
disadvantages of Lisp.

A pair of parentheses is superfluous only if you can remove them without
compensating for that removal by the addition of a language rule.

That is an incorrect definition of "superfluous".

If you have to do that, then you aren't removing anything, but merely
increasing the complexity of the encoding to achieve a higher compression.

In other words, you are improving brevity.

A new rule is a far greater burden than a pair of parentheses.

Almost all programmers and mathematicians disagree with you on that.

You
could argue that one rule eliminates countless pairs of parentheses, but
that is fallacious, because that rule has to be /instantiated/ in every
situation where those parentheses were removed.

We were all trained to comprehend that (and a lot more) from a very young
age.

In short, invisible is not necessarily better.

There is a trade-off.

# let polar x y = sqrt(x *. x +. y *. y), atan2 y x;;

This looks like incomrehensible drivel. More parentheses are needed to
show what goes with what.

No, more parentheses are not needed.

I disagree; a bit more punctuation would go a long way.

You have a comma there which binds more tightly than equals!

Note that in C:

a = b, b = c, c = a

parses as:

(a = b), (b = c), (c = a)

This is the way god intended it to be.

Note that you just contradicted yourself by claiming that my OCaml
was "incomrehensible drivel" and needed "more parentheses" in your previous
post before explaining in detail the only non-obvious aspect of precedence
required to completely parse it in this post. Indeed, you are now
saying "this is the way god intended it to be".

So you obviously can comprehend precedence.

This is why there are parentheses
around comma-separated lists, when those lists are to be treated as a
unit. For instance function calls:

f(a, b, c); // NOT: f a, b, c;

In a syntax where a comma expression is used to denote multiple values, it
should be parenthesized:

(x, y, z) = (1, 2, 3); // NOT: x, y, z = 1, 2, 3;

This is more psychologically sound.

You just contradicted yourself again by saying that unbracketed
comma-separated sequences are "what God intended" but you want to bracket
them.

What is the associativity and precedence of -> ?

Right associative and low precedence.

Right-to-left associative /binary/ operator? That's braindamaged.

Power is another right associative binary operator.

Even someone who doesn't know Common Lisp can at least work out the
abstract syntax tree.

You say that as if we were not all capable of deciphering the precedence
of addition and multiplication by the age of 5.

Well, the problem is that addition and multiplication is where the
similarity among most programming language syntaxes ends.

Power, comma, equality, comparisons, definitions, application, construction,
indexing etc. are all very similar between languages. The outlier is
undoubtedly s-exprs.

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

Relevant Pages

  • Re: Cons cell archaic!?
    ... Lisp can use other, alternative representations ... of lists, without cons. ... what exactly each of these jargons means is ... pretty much dependent on the language now. ...
    (comp.lang.lisp)
  • Re: LISPPA
    ... >> of arbitrary objects in a programming language. ... I'm puzzled by the statement that "Pure functional Lisp ... lists of arbitrary-typed elements has to be functional. ...
    (comp.lang.lisp)
  • Re: Lisp collections
    ... If a programming language specification talks about a data type, ... For example, The Common Lisp Hyperspec talks about lists, ... misapprehension that Lisp programmers generally just used lists to store ...
    (comp.lang.lisp)
  • Re: How powerful macros are?
    ... >> for software engineers to use arrays for everything, ... Did I miss something or is #an impossibly unbearable syntax in Lisp? ... and arrays are often slower for very short lists. ... I've also extended the language so that I have re-readable hash tables ...
    (comp.lang.lisp)
  • Re: Lisp for the C21
    ... Language design is not about necessity. ... and the need for variadic functions goes ... Every functional language I remember has lists as matter of course, ... OCaml can do almost the same thing as Lisp does with &rest and that is ...
    (comp.lang.functional)