[sillysaurus2]

I invite anyone who thinks C is low level to try their hand at CUDA or OpenCL.

You think C is bad? Those are far worse.

This is at least a great step in the right direction. It's not "low level" as you describe just because it's C.

[rbonvall]

You know what's worse than CUDA or OpenCL? General purpose algorithms implemented in a graphics API.

I read a lot of GPGPU papers at the university, and I could never understand the older ones, that described algorithms by mapping everything to graphics elements, and computed the solutions as a side-effect of rendering something.

Next to that, undestanding an algorithm implemented in CUDA is a breeze.

[foxhill]

i will preface this by saying i'm a C programmer at heart,

CUDA and OpenCL demand a depth of understanding of both C, and how your code is executed on many core processors. but i wouldn't call either of them terrible.

i would however, very much like to see a widespread higher level API for doing compute on GPUs, if only to encourage people to understand the lower level details.

[stass]

I didn't say at all that C is bad, as a matter of fact I write most of my code in C. It is, however a low-level programming language not much different from assembly.

The reason it is that it operates on concepts that are not abstract but are of register machines. A high completely abstracts underlying architecture so the code can be executed in any possible environment by means of translation, be it a $10MM Cray or a cellular automaton or a mechanical computer. In essence, a high level language provides an abstract notation for computation.

C, however, is not abstract at all. Variables? How those will map to a dataflow computation? Pointers? Would not work beyond register CPUs (e.g. it is very cumbersome to translate C programs to Javascript as a result and usually leads to a memory array emulation). Fixed-width types? Volatile pointers? Returns from the middle of a procedure? Gotos? Come on, how those are even going to run on a non-conventional architecture?

C also does not completely define the language semantics leaving certain operations implementation-specific or undefined. It also (before C11) didn't define any memory model, thus making it impossible to even describe an algorithm that depends on specific properties of memory accesses in a way that will be portable across different register machines. C algorithms are close to impossible to translate to be run on memory-less computation devices as the whole concept of C is based around having local memory and a stack space with certain properties (unless one wants to emulate a register machine, see JavaScript remark above).

In certain areas it lead to some ugly solutions like Cuda where the language looks like C but semantics is completely different and GPUs are the closest thing to he original C target as you can get.