December 11, 2009 Re: "Almost there" version of TDPL updated on Safari Rough Cuts | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | == Quote from Sean Kelly (sean@invisibleduck.org)'s article > Álvaro Castro-Castilla Wrote: > > > > Language extensions for message passing, such as Kilim for Java send messages giving away the ownership of data, not copying it. That's a reason for the need of compiler/runtime support. > Knowledge of unique ownership can obviate the need for copying, but copying is a reasonable fall-back in most cases. > > Also, parallel map/foreach is more feasible as a library-only solution, whether the message passing requires some support from the runtime environment. > It really depends on the language and what your goals are. There are message passing libraries for C, for example, but they don't provide much in the way of safety. IDK, generally I agree with the idea that D and Phobos should provide safe defaults and more efficiency when you really need it and explicitly ask for it. The exception, though, is when someone is using a construct that would only be used by people who really need efficiency, and thus has already explicitly asked for efficiency. This includes parallel foreach. In these cases, I think that "efficiency first, safety second" has to be the rule and there should never, ever be any implicit copying. If you can't implement this safely, then it should be implemented unsafely and place the onus of ensuring safety on the programmer. Concurrency for purposes other than pure throughput performance is a completely different animal, though one that I admittedly have never needed to deal with. Here, safety counts much more. |
December 11, 2009 Re: "Almost there" version of TDPL updated on Safari Rough Cuts | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | dsimcha:
> The exception, though, is when someone is using a construct that would only be used by people who really need efficiency, and thus has already explicitly asked for efficiency. This includes parallel foreach. In these cases, I think that "efficiency first, safety second" has to be the rule and there should never, ever be any implicit copying. If you can't implement this safely, then it should be implemented unsafely and place the onus of ensuring safety on the programmer.
@system parallel_foreach()
Vs:
parallel_foreach()
? :-)
When they can be created it's useful to have handy safe alternatives (possibly the default ones).
Bye,
bearophile
|
December 11, 2009 Re: "Almost there" version of TDPL updated on Safari Rough Cuts | ||||
---|---|---|---|---|
| ||||
Posted in reply to dsimcha | dsimcha Wrote:
> == Quote from Sean Kelly (sean@invisibleduck.org)'s article
> > Álvaro Castro-Castilla Wrote:
> > >
> > > Language extensions for message passing, such as Kilim for Java send messages
> giving away the ownership of data, not copying it. That's a reason for the need of compiler/runtime support.
> > Knowledge of unique ownership can obviate the need for copying, but copying is a
> reasonable fall-back in most cases.
> > > Also, parallel map/foreach is more feasible as a library-only solution,
> whether the message passing requires some support from the runtime environment.
> > It really depends on the language and what your goals are. There are message
> passing libraries for C, for example, but they don't provide much in the way of safety.
>
> IDK, generally I agree with the idea that D and Phobos should provide safe defaults and more efficiency when you really need it and explicitly ask for it. The exception, though, is when someone is using a construct that would only be used by people who really need efficiency, and thus has already explicitly asked for efficiency. This includes parallel foreach.
Yeah, that's why I said in my original reply that if message passing were used, it may be necessary to use casting to avoid copying. However, it may just be enough to just pass a slice of a shared range. Nothing has really been decided regarding restrictions for what can be passed.
|
Copyright © 1999-2021 by the D Language Foundation