Necessities for Adoption of D

[Jesse Phillips]

On Mon, 11 Feb 2008 02:07:29 -0500, Burton Radons wrote:

> 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.

I don't recall the news posts that discussed such possibilities, but it 
relates to the fact that D is heading towards adding more functional 
style programming. This is where const and invariant are playing a big 
roll. I don't know if Walter has come out and said it will allow for 
automatic paralleling, but any move toward function coding lends to such 
possibilities.