review of std.parallelism

dsimcha dsimcha at yahoo.com
Mon Mar 21 08:58:28 PDT 2011


== Quote from dsimcha (dsimcha at yahoo.com)'s article
> == Quote from Michel Fortin (michel.fortin at michelf.com)'s article
> > > 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).
> This problem is **much** less severe than you are suggesting.  x86 can address
> single bytes, so it's not a problem even if you're iterating over bytes on a
> 64-bit machine.  CPUs like Alpha (which no D compiler even exists for) can't
> natively address individual bytes.  Therefore, writing to a byte would be
> implemented much like writing to a bit is on x86:  You'd read the full word in,
> change one byte, write the full word back.  I'm not sure exactly how it would be
> implemented at the compiler level, or whether you'd even be allowed to have a
> reference to a byte in such an implementation.  This is why I consider this more a
> theoretical problem than a serious practical issue.

Actually, just remembered that word tearing is also an issue with unaligned memory
access.  I guess I could just include a warning that says not to do this with
unaligned memory.


More information about the Digitalmars-d mailing list