nigelsande...@btconnect.com wrote:
There are very few algorithms that actually benefit from using even low
hundreds of threads, let alone thousands. The ability of Erlang (and go
an IO and many others) to spawn 100,000 threads makes an impressive demo
for the uninitiated, but finding practical
On Fri, 14 May 2010 17:35:20 +0100, B. Estrade - estr...@gmail.com
<+nntp+browseruk+c4c81fb0fa.estrabd#gmail@spamgourmet.com> wrote:
The future is indeed multicore - or, rather, *many-core. What this
means is that however the hardware jockeys have to strap them together
on a single node, w
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com wrote:
> On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl
> <+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com> wrote:
>
>
> >
> >The support of threading should be completely optional. T
On Fri, May 14, 2010 at 06:03:46PM +0100, nigelsande...@btconnect.com wrote:
> On Fri, 14 May 2010 15:05:44 +0100, B. Estrade wrote:
>
> >On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com
> >wrote:
> >>On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol -
> >>rv...@isolu
On Fri, May 14, 2010 at 09:50:21AM -0700, Larry Wall wrote:
> On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
...
>
> But as you say, this is not a simple problem to solve; our response
> should not be to punt this to future generations, but to solve it
> as best as we can, a
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
> After reading this thread and S17, I have lots of questions and some
> remarks.
>
> Parallelism and Concurrency could be considered to be two different things.
>
> The hyperoperators and junctions imply, but do not require, pa
On Fri, 14 May 2010 15:05:44 +0100, B. Estrade wrote:
On Fri, May 14, 2010 at 12:27:18PM +0100, nigelsande...@btconnect.com
wrote:
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol -
rv...@isolution.nl
<+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com> wrote:
>
>The suppo
On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
: After reading this thread and S17, I have lots of questions and some
: remarks.
:
: Parallelism and Concurrency could be considered to be two different things.
:
: The hyperoperators and junctions imply, but do not require,
: p
Em Sex, 2010-05-14 às 15:48 +0400, Richard Hainsworth escreveu:
> The less, or rather the more abstract, the specification in perl6, the
> less likely perl6 will 'age'.
I think the important thing to realize here is that the Perl 6 language
keeps its definitions mostly abstract. Junctions, Hyper O
After reading this thread and S17, I have lots of questions and some
remarks.
Parallelism and Concurrency could be considered to be two different things.
The hyperoperators and junctions imply, but do not require, parallelism.
It is left for the implementors to resolve whether a single or mult
On Fri, 14 May 2010 10:01:41 +0100, Ruud H.G. van Tol - rv...@isolution.nl
<+nntp+browseruk+014f2ed3f9.rvtol#isolution...@spamgourmet.com> wrote:
The support of threading should be completely optional. The threading
support should not be active by default.
I'd like to understand why you
Ruud (>):
> (Do Perl_6 hyper-operators need pthreads?)
No. The ability to thread over list elements in a hyper operator is
more of a possibility than a requirement, if I understand things
correctly.
// Carl
Jason Switzer wrote:
On Thu, May 13, 2010 at 3:59 AM, wrote:
And at the core of that, is the need for preemptive (kernel) threading and
shared memory.
These can (and should!) be hidden from the application programmer, through
the use of language and/or library
level abstractions, of which th
On Thu, May 13, 2010 at 3:59 AM, wrote:
> This should be a reply to Daniel Ruoso's post above, but I cannot persuade
> my nntp reader
> to reply to a post made before I subscribed here. Sorry
>
> And at the core of that, is the need for preemptive (kernel) threading and
> shared memory.
>
> These
This should be a reply to Daniel Ruoso's post above, but I cannot persuade
my nntp reader
to reply to a post made before I subscribed here. Sorry
On Wed, 12 May 2010 14:16:35 +0100, Daniel Ruoso wrote:
I have 3 main problems with your thinking.
1: You are conflating two fundamentally differe
On Wed, May 12, 2010 at 8:57 PM, Alex Elsayed wrote:
> Forgot to send this to the list.
>
> -- Forwarded message --
> From: Alex Elsayed ...
>
It's also CPS based, which fits pretty well.
>
Here's another, one that might fit more readily with perlesque/CLR:
Actors that Unify T
Forgot to send this to the list.
-- Forwarded message --
From: Alex Elsayed
Date: Wed, May 12, 2010 at 8:55 PM
Subject: Re: Ideas for a "Object-Belongs-to-Thread" threading model
To: Daniel Ruoso
You may find interesting a paper that was (at one point) listed
in the
Em Qua, 2010-05-12 às 10:12 -0700, Dave Whipp escreveu:
> Before discussing the implementation, I think it's worth while
> stating
> what it is that you are attempting to abstract. For example, is the
> abstraction intended for a mapping down to a GPU (e.g. OpenCL) with a
> hierarchical address
Daniel Ruoso wrote:
Hi,
The threading model topic still needs lots of thinking, so I decided to
try out some ideas.
Every concurrency model has its advantages and drawbacks, I've been
wondering about this ideas for a while now and I think I finally have a
sketch. My primary concerns were:
1 -
I might have some more to say about any threading model later, but for
now I wanted to make everyone aware of a scripting language that is
"truly" multi-threaded - you may want to check it out. Some of it's
syntax is Perlish, whereas some is not - the point is that it is
supposed to scale on SMP ma
Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu:
> he threading model topic still needs lots of thinking, so I decided to
> try out some ideas.
After I sent the second version, I just realized I could make it simpler
by just assuming "one OS thread per Coroutine Group"... so here goes the
Em Ter, 2010-05-11 às 21:45 -0300, Daniel Ruoso escreveu:
> The threading model topic still needs lots of thinking, so I decided to
> try out some ideas.
After BrowserUK feedback and some more reading (including
http://www.c2.com/cgi/wiki?MessagePassingConcurrency ) and links from
there on, I deci
BrowserUK wrote:
> > -there are the interpreter processes.
> > Inventing (overloaded) terminology will just create confusion. Very
> > unhelpful in a context that suffers more than its fair share already.
Okay, I should probably call them "Actors" to use a more precise
terminology - since this
On Tue, 11 May 2010, Daniel Ruoso wrote:
2 - The interpreter implements a scheduler, just like POE.
I don't have a clue about threading, but I saw POE, and since I know
that's an event loop mechanism, I thought I'd comment that I want to be able
to do GTK programming, which I think requires
Since I don't think BrowserUK subscribes here, I'll paste in the remarks
he attached to your earlier paste, just to help get the discussion going,
and on the assumption this will not be regarded as antisocial. :)
Larry
BrowserUK wrote:
>
> -there are the interpreter processes.
>
> Inventin
Hi,
The threading model topic still needs lots of thinking, so I decided to
try out some ideas.
Every concurrency model has its advantages and drawbacks, I've been
wondering about this ideas for a while now and I think I finally have a
sketch. My primary concerns were:
1 - It can't require lock
26 matches
Mail list logo
