Necessities for Adoption of D

[Burton Radons]

Jesse Phillips Wrote:

> On Sun, 10 Feb 2008 22:59:49 -0500, Burton Radons wrote:
> 
> > Hans W. Uhlig Wrote:
> > 
> >> 3) Good, native parallelism - With dual core, quad core, or in IBM's
> >> Cell  processor Obscene core processors, none of the current C Syntax
> >> family is parallelism handled natively and "well".
> > 
> > Do you mean in the library or in the language? I don't think D can be a
> > magically-parallelising language; it's not constructed for it, and while
> > it's a cool trick in those languages which do it I'd be worried about it
> > not parallelising important code because of some functional test
> > incorrectly failing and making it run sequentially.
> 
> Well that's what D2 is getting ready for, magically-paralleling programs. 
> It already supports threading which is explicit. Granted its not the 
> simplest to use, but I think paralleling will be evolving soon for D. 
> (And by soon I mean later)

Reference? I don't use 2.0. Anyway what I said holds IMO - when you want code to be executed in parallel, it's not something that should be left to an overly-cautious safety check. For instance, it'd be extremely hard to prove that asm blocks containing SIMD code can be safely parallelised since they may or may not be utilising their own output as input. Yet that's precisely the situation in which parallelisation needs to be done most aggressively. You can also make better decisions about when an array is going to get long enough to merit splitting, while the compiler can only do this after instrumenting. And when I'm optimising code, the last thing I want is for seemingly harmless changes to suddenly cause jumps of 30% in execution speed, which is what could happen with automatic parallelisation.