3 ms·
Very nice! I look forward to trying this out. There a few issues which come to mid though: 1. How do these benchmark results compare to writing x64_64 impleme
by einpoklum 6y ago
Very nice! I look forward to trying this out.
There a few issues which come to mid though:
1. How do these benchmark results compare to writing x64_64 implementations directly? That is, is it enough to reach OpenCL-level performance?
2. What about if I want to use both a CPU and and a GPU? It seems that would not be supported, as this library produces a `libcuda.so`.
3. What about AMD chips?
4. The README says:
> Authors of CUDA benchmarks used CUDA functions atomicInc
> and atomicDec which have direct hardware support on NVIDIA
> cards, but no hardware support on Intel cards. They have
> to be emulated in software, which limits performance
is there really no support, not even in the near future, for atomic increment on Intel chips?
5. This is all written in Rust. It's a bit fishy to me for a C library to be implemented in Rust, though maybe I'm just a little prejudiced.
6. Where is the documentation of the semantic differences between proper CUDA and ZLUDA? e.g. - what do streams do? How do events work? etc.
- johnnycerberus 6y agoTo be fair I have the same feeling about Rust. C++ is the language positioned for high performance computing, almost everything that screams HPC is in C++. We already have problems in our company modifying some old Fortran libraries that are called from C++ and in the future God knows what Rust or Zig training we will require for basically no upside for HPC. But if safety would be my concern, I would totally look towards Rust. Or hopefully, Julia will save the day.