Am 25.03.2011 15:40, schrieb dsimcha:
On 3/25/2011 5:42 AM, Sönke Ludwig wrote:
Am 25.03.2011 10:33, schrieb Sönke Ludwig:
yadda-yadda
>
Apart from all this - I just want to make this a known problem, what you
(or maybe Andrei for std.concurrency) decide is up to you and I'm fine
with any out
On 3/25/2011 5:42 AM, Sönke Ludwig wrote:
Am 25.03.2011 10:33, schrieb Sönke Ludwig:
yadda-yadda
>
Apart from all this - I just want to make this a known problem, what you
(or maybe Andrei for std.concurrency) decide is up to you and I'm fine
with any outcome for my personal stuff because I d
Am 25.03.2011 10:33, schrieb Sönke Ludwig:
yadda-yadda
>
Apart from all this - I just want to make this a known problem, what you
(or maybe Andrei for std.concurrency) decide is up to you and I'm fine
with any outcome for my personal stuff because I do not have such a
complex system apart fr
Am 25.03.2011 05:14, schrieb dsimcha:
On 3/24/2011 10:21 PM, Sönke Ludwig wrote:
Can you elaborate and/or provide an example of the "general" problem?
I'm not quite sure what you're getting at.
I have one very specific constellation that I can only sketch.. Suppose
you have some kind of compl
Am 25.03.2011 04:32, schrieb dsimcha:
On 3/24/2011 10:31 PM, Sönke Ludwig wrote:
Well what can I say.. things can become more complex and you cannot
always say this is parallelism and this is concurrency ore something.
It's just nice when the libary does not get in the way when you are in a
situ
On 3/24/2011 10:21 PM, Sönke Ludwig wrote:
Indeed this pattern solves the problem to wait for the completion of a
specific task. It also avoids a huge potential of deadlocks that a
general yield() that does not take a task would have. However, it will
not solve the general problem of one task wai
On 3/24/2011 10:31 PM, Sönke Ludwig wrote:
Well what can I say.. things can become more complex and you cannot
always say this is parallelism and this is concurrency ore something.
It's just nice when the libary does not get in the way when you are in a
situation where eg. throughput and responsi
Am 25.03.2011 02:51, schrieb dsimcha:
On 3/24/2011 9:15 PM, Sönke Ludwig wrote:
Am 24.03.2011 13:03, schrieb Michel Fortin:
On 2011-03-24 03:00:01 -0400, Sönke Ludwig
said:
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to
Am 25.03.2011 02:17, schrieb dsimcha:
On 3/24/2011 9:05 PM, Sönke Ludwig wrote:
This may not be an issue in the std.parallelism design. A TaskPool task
can safely wait on other tasks. What prevents this from causing a
deadlock is that calling yieldForce, spinForce, or waitForce on a task
that ha
On 3/24/2011 9:15 PM, Sönke Ludwig wrote:
Am 24.03.2011 13:03, schrieb Michel Fortin:
On 2011-03-24 03:00:01 -0400, Sönke Ludwig
said:
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a
Task
Am 24.03.2011 13:03, schrieb Michel Fortin:
On 2011-03-24 03:00:01 -0400, Sönke Ludwig
said:
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a TaskPool.
(Should this have a less verbose name
On 3/24/2011 9:05 PM, Sönke Ludwig wrote:
This may not be an issue in the std.parallelism design. A TaskPool task
can safely wait on other tasks. What prevents this from causing a
deadlock is that calling yieldForce, spinForce, or waitForce on a task
that has not started executing yet will execut
Am 24.03.2011 14:25, schrieb dsimcha:
On 3/24/2011 3:00 AM, Sönke Ludwig wrote:
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a TaskPool.
(Should this have a less verbose name?)
The thread
On 3/24/2011 1:34 PM, spir wrote:
On 03/24/2011 05:32 PM, bearophile wrote:
I tried to keep it as consistent as possible with std.algorithm.
OK. Then the question is why std.algorithm uses normal strings instead
of q{} ones.
And regarding consistency with std.algorithm, a more important factor
> On 3/24/2011 8:35 AM, spir wrote:
> > On 03/24/2011 05:32 AM, dsimcha wrote:
> >> [...]
> >>
> >> The new docs are at
> >> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html .
> >
> > About the doc: very good. I could understand most of it, while knowing
> > nearly nothing about parallel
== Quote from spir (denis.s...@gmail.com)'s article
> On 03/24/2011 06:04 PM, dsimcha wrote:
> > Hmm, you do have a point there. Two reasons:
> >
> > 1. map() was there first and at the time I didn't feel like renaming it.
> >
> > 2. I think map() is much more frequently useful than lazyMap() an
== Quote from Russel Winder (rus...@russel.org.uk)'s article
> Is there actually any point in having a lazy parallel map?
It's for pipelining. Please read the API documentation for details about how it
works. It's actually only semi-lazy.
> > > Unfortunately I don't have access to this kind of
On Thu, 2011-03-24 at 12:32 -0400, bearophile wrote:
> dsimcha:
>
> > I tried to keep it as consistent as possible with std.algorithm.
>
> OK. Then the question is why std.algorithm uses normal strings instead of q{}
> ones.
Actually the question why user strings at all, why not have a lambda
f
On 03/24/2011 06:04 PM, dsimcha wrote:
Hmm, you do have a point there. Two reasons:
1. map() was there first and at the time I didn't feel like renaming it.
2. I think map() is much more frequently useful than lazyMap() and name
verbosity
should be inversely proportional to usage frequency.
On 03/24/2011 05:32 PM, bearophile wrote:
I tried to keep it as consistent as possible with std.algorithm.
OK. Then the question is why std.algorithm uses normal strings instead of q{}
ones.
And regarding consistency with std.algorithm, a more important factor is that
std.algorithm.map is laz
dsimcha:
> 2. I think map() is much more frequently useful than lazyMap() and name
> verbosity
> should be inversely proportional to usage frequency.
I agree, but I have suggested to replace "map" => "amap" and "lazyMap" => "map"
(and to add a fully eager amap to std.algorithm). The increase o
== Quote from bearophile (bearophileh...@lycos.com)'s article
> dsimcha:
> > I tried to keep it as consistent as possible with std.algorithm.
> OK. Then the question is why std.algorithm uses normal strings instead of q{}
> ones.
I personally think "" strings look nicer for simple cases like "a +
dsimcha:
> I tried to keep it as consistent as possible with std.algorithm.
OK. Then the question is why std.algorithm uses normal strings instead of q{}
ones.
And regarding consistency with std.algorithm, a more important factor is that
std.algorithm.map is lazy, while you have a eager map, a
On 3/24/2011 11:00 AM, Michel Fortin wrote:
What it adds is a task pool, where you have a fixed number of threads
for an unlimited number of tasks. Spawning 10,000 threads because you
have 10,000 parallelizable tasks generally isn't a good idea.
That said, perhaps std.concurrency's "spawn" sh
On 2011-03-24 10:43:08 -0400, dsimcha said:
Sounds like a good plan. In general, I've tried to keep the design of
std.parallelism simple but composable. I have no intention of
re-implementing any kind of message system when std.concurrency already
does this well. If this is what you want t
On 3/24/2011 10:34 AM, Michel Fortin wrote:
One thing I'd want to be sure however is that you can use a parallel
foreach from within a task. So if you have one or two tasks that could
benefit from data parallelism it won't bring the whole system down. From
the API I don't think it'll be a proble
On 2011-03-24 09:46:01 -0400, dsimcha said:
Please review the changes carefully, then, because this is a use case I
know next to nothing about and didn't design for.
Well, it's practically the same thing except you never want to execute
a task in the main thread, because the main thread acts
On 3/24/2011 8:03 AM, Michel Fortin wrote:
On 2011-03-24 03:29:52 -0400, Sönke Ludwig
said:
Hm depending on the way the pool is used, it might be a better default
to have the number of threads equal the number of cpu cores. In my
experience the control thread is mostly either waiting for tasks
On 3/24/2011 8:35 AM, spir wrote:
On 03/24/2011 05:32 AM, dsimcha wrote:
[...]
The new docs are at
http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html .
About the doc: very good. I could understand most of it, while knowing
nearly nothing about parallelism prior to reading.
2 details:
*
On 3/24/2011 3:29 AM, Sönke Ludwig wrote:
Hm depending on the way the pool is used, it might be a better default
to have the number of threads equal the number of cpu cores. In my
experience the control thread is mostly either waiting for tasks or
processing messages and blocking in between so it
On 3/24/2011 3:00 AM, Sönke Ludwig wrote:
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a TaskPool.
(Should this have a less verbose name?)
The threading system I designed for the company I
On 3/24/2011 3:23 AM, bearophile wrote:
dsimcha:
and apologize for getting defensive at times.
It happens to mammals, don't worry.
The new docs are at
http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html .
real getTerm(int i) {
immutable x = ( i - 0.5 ) * delta;
On 03/24/2011 05:32 AM, dsimcha wrote:
[...]
The new docs are at http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html .
About the doc: very good. I could understand most of it, while knowing nearly
nothing about parallelism prior to reading.
2 details:
* highlight key words only on firs
On 2011-03-24 03:29:52 -0400, Sönke Ludwig
said:
Hm depending on the way the pool is used, it might be a better default
to have the number of threads equal the number of cpu cores. In my
experience the control thread is mostly either waiting for tasks or
processing messages and blocking in b
On 2011-03-24 03:00:01 -0400, Sönke Ludwig
said:
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a TaskPool.
(Should this have a less verbose name?)
The threading system I designed for the
On 03/24/2011 05:32 AM, dsimcha wrote:
One thing Andrei mentioned that I'm really not sure about is what to do with
TaskPool.join(). My example for it is still terrible, because I think it's an
evolutionary artifact. It was useful in earlier designs that were never
released and didn't have high
Hm depending on the way the pool is used, it might be a better default
to have the number of threads equal the number of cpu cores. In my
experience the control thread is mostly either waiting for tasks or
processing messages and blocking in between so it rarely uses a full
core, wasting the av
dsimcha:
> and apologize for getting defensive at times.
It happens to mammals, don't worry.
> The new docs are at
> http://cis.jhu.edu/~dsimcha/d/phobos/std_parallelism.html .
>real getTerm(int i) {
>immutable x = ( i - 0.5 ) * delta;
>return delta / ( 1.0 + x * x ) ;
>
Am 24.03.2011 05:32, schrieb dsimcha:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a TaskPool.
(Should this have a less verbose name?)
The threading system I designed for the company I work for uses priority
per task to contro
On Thu, 24 Mar 2011 05:32:26 +0100, dsimcha wrote:
In addition to improving the documentation, I added
Task.executeInNewThread() to allow Task to be useful without a TaskPool.
(Should this have a less verbose name?)
spawnAndRun?
--
Simen
I've finished all of the changes that were discussed in the initial
std.parallelism review. I know I said I needed more time than this, but
honestly, I hit a best-case scenario. I had more time than I
anticipated to work on it *and* the changes (especially fixing the
exception handling issue)
41 matches
Mail list logo
