"Windows and Linux Not Well Prepared For Multicore Chips" http://developers.slashdot.org/article.pl?sid=09/03/22/193205&from=rss

I wouldn't completely agree that operating systems aren't ready for such things.

One of the comments reads: "This is the kind of the the compiler could do just fine ... by isolating parts of the code in which there are no dependencies in the data-flow, and which could therefore run in parallel..."

This sounds like what "pure" functions are going to be for, right?

On Sun, Mar 22, 2009 at 9:55 PM, Brian <digitalmars@brianguertin.com> wrote:
> "Windows and Linux Not Well Prepared For Multicore Chips" http://developers.slashdot.org/article.pl?sid=09/03/22/193205&from=rss
>
> I wouldn't completely agree that operating systems aren't ready for such things.
>
> One of the comments reads: "This is the kind of the the compiler could do just fine ... by isolating parts of the code in which there are no dependencies in the data-flow, and which could therefore run in parallel..."
>
> This sounds like what "pure" functions are going to be for, right?

That's more or less exactly what they're for.

On Sun, 22 Mar 2009 21:55:04 -0400, Brian <digitalmars@brianguertin.com> wrote:

> "Windows and Linux Not Well Prepared For Multicore Chips"
> http://developers.slashdot.org/article.pl?sid=09/03/22/193205&from=rss
>
> I wouldn't completely agree that operating systems aren't ready for such
> things.
>
> One of the comments reads: "This is the kind of the the compiler could do
> just fine ... by isolating parts of the code in which there are no
> dependencies in the data-flow, and which could therefore run in
> parallel..."
>
> This sounds like what "pure" functions are going to be for, right?

Yes and No. No, what they are talking about is a parallelizing compiler. i.e. one that performs automatic parallelization / code analysis, which for the most part doesn't work because it has no grantees. And yes, pure is all about giving the complier the grantees it needs to actually automatically parallelize the code.

On Sun, 22 Mar 2009 22:09:53 -0400, Robert Jacques <sandford@jhu.edu> wrote:

> On Sun, 22 Mar 2009 21:55:04 -0400, Brian <digitalmars@brianguertin.com> wrote:
>
>> "Windows and Linux Not Well Prepared For Multicore Chips"
>> http://developers.slashdot.org/article.pl?sid=09/03/22/193205&from=rss
>>
>> I wouldn't completely agree that operating systems aren't ready for such
>> things.
>>
>> One of the comments reads: "This is the kind of the the compiler could do
>> just fine ... by isolating parts of the code in which there are no
>> dependencies in the data-flow, and which could therefore run in
>> parallel..."
>>
>> This sounds like what "pure" functions are going to be for, right?
>
> Yes and No. No, what they are talking about is a parallelizing compiler. i.e. one that performs automatic parallelization / code analysis, which for the most part doesn't work because it has no grantees. And yes, pure is all about giving the complier the grantees it needs to actually automatically parallelize the code.

Okay, next time I should read TFA before posting. What the author is talking about isn't pure or parallelizing compilers. What he's actually talking about is adding parallel instructions to the CPU. (The focus was on Itanium (which exchanged out-of-order execution for compiler controlled parallel instructions), though it could easily apply to the next SSE instruction set (specifically the one coming with larrabee) which primarily adds conditional tests and an execution mask. These allow for SIMD flow control (and have been in GPUs for a while) )

Jarrett Billingsley wrote:
> On Sun, Mar 22, 2009 at 9:55 PM, Brian <digitalmars@brianguertin.com> wrote:
>> This sounds like what "pure" functions are going to be for, right?
> That's more or less exactly what they're for.

Only partially. Pure functions are also a valuable tool to aid in modularizing code and self-documenting that it is modularized. Pure functions have some minor optimization benefits.