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

[조성빈]

I understand your points; but IMHO Elisp is not doing well in all kinds of 
aspects, Isn’t it?̊̈

나의 iPhone에서 보냄

2019. 5. 11. 오후 4:32, tomas@tuxteam.de 작성:

>> On Sat, May 11, 2019 at 02:38:58AM +0200, Emanuel Berg wrote:
>> If it is possible to have Elisp as fast as CL
>> or even as fast as C (!), the only problem is
>> no one has been motivated to do it! ???
>> 
>> Are there not young people and university
>> students who would love such a challenge?
> 
> One last attempt: this whole thread is based on the premise
> that there is one clear definition of slow. Yet, there isn't.
> 
> Back in the 1980s, the (micro-) computers were so slow, that
> access to main memory wasn't a problem at all. I know of one
> design where two Z80 ran off the same static RAM, taking turns
> to access it.
> 
> Somewhat later, RAM was so slow that we had to interpose several
> layers of cache between it and the CPU (that is still the situation
> nowadays, which brought upon us Meltdown and Spectre).
> 
> A tad later, CPUs stopped getting faster at sequential execution.
> Making pipelines deeper and things stopped being fun, and transistors
> are at the current limit of how fast they can do. But, we can make
> them cheaper and smaller (and perhaps somewhat less greedy on
> electrons), so packing more CPUs on the chip is becoming more
> fashionable [1].
> 
> If you want to be really fast these days, you have a gang of
> fairly dumb processors all doing the same instruction at a
> time (SIMD). It's weird to program that: if you take a branch,
> you have to decide for one side, and throw away those members
> of your gang which went the other way (well, you throw their
> results away, actually). Perhaps pick the second branch up
> in a second pass.
> 
> Of course, the definition of "fast software" changes radically
> when your bedrock moves that quickly. The second "generation"
> above made cache-efficient algorithms interesting (somehow
> a rebirth of the 70ies, where you had very limited RAM and
> somewhat bigger external memory). In the third generation,
> parallelizable algorithms became more interesting (did you
> know that bubble sort, the laughing stock of CS, parallelizes
> pretty well? If you have more processors than time, this one
> isn't that bad). The fourth generation... well. Interestingly,
> functional languages help in making fast programs for those
> strange beasts without getting crazy.
> 
> What I don't like about this thread is that "fast" is being
> treated as the only metrics (it isn't) and as if it were a
> metrics at all (it isn't either).
> 
> Cheers
> 
> [1] Sometimes you see that coming and bet too early on it.
>    Alas, Sun is no more:
>    https://en.wikipedia.org/wiki/Sun_Niagara 
> 
> -- tomás