5 ms·
I might have written too much about the languages I intended just to bring forward as example. D is not high-performance (I clarified that in the post) the sam
by c0de517e 12y ago
I might have written too much about the languages I intended just to bring forward as example.
D is not high-performance (I clarified that in the post) the same way as C and C++ are not. They are not meant for HPC, they are meant to be "systems" languages.
The difference between the two is that HPC is usually about parallelism and has always been. Instruction level (SIMD and GPUs), threads, clusters and so on. D is a bit better than C++ as it at least standardizes SIMD a bit, but still IMHO it doesn't qualify as HPC.
C++ adopted threads only in 11, doesn't have SIMD, doesn't know about GPUs, it got "restrict" only in 11 as well and so on and on. It's clearly not for HPC.
- adamnemecek 12y agoSo what do you consider a HPC language? > C++ adopted threads only in 11 Fair. > doesn't know about GPUs, Is there a general purpose language that has GPU support out of the box? > it got "restrict" only in 11 as well AFAIK, restrict is still not part of the standard, despite compilers implementing it.
- easytiger 12y agoI still maintain he's talking nonsense. For a start most traditional HPC is done not via threads but via IPC. He's now not talking about languages but their libraries / platform offerings. Just because it is in the c++ stdlib doesn't mean you couldn't do it. Indeed the only reason it has been integrated into the standard platform the language offers is because it was proven over many many years as an external library.
- adamnemecek 12y agoI agree. As for the threads thing, I agree as well but there is a school of thought that believes that threads should be part of the language http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
- c0de517e 12y agoTo both comments - it's not JUST because the lack of threads, don't take an example as the entire extent of the critique. It lacks threads. It lacks SIMD. It lacks control over pointer aliasing (restrict), something that FORTRAN did right decades before C++ and C is doing today but C++ still lacks, and it's quite fundamental to write high performance kernels. It does -NOTHING- of the things that are needed for performance, all these things had to be added by custom compiler extensions because it's a popular language and we have very, very good compilers, but the language standard itself lacks in a lot of ways for HPC
- adamnemecek 12y agoSo what do you consider an HPC language? Fortran?
- c0de517e 12y agoFortan is -undoubtedly- thought as a HPC. That doesn't mean it's great or I would use it today, but yes, without a doubt it is one of such languages. That's not to say that if today I had to write, as I do, a tight CPU kernel, I would not chose C or C++, these have the best compilers and tools and are more general languages. But C++ was never designed to aid stuff like numerical computation, never. It was designed to be zero-overhead on top of C if you didn't use any feature with overhead. That means that it can go all the way down to C performance, and C is considered almost as a portable assembly, so it's quite low-level. Low-level and high performance are not entirely the same thing! In fact you can easily, easily outperform -standard- C++ in many interpreted languages that support vector operations or GPU offloading, for example matlab. If you want a c-like cpu hpc language for tight numerical kernels to integrate with c functions, look for Intel's ISPC
- c0de517e 12y agoThe lack of GPU support is indeed widespread and really quite forgivable today. Threads, SIMD and restrict are not. And you're right about C++11, my bad. It's funny how C is actually pioneering a lot of the changes actually required for performance while C++ thinks about standardizing Cairo for 2d graphics...