review of std.parallelism

Michel Fortin michel.fortin at michelf.com
Mon Mar 21 08:37:10 PDT 2011


On 2011-03-21 09:50:09 -0400, dsimcha <dsimcha at yahoo.com> said:

> On 3/21/2011 8:37 AM, Michel Fortin wrote:
>> Well, it'll work irrespective of whether shared delegates are used or
>> not. I think you could add a compile-time check that the array element
>> size is a multiple of the word size when the element is passed by ref in
>> the loop and leave the clever trick as a possible future improvements.
>> Would that work?
> 
> On second thought, no, but for practical, not theoretical reasons:  
> One, you can't introspect whether a foreach loop is using a ref or a 
> value parameter.  This is an issue with how opApply works.

Indeed a problem. Either we fix the compiler to support that, or we 
change the syntax to something like this:

	taskPool.apply(range, (ref int value) {
		...
	});

Or we leave things as they are.

> Two, AFAIK there's no way to get the native word size.

Right. That's a problem too... you could probably alleviate this by 
doing a runtime check with some fancy instructions to get the native 
word size, but I'd expect that to be rather convoluted.

I'd like to check if I understand that well. For instance this code:

	int[100] values;
	foreach (i, ref value; parallel(values))
		value = i;

would normally run fine on a 32-bit processor, but it'd create 
low-level a race on a 64-bit processor (even a 64-bit processor running 
a 32-bit program in 32-bit compatibility mode). And even that is a 
generalization, some 32-bit processors out there *might* have 64-bit 
native words. So the code above isn't portable. Is that right?

Which makes me think... we need to document those pitfalls somewhere. 
Perhaps std.parallelism's documentation should link to a related page 
about what you can and what you can't do safely. People who read that 
"all the safeties are off" in std.parallelism aren't going to 
understand what you're talking about unless you explain the pitfalls 
with actual examples (like the one above).


> Unfortunately, I'm going to have to take a hard line on this one.  The 
> issue of integrating std.parallelism into the race safety system had 
> been discussed a bunch in the past and it was basically agreed that 
> std.parallelism is a "here be dragons" module that cannot reasonably be 
> made to conform to such a model.

About the "cannot reasonably be made to conform to such a model" part: 
that is certainly true today, but might turn out not to be true as the 
model evolves. It certainly is true as long as we don't have shared 
delegates. Beyond that it becomes more fuzzy. The final goal of the 
module shouldn't be to bypass safeties but to provide good parallelism 
primitives. By all means, if safeties can be enabled reasonably they 
should be (but as of today, they can't).

And I totally agree with you that it's quite silly to require casts 
everywhere to use synchronized. I'll be the first to admit that it's 
hard to see synchronized classes being very practical as they're 
implemented today. There's room for improvements there too.


> Given the choice (and I hope I'm not forced to make this choice) I'd 
> rather std.parallelism be a third-party module that's actually usable 
> than a Phobos module that is such a PITA to use that noone does in 
> practice.

Which is understandable.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/



More information about the Digitalmars-d mailing list