Is generalized decomposition by the compiler considered a viable technology to pursue? I am sure there is a certain level of intuition that leads to recognition of dependencies and there might even be some analysis needed before dependencies can be identified, which might be extremely difficult and time consuming for a compiler.
On another note, how come CUDA wasn't based around a functional programming language such as OCaml? Wouldn't the higher level abstractions provided by such a language ensure better side effect free computation? Also it just seems that parallelism is better expressed in such language because of the nature of the abstractions provided? Is it just because most programmers are more comfortable with C that CUDA was designed in such a way?
0xc0ffee
@kidz I had this same thought regarding OCaml v CUDA. My short justification is that some of the index-heavy code that you can write in CUDA isn't easily written in OCaml. (Awkward tabulates, etc).
The C-style is somehow more expressive. (Maybe).
I'd be interested to hear more on this topic.
bullseye
Interestingly, CUDA actually doesn't support the full C standard. Its primary compliance lies with C++, making some valid C code unable to compile.
Also, CUDA is just a model that gives extensions to the programming language employed to express parallelism. Finally, C is not only less memory-intensive, but also easier to analyze for performance than OCaml.
kayvonf
@bullseye. I'm curious. What do you mean when you said "C is easier to analyze for performance than OCaml?"
bullseye
@kayvonf C has a clearer cost model than OCaml, particularly because in C, memory allocation is explicit (not so explicit in OCaml). This makes analyzing C code easier and more predictable.
bdebebe
@0xc0ffee I'm interested what you mean by C-style is somehow more expressive. I think OCaml and C are different in many regards, and although I agree with @bullseye about being able to analyze C code for its memory allocation, I think Ocaml is still pretty predictable, although that might just be that I have been exposed to much more complicated C code than OCaml code.
Is generalized decomposition by the compiler considered a viable technology to pursue? I am sure there is a certain level of intuition that leads to recognition of dependencies and there might even be some analysis needed before dependencies can be identified, which might be extremely difficult and time consuming for a compiler.
On another note, how come CUDA wasn't based around a functional programming language such as OCaml? Wouldn't the higher level abstractions provided by such a language ensure better side effect free computation? Also it just seems that parallelism is better expressed in such language because of the nature of the abstractions provided? Is it just because most programmers are more comfortable with C that CUDA was designed in such a way?
@kidz I had this same thought regarding OCaml v CUDA. My short justification is that some of the index-heavy code that you can write in CUDA isn't easily written in OCaml. (Awkward tabulates, etc).
The C-style is somehow more expressive. (Maybe).
I'd be interested to hear more on this topic.
Interestingly, CUDA actually doesn't support the full C standard. Its primary compliance lies with C++, making some valid C code unable to compile.
Also, CUDA is just a model that gives extensions to the programming language employed to express parallelism. Finally, C is not only less memory-intensive, but also easier to analyze for performance than OCaml.
@bullseye. I'm curious. What do you mean when you said "C is easier to analyze for performance than OCaml?"
@kayvonf C has a clearer cost model than OCaml, particularly because in C, memory allocation is explicit (not so explicit in OCaml). This makes analyzing C code easier and more predictable.
@0xc0ffee I'm interested what you mean by C-style is somehow more expressive. I think OCaml and C are different in many regards, and although I agree with @bullseye about being able to analyze C code for its memory allocation, I think Ocaml is still pretty predictable, although that might just be that I have been exposed to much more complicated C code than OCaml code.