3 ms·
The languages that use arrays efficiently for parallel programming (i.e. GPU languages) aren't general-purpose programming languages; programs in those language
by timrobinson 16y ago
The languages that use arrays efficiently for parallel programming (i.e. GPU languages) aren't general-purpose programming languages; programs in those languages are written with data parallelism in mind. C# is a general-purpose imperative language; it's very hard to take a program in a language such as C#, where mutation is interspersed throughout the code, and parallelise it automatically.
"I'm impressed by the posters knowledge of C#" - Eric Lippert designed and implemented large parts of the last couple of versions of the C# language and compiler.
- jasonwatkinspdx 16y ago"The languages that use arrays efficiently for parallel programming (i.e. GPU languages) aren't general-purpose programming languages" I disagree. Typically these languages are supersets of general purpose languages like c. That is, they are c code with additional annotations (OpenMP) or use annotations with some initialization API (GPU languages). On top of that, there are purely array based general purpose languages (APL, J, K, NESL, etc). "it's very hard to take a program in a language such as C#, where mutation is interspersed throughout the code, and parallelise it automatically." I agree with qualifications. It's not so much the mutation that is fault, but the over specification of dependence. For example, map() makes clear that the iteration is data parallel. It is trivial to convert map() to pmap(). for() does not say anything about the iteration being data parallel, so to convert this to par() the compiler must do an analysis. Depending on the program this may require an alias analysis. While this may be possible, and perhaps even easy for common cases, to do so in general requires quite complex analysis. In any case, I think it's perfectly possible to create a parallel mutable language. In fact, the agent model readily encapsulates mutability in a parallel and distributed way. So while I agree with the critique in the context of C#, I don't agree with how the author generalizes it to the topic of languages as a whole.