Re: GNU Guile 3.0.8 released

[Maxime Devos]

Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
> We are delighted to announce GNU Guile release 3.0.8, the latest in the [...]
> The Guile 3.0.8 release mixes maintenance and optimizations [...]

Is there any reason the fix
 was not
applied?

In the future, could it be announced in advance that a new version will
be released? Then people could test the new proposed version and remind
maintainers of forgotten fixes before the version has been finalised.

Greetings,
Maxime.


signature.asc
Description: This is a digitally signed message part

Re: Pausable continuations

[Stefan Israelsson Tampe]

I managed to make jitted code work for an example, speeds up the code up
2x. So in 1s ther is 40M ops per s
overhead in the generator construct, that's essentially 4x slower the
fastest it can do in a very simple loop. And matches
pythons generators and are 15x faster than the example code I have above.

On Thu, Feb 10, 2022 at 4:19 PM Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:

> I did some benchmark, consider this code below. Let's turn off the jit.
> Then
> a 20M loop using normal delimited continuations yields,
>
> ;; 7.866898s real time, 14.809225s run time.  9.652291s spent in GC
>
> With a pausing continuation or generator we end up with,
> ;; 0.965947s real time, 0.965588s run time.  0.00s spent in GC.
>
> python 3's similar generator example is executing at 0.5s for the same
> looop.
> so using delimited continuations to model pythons generators we have an
> overhead of around 15X.
>
> With jit,
> ;; 6.678504s real time, 13.589789s run time.  9.560317s spent in GC.
>
> So we can't really get any speedup help from guile's jit here. The paused
> jit version is not available as I have not figured out how to do this jet.
>
> (define prompt (list 1))
> (define (f)
>   (let lp ((i 0))
> (when (< i 2000)
>   (begin
> (abort-to-prompt prompt)
> (lp (+ i 1))
>
> (define (test2)
>   (let lp ((k f))
> (call-with-prompt prompt k lp)))
>
>
>
> On Thu, Feb 10, 2022 at 2:07 PM Stefan Israelsson Tampe <
> stefan.ita...@gmail.com> wrote:
>
>> Consider a memory barrier idiom constructed from
>> 0, (mk-stack)
>> 1. (enter x)
>> 2. (pause x)
>> 3. (leave x)
>>
>> The idea is that we create a separate stack object and when entering it,
>> we will swap the current stack with the one in the argument saving the
>> current stack in x  and be in the 'child' state and move to a paused
>> position in case of a pause, when pausing stack x, we will return to where
>> after where entered saving the current position in stack and ip, and be in
>> state 'pause' and when we leave we will be in the state 'leave and move
>> to the old stack, using the current
>> ip. At first encounter the function stack frame is copied over hence
>> there will be a fork limited to the function only.
>>
>> This means that we essentially can define a generator as
>> (define (g x)
>>   (let lp ((n 0))
>> (if (< n 10)
>> (begin
>>(pause x)
>>(lp (+ n 1))
>>
>> And use it as
>> (define (test)
>> (let ((x (mk-stack)))
>> (let lp ()
>>(case (enter x)
>>((pause)
>>(pk 'pause)
>>(lp))
>> ((child)
>>  (g x)
>>  (leave x
>>
>> A paused or leaved stack cannot be paused, an entered stack cannot be
>> entered and one cannot leave a paused stack, but enter a leaved stack.
>>
>> Anyhow this idea is modeled like a fork command instead of functional and
>> have the benefit over delimited continuations that one does not need to
>> copy the whole stack and potentially speed up generator like constructs.
>> But not only this, writing efficient prolog code is possible as well. We
>> could simplify a lot of the generation of prolog code, speed it up and also
>> improve compiler speed of prolog code significantly.
>>
>> How would we approach the  prolog code. The simplest system is to use
>> return the
>> alternate pause stack when succeeding things becomes very simple,
>>
>> x   = stack to pause to in case of failure
>> cc = the continuation
>>
>> ( (x cc)  goal1 goal2)
>>  :: (cc (goal1 (goal2 x))
>>
>> (   (x cc)  goal1 goal2)
>> ::  (let ((xx (mkstack)))
>>  (case (enter xx)
>>  ((child)
>>   (cc (goal2 xx)))
>>
>> ((pause)
>>  (cc (goal2 x)
>>
>> Very elegant, and we also can use some heuristics to store already made
>> stacks when
>> leaving a stack and reuse at the next enter which is a common theme in
>> prolog,
>>
>> Anyhow we have an issue, consider the case where everythings
>> succeds forever. Then we will blow the stack . There is no concept of tail
>> calls here. So what you can do is the following for an ,
>>
>> (let ((xx (mk-stack)))
>> (case (enter xx)
>>   ((child)
>>(goal1 x (lambda (xxx) (pause xx xxx)))
>>
>>   ((pause xxx)
>>  (goal2 xxx cc
>>
>> This enable cuts so that a cutted and (and!) in kanren lingo will use
>> (goal2 x cc)
>>
>> And we have tail calls!
>>
>>
>> I have a non jitted version guile working as a proof of concept.
>>
>> The drawback with this is if a function uses a lot of stack, it will be a
>> memory hog.
>>
>> WDYT?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> .
>>
>>
>>
>

Re: Pausable continuations

[Stefan Israelsson Tampe]

Hmm, I can improve the delimited continuation speed slightly by doing the
below code


(define prompt (list 1))
(define (f2)
  (let lp ((i 0))
(when (< i 2000)
  (begin
(abort-to-prompt prompt)
(lp (+ i 1)
  #f)

 ; 5.906402s real time, 12.297234s run time.  8.894807s spent in GC.

So we are actually around 12X faster.

(define (test2)
  (let lp ((k f2))
(let ((k (call-with-prompt prompt k (lambda (k) k
  (if k (lp k) #f


On Fri, Feb 11, 2022 at 1:06 PM Stefan Israelsson Tampe <
stefan.ita...@gmail.com> wrote:

> I managed to make jitted code work for an example, speeds up the code up
> 2x. So in 1s ther is 40M ops per s
> overhead in the generator construct, that's essentially 4x slower the
> fastest it can do in a very simple loop. And matches
> pythons generators and are 15x faster than the example code I have above.
>
> On Thu, Feb 10, 2022 at 4:19 PM Stefan Israelsson Tampe <
> stefan.ita...@gmail.com> wrote:
>
>> I did some benchmark, consider this code below. Let's turn off the jit.
>> Then
>> a 20M loop using normal delimited continuations yields,
>>
>> ;; 7.866898s real time, 14.809225s run time.  9.652291s spent in GC
>>
>> With a pausing continuation or generator we end up with,
>> ;; 0.965947s real time, 0.965588s run time.  0.00s spent in GC.
>>
>> python 3's similar generator example is executing at 0.5s for the same
>> looop.
>> so using delimited continuations to model pythons generators we have an
>> overhead of around 15X.
>>
>> With jit,
>> ;; 6.678504s real time, 13.589789s run time.  9.560317s spent in GC.
>>
>> So we can't really get any speedup help from guile's jit here. The paused
>> jit version is not available as I have not figured out how to do this jet.
>>
>> (define prompt (list 1))
>> (define (f)
>>   (let lp ((i 0))
>> (when (< i 2000)
>>   (begin
>> (abort-to-prompt prompt)
>> (lp (+ i 1))
>>
>> (define (test2)
>>   (let lp ((k f))
>> (call-with-prompt prompt k lp)))
>>
>>
>>
>> On Thu, Feb 10, 2022 at 2:07 PM Stefan Israelsson Tampe <
>> stefan.ita...@gmail.com> wrote:
>>
>>> Consider a memory barrier idiom constructed from
>>> 0, (mk-stack)
>>> 1. (enter x)
>>> 2. (pause x)
>>> 3. (leave x)
>>>
>>> The idea is that we create a separate stack object and when entering it,
>>> we will swap the current stack with the one in the argument saving the
>>> current stack in x  and be in the 'child' state and move to a paused
>>> position in case of a pause, when pausing stack x, we will return to where
>>> after where entered saving the current position in stack and ip, and be in
>>> state 'pause' and when we leave we will be in the state 'leave and move
>>> to the old stack, using the current
>>> ip. At first encounter the function stack frame is copied over hence
>>> there will be a fork limited to the function only.
>>>
>>> This means that we essentially can define a generator as
>>> (define (g x)
>>>   (let lp ((n 0))
>>> (if (< n 10)
>>> (begin
>>>(pause x)
>>>(lp (+ n 1))
>>>
>>> And use it as
>>> (define (test)
>>> (let ((x (mk-stack)))
>>> (let lp ()
>>>(case (enter x)
>>>((pause)
>>>(pk 'pause)
>>>(lp))
>>> ((child)
>>>  (g x)
>>>  (leave x
>>>
>>> A paused or leaved stack cannot be paused, an entered stack cannot be
>>> entered and one cannot leave a paused stack, but enter a leaved stack.
>>>
>>> Anyhow this idea is modeled like a fork command instead of functional
>>> and have the benefit over delimited continuations that one does not need to
>>> copy the whole stack and potentially speed up generator like constructs.
>>> But not only this, writing efficient prolog code is possible as well. We
>>> could simplify a lot of the generation of prolog code, speed it up and also
>>> improve compiler speed of prolog code significantly.
>>>
>>> How would we approach the  prolog code. The simplest system is to use
>>> return the
>>> alternate pause stack when succeeding things becomes very simple,
>>>
>>> x   = stack to pause to in case of failure
>>> cc = the continuation
>>>
>>> ( (x cc)  goal1 goal2)
>>>  :: (cc (goal1 (goal2 x))
>>>
>>> (   (x cc)  goal1 goal2)
>>> ::  (let ((xx (mkstack)))
>>>  (case (enter xx)
>>>  ((child)
>>>   (cc (goal2 xx)))
>>>
>>> ((pause)
>>>  (cc (goal2 x)
>>>
>>> Very elegant, and we also can use some heuristics to store already made
>>> stacks when
>>> leaving a stack and reuse at the next enter which is a common theme in
>>> prolog,
>>>
>>> Anyhow we have an issue, consider the case where everythings
>>> succeds forever. Then we will blow the stack . There is no concept of tail
>>> calls here. So what you can do is the following for an ,
>>>
>>> (let ((xx (mk-stack)))
>>> (case (enter xx)
>>>   

Re: [PP?] GNU Guile 3.0.8 released

[Developers list for Guile, the GNU extensibility library]

On Fri, 11 Feb 2022, Andy Wingo  wrote:

> Note however that as with macros, when a definition changes in module
> A, a separately compiled module B that uses that definition doesn't
> automatically get recompiled.  This is a limitation in Guile that we
> would like to fix.

I find this to be critical.  It's a real pain to not have dependencies
tracking in a build system.  

How could this be fixed?  Does generating *.d files like GCC does for C
would work?

-- 
Olivier Dion
Polymtl

Re: GNU Guile 3.0.8 released

[Aleix Conchillo Flaqué]

On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos  wrote:

> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
> > We are delighted to announce GNU Guile release 3.0.8, the latest in the
> [...]
> > The Guile 3.0.8 release mixes maintenance and optimizations [...]
>
>
Am I the only one who has not received the announcement?

Aleix

Re: GNU Guile 3.0.8 released

[Ricardo Wurmus]

Aleix Conchillo Flaqué  writes:

> On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos  wrote:
>
>> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
>> > We are delighted to announce GNU Guile release 3.0.8, the latest in the
>> [...]
>> > The Guile 3.0.8 release mixes maintenance and optimizations [...]
>>
>>
> Am I the only one who has not received the announcement?

No.  I also haven’t received it.

-- 
Ricardo

Re: GNU Guile 3.0.8 released

[Chris Vine]

On Fri, 11 Feb 2022 19:03:17 +0100
Ricardo Wurmus  wrote:
> Aleix Conchillo Flaqué  writes:
> > On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos  wrote:
> >
> >> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
> >> > We are delighted to announce GNU Guile release 3.0.8, the latest in the
> >> [...]
> >> > The Guile 3.0.8 release mixes maintenance and optimizations [...]
> >>
> >>
> > Am I the only one who has not received the announcement?
> 
> No.  I also haven’t received it.

I didn't receive it either, on either guile-user or guile-devel.  It
looks as if something may be amiss with the mailing list servers.

Re: Pausable continuations

[Vijay Marupudi]

This is exciting work, thanks for sharing! Maybe non-continuable
exceptions could be based on pausing continuations.

~ Vijay

Re: GNU Guile 3.0.8 released

[Greg Troxel]

Aleix Conchillo Flaqué  writes:

> On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos  wrote:
>
>> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
>> > We are delighted to announce GNU Guile release 3.0.8, the latest in the
>> [...]
>> > The Guile 3.0.8 release mixes maintenance and optimizations [...]
>>
>>
> Am I the only one who has not received the announcement?

I got the announcement but it was filed to spam because of a rule
KAM_MAILSPLOIT (KAM ruleset for spamassassin), because there were two
From: headers.  I have reported this ruleset false positive.

Andy: Perhaps resend, with only one From: header.


signature.asc
Description: PGP signature

Re: GNU Guile 3.0.8 released

[Aleix Conchillo Flaqué]

On Fri, Feb 11, 2022 at 5:28 PM Greg Troxel  wrote:

>
> Aleix Conchillo Flaqué  writes:
>
> > On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos 
> wrote:
> >
> >> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
> >> > We are delighted to announce GNU Guile release 3.0.8, the latest in
> the
> >> [...]
> >> > The Guile 3.0.8 release mixes maintenance and optimizations [...]
> >>
> >>
> > Am I the only one who has not received the announcement?
>
> I got the announcement but it was filed to spam because of a rule
> KAM_MAILSPLOIT (KAM ruleset for spamassassin), because there were two
> From: headers.  I have reported this ruleset false positive.
>
>
It didn't even get into GMail spam... Oh well.

> Andy: Perhaps resend, with only one From: header.
>

I'll ping him.

Thanks!

Aleix