[erlang-questions] list comprehensions speed

Richard A. O'Keefe ok@REDACTED
Tue Feb 25 23:24:26 CET 2014

On 26/02/2014, at 6:44 AM, Joe Armstrong wrote:
>   Your job is to write beautiful and clear code.
>    It is the compiler writers job to turn clear and beautiful code in quickly executing code.
>    It is the language designers job to design languages that will make it difficult for
>    you to shoot yourself in the foot.

We all have experiences that stick in our minds.
Here's one of mine.  I wanted to have a tokeniser for
Prolog written in Prolog.  (At the time I was planning
to write my own Prolog system so that I could have it
on machines other than a DEC-10, PDP-11, or VAX.)  So
I wrote something fairly clear and straightforward
and tested it and it worked.  Then I spent a day
hacking on it, throwing in every trick I could think of
to make it faster.

And it ran SLOWER.

Just last week, I was looking at someone else's code in
a programming language other than Erlang, and there was
an obvious way to make it faster.  So I used that

And it ran SLOWER.

In that case, it turned out that the compiler by default
generated pretty bad code for arithmetic expressions and
if you told it to optimise arithmetic expressions, the
result was a 30% speedup.  I refrain from naming the
language or the compiler, because the compiler shouldn't
have been pessimising arithmetic expression evaluation in
the first place.

The real reason I want to improve that program is that I
have already shown the author a refactoring he doesn't like
which I think can give at least an O(N) speedup -- as well
as making the program shorter and clearer -- but I needed
good base benchmarks to be convincing.

>   If you write clear code and you think it should run quickly and it does not do not
>   optimise the code - tell the compiler writer to fix the compiler/run-time.
>   We will get 1000+ core machines  within a few years

Chips with 256 cores exist now.  Intel have a lab one.
Kalray will sell you a 256-core chip now:
Their "Coolidge" processor with 1024 cores is roadmapped
for 2015.  That's next year, people.

More information about the erlang-questions mailing list