>>57
I fucking asked you if Microsoft offered a POSIX threads layer and you implied "no" by going all out and saying that Microsoft uses POSIX threads internally, as if it were its native threads interface.
Well guess what? This UNIX subsystem for Windows provides a POSIX threads layer, and a UNIX System V layer, on top of the native OS facilities. The native OS API for threading still is NOT POSIX threads. It's Winthreads.
Microsoft does not use POSIX threads natively.
Furthermore, "Win32" has been a deprecated term since around 2003/2004. You now refer to it as simply Windows or "Win" for short. As in, the Windows API or "Win API."
http://msdn.microsoft.com/en-us/library/ee663300%28v=VS.85%29.aspx
Does it say "Win32" or "Win32 API" anywhere? No it does not. Personally, I don't use Windows as my primary OS, I use a free as freedom operating system. But I still have the decency and thoughtfulness to use the correct terminology, even for operating systems I somewhat despise.
>>58
also ooc.util.concurrent.gpgpu
C++AMP supports targeting GPU, FPGA, and other heterogenous computing devices as first class citizens in a unified programming model. For example, this is code that runs on the host CPU and partitions work on a buffer to be carried out on one or more GPU devices across one or more GPU wavefronts:
#include <stdlib.h>
#include <ppl.h>
int main(int argc, char** argv) {
const size_t buffer_size = 32 * 1024 * 1024;
int* buffer = malloc(buffer_size * sizeof(int));
parallel_for(0, buffer_size, [&] (size_t i) restrict(gpu) {
buffer[i] = (int)((i * 8) & 0x7FFF);
});
// ...
free(buffer);
return 0;
}
Note how I'm not using external source files for the GPU compute kernels. Notice how I don't have specify how to partition the work, or marshal data between the CPU and GPU(s)--it does it all for me automatically, although if I wish, I can use my own custom partitioner.
I'm looking at the occ source code and I don't see where this magical concurrency library of yours resides. So I can't determine the extent to which occ's gpgpu stuff goes, but I have a feeling it's probably just a wrapper around OpenCL host library APIs.
This looks like a community driven language with out much thought behind the library design, it's all just thrown together in an ad-hoc manner like every other community driven project. Why should I use this over an ISO/IEC standardized language and library extension with multiple vendor and FOSS community support?
>>59
It is. Did you follow the link? It's not
pthread_create(3), it was
CreateThread, you swine.