On Oct 6, 2011, at 4:48 AM, Robby Findler wrote:
> Do you want async-channel, maybe? If not, then rolling your own
> syncronization pattern via the CML-like primitives is the way to go.
> Once you get used to programming with them, they are very easy to use
> and easy to make thread-safe things (
Do you want async-channel, maybe? If not, then rolling your own
syncronization pattern via the CML-like primitives is the way to go.
Once you get used to programming with them, they are very easy to use
and easy to make thread-safe things (contrary to popular wisdom that
thread-safety is hard to ac
>> - If the original list to be processed is very long, then the construction
>> of >> the second phase list shouldn't wait for bottle neck items to cons
>> the list >> elsewhere where possible. The speed gain wouldn't be
>> substantial though, >> since it is just building a list, and you cannot
rzilay [mailto:e...@barzilay.org]
> Sent: 03 October 2011 22:57
> To: jukka.tuomi...@finndesign.fi
> Cc: Sam Tobin-Hochstadt; Racket mailing list; Robby Findler; Ivanyi
> Peter
> Subject: Re: [racket] Concurrent execution
>
>
> Four hours ago, jukka.tuomi...@finndesign.
Four hours ago, jukka.tuomi...@finndesign.fi wrote:
>
> Wow, that's great Sam!
>
> I tried to create a simple test around it (below), but it's hard to find a
> pattern in the results. A few notes, though:
>
> - The results vary a great deal from run to run
> - 'Plain map' seems to do things in p
Wow, that's great Sam!
I tried to create a simple test around it (below), but it's hard to find a
pattern in the results. A few notes, though:
- The results vary a great deal from run to run
- 'Plain map' seems to do things in parallel itself!?
(by looking at the System Monitor during the test
On Mon, Oct 3, 2011 at 2:25 AM, Jukka Tuominen
wrote:
>
> Sorry for thinking aload again, but I'm learning these issues myself in the
> background, and I wonder if something like the following might work?
>
> Concurrent List Processing -idea
>
> Two phase process
>
> 1) Distribution phase
> Creat
by Findler
> Sent: 01 October 2011 06:02
> To: Ivanyi Peter
> Cc: Racket mailing list
> Subject: Re: [racket] Concurrent execution
>
>
> Futures will let you share data, but you'd have to try to avoid
> allocation in the futures (not completely, just mostly) for good
>
Futures will let you share data, but you'd have to try to avoid
allocation in the futures (not completely, just mostly) for good
performance (so you'd probably want to build vectors to save the
results into). For places, you cannot share the database, you'd have
to send if over a place channel to b
9 matches
Mail list logo
