Re: wip-ports-refactor

2016-05-12 Thread Andy Wingo
On Wed 11 May 2016 16:23, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo skribis: > >>| peek-char | read-char | peek-byte | read-byte >> -+---+---+---+-- >> 2.0 | 0.811s| 0.711s| 0.619s

Re: wip-ports-refactor

2016-05-11 Thread Andy Wingo
On Wed 11 May 2016 12:42, Chris Vine writes: > So you are saying that some parts of guile rely on the ordering > guarantees of the x86 memory model (or something like it) with respect > to atomic operations on some internal localised shared state? Let's say you cons a fresh pair and pass it to a

Re: wip-ports-refactor

2016-05-11 Thread Ludovic Courtès
Hello! Andy Wingo skribis: > This is in a UTF-8 locale. OK. So we have 10M "a" characters. I now > want to test these things: > > 1. peek-char, 1e7 times. > 2. read-char, 1e7 times. > 3. lookahead-u8, 1e7 times. (Call it peek-byte.) > 4. get-u8, 1e7 times. (Call it read-byte.) > >

Re: wip-ports-refactor

2016-05-11 Thread Christopher Allan Webber
Andy Wingo writes: > Greets, > > On Sun 17 Apr 2016 10:49, Andy Wingo writes: > >> | baseline | foo| port-line | peek-char >> --+--++---+-- >> guile 2.0 | 0.269s | 0.845s | 1.067s| 1.280s >> guile

Re: wip-ports-refactor

2016-05-11 Thread Chris Vine
On Tue, 10 May 2016 16:30:30 +0200 Andy Wingo wrote: > I think we have no plans for giving up pthreads. The problem is that > like you say, if there is no shared state, and your architecture has a > reasonable memory model (Intel's memory model is really great to > program), then you're fine. Bu

Re: wip-ports-refactor

2016-05-10 Thread Andy Wingo
On Tue 10 May 2016 17:02, Andy Wingo writes: > (with-output-to-file "/tmp/testies.txt" (lambda () (do-times #e1e6 > (write-char #\a Sorry, I meant #e1e7. The file really does have 10M characters. Actually 10M+1 because of a do-times bug :P > > This is in a UTF-8 locale. OK. So we have

Re: wip-ports-refactor

2016-05-10 Thread Andy Wingo
Greets, On Sun 17 Apr 2016 10:49, Andy Wingo writes: > | baseline | foo| port-line | peek-char > --+--++---+-- > guile 2.0 | 0.269s | 0.845s | 1.067s| 1.280s > guile master | 0.058s | 0.224

Re: wip-ports-refactor

2016-05-10 Thread Andy Wingo
Hi :) On Sun 24 Apr 2016 13:05, Chris Vine writes: > on the question of guile's thread implementation, it seems to me to be > basically sound if you avoid obvious global state. I have had test > code running for hours, indeed days, without any appearance of data > races or other incorrect behav

Re: wip-ports-refactor

2016-04-24 Thread Chris Vine
On Wed, 06 Apr 2016 22:46:28 +0200 Andy Wingo wrote: > So, right now Guile has a pretty poor concurrency story. We just have > pthreads, which is great in many ways, but nobody feels like > recommending this to users. The reason is that when pthreads were > originally added to Guile, they were d

Re: wip-ports-refactor

2016-04-19 Thread Ludovic Courtès
Hello! Andy Wingo skribis: > On Sun 17 Apr 2016 12:44, l...@gnu.org (Ludovic Courtès) writes: > >> Andy Wingo skribis: >> >>> I want to test four things. >>> >>> ;; 1. How long a loop up to 10 million takes (baseline measurement). >>> (let ((port (open-input-string "s"))) (do-times #e1e

Re: wip-ports-refactor

2016-04-19 Thread Andy Wingo
Hi, On Sun 17 Apr 2016 12:44, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo skribis: > >> I want to test four things. >> >> ;; 1. How long a loop up to 10 million takes (baseline measurement). >> (let ((port (open-input-string "s"))) (do-times #e1e7 1)) >> >> ;; 2. A call to a

Re: wip-ports-refactor

2016-04-17 Thread Ludovic Courtès
Andy Wingo skribis: > I want to test four things. > > ;; 1. How long a loop up to 10 million takes (baseline measurement). > (let ((port (open-input-string "s"))) (do-times #e1e7 1)) > > ;; 2. A call to a simple Scheme function. > (define (foo port) 42) > (let ((port (open-inp

Re: wip-ports-refactor

2016-04-17 Thread Andy Wingo
Hi :) On Thu 14 Apr 2016 16:03, l...@gnu.org (Ludovic Courtès) writes: > Andy Wingo skribis: > >> I have been working on a refactor to ports. The goal is to have a >> better concurrency story. Let me tell that story then get down to the >> details. > > In addition to concurrency and thread-saf

Re: wip-ports-refactor

2016-04-14 Thread Ludovic Courtès
Hi! Andy Wingo skribis: > I have been working on a refactor to ports. The goal is to have a > better concurrency story. Let me tell that story then get down to the > details. In addition to concurrency and thread-safety, I’m very much interested in the impact of this change on the API (I’ve a

Re: wip-ports-refactor

2016-04-13 Thread Christopher Allan Webber
Andy Wingo writes: > Hi! > > Summarizing my reply over IRC: > > On Thu 07 Apr 2016 06:16, Christopher Allan Webber > writes: > >> So, does this branch replace ethreads, or compliment it? Where should I >> be focusing my (currently limited) review / integration attempt energy? >> I've been hopin

Re: wip-ports-refactor

2016-04-12 Thread Andy Wingo
On Wed 06 Apr 2016 22:46, Andy Wingo writes: > I have been working on a refactor to ports. The status is that in wip-ports-refactor I have changed the internal port implementation to always have buffers, and that those buffers are always bytevectors (internally encapsulated i

Re: wip-ports-refactor

2016-04-12 Thread Andy Wingo
Hi! Summarizing my reply over IRC: On Thu 07 Apr 2016 06:16, Christopher Allan Webber writes: > So, does this branch replace ethreads, or compliment it? Where should I > be focusing my (currently limited) review / integration attempt energy? > I've been hoping to review ethreads this week but

Re: wip-ports-refactor

2016-04-06 Thread Christopher Allan Webber
Andy Wingo writes: > Hi, > > I have been working on a refactor to ports. The goal is to have a > better concurrency story. Let me tell that story then get down to the > details. Hoo, what an email! I need to read your code before I can do a full commentary. But... > More appropriate is 8sync

wip-ports-refactor

2016-04-06 Thread Andy Wingo
Hi, I have been working on a refactor to ports. The goal is to have a better concurrency story. Let me tell that story then get down to the details. So, right now Guile has a pretty poor concurrency story. We just have pthreads, which is great in many ways, but nobody feels like recommending t