[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile-2.0 and debian
From: |
Paul |
Subject: |
Re: guile-2.0 and debian |
Date: |
Sat, 26 Nov 2016 00:43:45 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
On 11/25/2016 06:13 PM, Thomas Morley wrote:
- Investigate why lilypond is a lot slower when using guile-2.0
This is the current main problem, I'd say.
From what I've read, the guile 2.0 interpreter is simply slower than
the guile 1.8 interpreter (with the trade-off being that 2.0 has a
compiler). For example, a quote from:
https://wingolog.org/archives/2016/01/11/the-half-strap-self-hosting-and-guile
-----------------begin-quote
Back in 2009 when we switched to the eval-in-Scheme, we knew that it
would result in a slower interpreter. This is because instead of the
interpreter being compiled to native code, it was compiled to bytecode.
Also, Guile's Scheme compiler wasn't as good then, so we knew that we
were leaving optimizations on the floor. Still, the switch to an
evaluator in Scheme enabled integration of the compiler, and we thought
that the interpreter speed would improve with time. I just took a look
and with this silly loop:
(let lp ((n 0)) (if (< n #e1e7) (lp (1+ n))))
Guile 1.8's interpreter written in C manages to run this in 1.1 seconds.
Guile 2.0's interpreter written in Scheme and compiled to the old
virtual machine does it in 16.4 seconds. Guile 2.1.1's interpreter, with
the closure-chaining optimization, a couple of peephole optimizations in
the interpreter, and compiled using the better compiler and VM from
Guile 2.2, manages to finish in 2.4 seconds. So we are definitely
getting better, and by the time we compile eval.scm to native code I
have no doubt that we will be as good as the old C implementation. (Of
course, when compiled to Guile 2.2's VM, the loop finishes in 55
/milli/seconds, but comparing a compiler and an interpreter is no fair.)
------------------end-quote
So I assume (as a non-authority in this area) that the best way to
address the slowdown is to start using guile 2.0's compiler to compile
LilyPond's scheme code. And I suppose taking that step would make sense
after the known bugs are fixed and things work using the interpreter,
but are just slower.
-Paul
- Re: guile-2.0 and debian, (continued)
- Re: guile-2.0 and debian, Thomas Morley, 2016/11/25
- Re: guile-2.0 and debian, David Kastrup, 2016/11/25
- Re: guile-2.0 and debian, David Kastrup, 2016/11/25
- Re: guile-2.0 and debian, Antonio Ospite, 2016/11/25
- Re: guile-2.0 and debian, Knut Petersen, 2016/11/25
- Re: guile-2.0 and debian, Knut Petersen, 2016/11/25
- Re: guile-2.0 and debian, Thomas Morley, 2016/11/25
- Re: guile-2.0 and debian,
Paul <=
- Re: guile-2.0 and debian, David Kastrup, 2016/11/26
- Re: guile-2.0 and debian, David Kastrup, 2016/11/26
- Re: guile-2.0 and debian, Thomas Morley, 2016/11/26
- Re: guile-2.0 and debian, Thomas Morley, 2016/11/26
- Re: guile-2.0 and debian, Thomas Morley, 2016/11/28
- Re: guile-2.0 and debian, Antonio Ospite, 2016/11/29
- Re: guile-2.0 and debian, Federico Bruni, 2016/11/24
- RE: guile-2.0 and debian, Andrew Bernard, 2016/11/24
- Re: guile-2.0 and debian, Thomas Morley, 2016/11/23
- Re: guile-2.0 and debian, Thomas Morley, 2016/11/23