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
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
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.)
>
>
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
19 matches
Mail list logo