Don't get me wrong, I do appreciate the effort that went into this and fully intend to check it out sooner or later, but lately the appearance of new deep learning frameworks is beginning to trigger flashbacks to this: http://notinventedhe.re/on/2015-5-19
not in the same league, deep learning is a game changer, more people are realizing this, and as deep learning is relatively newly popular there is an initial explosion after which there a few mature favorites will emerge.
Nothing wrong with the names, it's a name. Sure being "dark" might be a poor fit for code that's open. It's already has other meanings too, but in the end, it's name.
Hmm, is this really nice? I doesn't look like something I'd just recommend to colleagues, with the religious symbols, names like Darknet and Yolo, Nightmare and black magic. Are they trying to stay away from the corporate market?
I use this a bit - the You Only Look Once implementation is good & fast (should be - redmon wrote the paper http://arxiv.org/abs/1506.02640) and it's all C. I don't think it's competing to overtake Torch/Caffe/Tensorflow as 'the' framework. What I find it good for is looking at the source code and trying to understand how something works in code (often not easy even after reading the papers) - easier than with the big frameworks. Also may be a good place to start for simpler target platforms e.g. embedded. Kudos to pjreddie.
TensorFlow is designed to be trained on distributed systems, but deployed on embedded systems; in fact, to me, this is the single greatest advantage TensorFlow has currently.
Please understand that proprietary software isn't an enemy that must be routed out, and that developing good software (using the right tools for the job) is usually more important (to the developer) than developing software with no proprietary dependencies.
The companies that give away proprietary libraries that developers come to depend on essentially do act as an "enemy within" - you never know when they'll decide that their original reason to give away the library didn't give them enough profits and they are going start charging for future licenses, change the interface, drop support or whatever. Didn't Twitter pull the plug on a company using one of its private interfaces just a few days ago (slightly different but not entirely different).
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.
I would say that there are very good reasons for hesitating when thinking about adopting software that is reliant on proprietary software. Like vendor lock in.
This project however appears to support OpenCL which is not proprietary.
OpenCl targets nVidia GPUs also, at least according to the documentation.
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.
> The main problem is OpenCL seems an order of magnitude more complex than CUDA.
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.
Depends what you want to gain? You want to do scientific computing? Interested in mobile platforms? Or just curious about GPUs?
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.
CUDA is designed to help NVidia to sell more chips so I don't see it as a big risk.
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.
> CUDA is designed to help NVidia to sell more chips so I don't see it as a big risk.
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?
This is cool. The documentation is very entertaining, although not something you'd show to your boss. Looks like it implements a lot more than just neural networks.
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.
40 comments
[ 3.0 ms ] story [ 74.4 ms ] threadhttps://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?
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?
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.