Imagine if Microsoft begins saving users' information using its operating system. As result they got more information on you even than Google or anyone else.
Generalizing, there's really a math relation but it's most because the language designer wanted this. Nobody wanted to add this feature (not so trivial to a compiler) if they just could return a struct.
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.
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.
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.
C is no where near as low level as you can get. C-- is closer. LLVM-IR is even closer. but really, the lowest level you can get is the assembly of the architecture you're running on.
at the time of the creation, the general consensus was that C was too high level, that it abstracted away the actual workings of the code.
we've been introduced to high level languages that have made us re-evaluate what it means to be low or high level. but make no mistake, C is.. at least medium-level..!
At the risk of being pointlessly pedantic: assembly is surely not the lowest level relevant to the topic at hand. When programming for very high performance, you usually need to consider the microarchitecture you are targeting.
Hmm. Most "super-high-performance" projects I've seen find they can get more bang for the buck by switching to a different microarchitecture (FPGA etc) or exploiting parallelism (buy ten computers), not so much optimizing the machine code.
Well, "attract more contributors if it is written in Go" I think that it isn't the point really. In fact, I think it's more easier if you're using C than or even C++. The question about C it's much error-prone language which would make development slow than using a more modern language with the C string and malloc()s pain. Not mentioned that it's cool a Go compiler written in Go and C# compiler written in C# :)
The PS3 uses both SNC and GCC (4.1). The developer has a choice of using SNC or GCC when generating code for the PPU -- the general purpose processor on the PS3 -- but only GCC is available when building code for the SPUs.
SNC is (was?) a great compiler. The code it generated was faster and significantly smaller than that generated by GCC, while being much faster at building to boot. Later versions of SNC added limited C++11 support as well.
