help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: 조성빈
Subject: Re: Is Elisp really that slow? (was: Why is Elisp slow?)
Date: Sun, 12 May 2019 18:46:20 +0900

2019. 5. 12. 오후 4:54, tomas@tuxteam.de 작성:

>> 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?

So, you would compare languages that are ‘safe and dynamic enough’ as Elisp.
E.g. Python, JS, CL, Ruby, etc.

> 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.

Speed comes at a price, but as we see Pypy, JS, CL, and other high languages 
that are fast, we can see that it is /so/ clear that we can pursue more speed 
without sacrificing the language’s expressiveness, dynamicness, etc.

> 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.

Well, look at Atom and VS Code which is using the V8 engine (through node) to 
execute JS to tweak the editor. 
Now compare that to Emacs.
And Atom gets criticized by it’s slow bootup time, etc...
It’s pretty sure Emacs can benefit from some speed...

>>                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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]