Darknet: C and CUDA open source neural network framework
pjreddie.com
pjreddie.com
https://en.m.wikipedia.org/wiki/Darknet
And why CUDA, and not OpenCL?
My bold guess is because there are more training machines run on Nviada GPUs as opposed to AMD's.
Likely not so bold. AMD GPUs are good, but a quite a bit more pain to program compared to NVIDIA with CUDA (OpenCL on NVIDIA is more or less useless).
As for why CUDA, probably because that is what 90-something% of the ML community uses for this. Network affect.
The library appears to be using cuBLAS; what's the OpenCL alternative with comparable run-time performance and functionality?
Shameless plug: For a minimal neural network implementation in ANSI C, check out: https://github.com/codeplea/genann Sometimes lack of features is a feature.
Cuda looks several orders of magnitude easier than OpenCl but Cuda versus opencl is just not simply a "best tool" question for an ongoing project. There's every reason to wish to remove proprietary libraries whether that's possible or not.
This project however appears to support OpenCL which is not proprietary.
The main problem is OpenCL seems an order of magnitude more complex than CUDA. To be honest, Cuda seems semi-portable just because (according to documentation and tutorials I've read) you do little more than allocate memory, tag functions, write loops and the compiler figures out the rest. OpenCL seems to demand everything be specified in gruesome detail whether in the c or the c++ version. Also, the latest pdf-pamphlet of the Khronos Group on opencl 1.2 just says they're "exploring" an open source implementation of the spec, which doesn't encourage one to imagine the spec as available.
Edit: Researching this, it seems that the CUDA compiler actually has been integrated into clang/llvm. An open spec with open compiler seems as open as one can get with software - it only targets NVidia but you can just complain Linux was proprietary when it originally only targeted Intel.
https://research.nvidia.com/news/nvidia-contributes-cuda-com...
Do you have any experience to back that up with? I've worked with both and I know that there are areas where your "order of magnitude" (which BTW I'd like to see on paper, quantified) does hold up, e.g. dev tools, but in general your claim is simply false.
> To be honest, Cuda seems semi-portable just because (according to documentation and tutorials I've read) you do little more than allocate memory, tag functions, write loops and the compiler figures out the rest.
Nonsense, you're likely confusing OpenACC with CUDA, the CUDA runtime API is in many cases considerably more simple than OpenCL, but it requires a compiler, and frankly often times is screams rushed design/implementation. In contrast, the CUDA driver API is quite similar to OpenCL.
...and BTW OpenACC is "open" only on paper and in fact it is a very divisive move that has created conflicts, polarized the community, and undermined collaboration between multiple parties (in particular with the OpenMP proponents).
> Also, the latest pdf-pamphlet of the Khronos Group on opencl 1.2 just says they're "exploring" an open source implementation of the spec, which doesn't encourage one to imagine the spec as available.
The latest spec is 2.0 FYI; can you explain my how on earth does one's imagination go astray so badly to believe that just because there is no reference implementation one would consider the spec "not available". Don't get me started with the examples of standards that exist without an official reference implementation.
> Edit: Researching this, it seems that the CUDA compiler actually has been integrated into clang/llvm. An open spec with open compiler seems as open as one can get with software - it only targets NVidia but you can just complain Linux was proprietary when it originally only targeted Intel.
BS. Show me the "open spec of CUDA". Even if one did exist, good luck trying to influence the design of it if you're not an big oil company, Google, Audi or GM. Also, try to use the CUDA name without having to pay a ton of money. And you seem to forget that the "open compiler" does not actually generate byte-code (that's done by the propritary JIT compiler) and even if did, you still nee NVIDIA's proprietary driver to run it.
Without knowing the answer to that, I won't attempt to go into more details, but will give two examples: * If you want to have transferable knowledge (e.g. to be able to jump into mobile development on ARM), choose OpenCL. * If you're curious to learn and try stuff out mostly to get a taste of GPU computing, consider using CUDA (as it has better dev tools), but if you find it fun/useful, do consider switching to OpenCL.
While it is all well and good to hold certain beliefs [people shouldn't eat meat, use cars, whatever], it also a valid to believe there is nothing wrong with using proprietary, for profit software. Personally I believe that exchanging money for something of value is fine.
Don't you see it as a risk to marry your project to a proprietary API of a company that actively and intentionally cripples their implementation of the standard for no other apparent reason but to hold back progress of OpenCL and essentially ensure vendor lock-in and create a disadvantageous situation for competitors relying on the aforementioned standards?