Re: Is Elisp really that slow? (was: Why is Elisp slow?)

[<tomas@tuxteam.de>]

[-- Attachment #1: Type: text/plain, Size: 2719 bytes --]

On Sun, May 12, 2019 at 01:09:09AM +0200, Emanuel Berg wrote:
> tomas wrote:
> 
> > Show us the benchmarks.
> 
> How do people do benchmarks when it comes to
> comparing the speed of different
> computer languages?

My favourite search engine recommends [1], [2].

> Do you solve a wide/varied set of problems (the
> same set) with different languages and then
> compare the wall clock execution time?

More or less, yes. See references.

> Perhaps using an atomic clock in
> a sterile environment?

Clock accuracy/precision/resolution will be the least of your problems
in a cross-language benchmark. Different languages exist for a reason,
and carry with them a whole set of different cultures, so they'll tend
to express a problem in subtly different way (leading to subtly differing
semantics). How do you account for the fact that some problem expressed
in C won't do array bounds checking, while in Java it will do them
dynamically all the time (costing runtime), whereas in some smart
functional language the compiler will do most of that work most of
the time, due to advanced compiler magic? How do you account for the
fact that in language A the programmer will take 100 times longer to
master the language, but one-tenth of the time to write a program?
The fact that this compiler will produce runtimes twice as fast, but
ten times as fat, and take 50 times the compile time?

Yeah. Numbers for illustration only.

> Now, while that would be interesting to do,
> I think it's pretty clear Elisp would benefit
> from more speed.

My whole point is that this is /not/ so clear. Emphatically so.
Speed comes at a price (did you do your research about Spectre
and Meltdown?). Perhaps Elisp has found an optimum in this tradeoff,
for the job it's supposed to do.

Well, actually this optimum point shifts around with time, since
the environment Emacs lives in changes (people using it, the kind
of tasks it is put to, but also the hardware it lives on).

Actually I'm convinced Emacs is tracking this optimum pretty nicely,
since it is looking back to 34 years of life (and still receives a
steady stream of patches [3]!). Few pieces of software can say that
of them.

>                 Maybe it is not slow for its
> purposes,

...and that is exactly the point!

>           but it ain't fast either, sure is
> my impression.

I haven't the time currently to illustrate my point more, sorry. Do
your experiments, find out for yourself.

Cheers

[1] https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game
[2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/
[3] http://git.savannah.gnu.org/cgit/emacs.git

-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]