leaf

I tried to create a ML framework[0] that would work on both CUDA and OpenCL (and natively on the CPU) around 2015/2016, which included creating FFI wrappers for both CUDA and OpenCL. This is where my experience on the subject (and my contempt for NVIDIA) comes from. Me memory isn't perfect, but IIRC the situation was roughly the following: We were quite short on resources (both devtime and money), which meant that we had to choose our scope wisely. Optimally we would have implemented both CUDA and OpenCL 2.0, but we had to settle for OpenCL 1.2 (which offered reduced performance, but was "good enough" for inference). IIRC OpenCL 2.0 was very very similar in what capabilities it assumed and offered to the CUDA version at the time, and cards like the GTX Titan X had "compute capabilities" that supported features like shared virtual memory b

Though this is a snapshot from ~2015, I don't think anything has significantly changed since then: I developed a (more or less popular, though not in wide use) ML framework[0] back then. NVIDIA pretty quickly contacted us and offered to send a Titan X (top-of-the-line back then) our way. We also tried to make the framework work with OpenCL, but were severely limited in doing so. Mostly because Nvidia intentionally limits their GPUs to an older OpenCL version that has an uncompetitive featureset. They started doing that once they had a decent lead in the market over AMD. With that OpenCL was no longer vendor agnostic, but rather AMD-only, and you would always need to fully support both backends to support both vendors. Yes, Nvidia may produce the best GPUs right now and have great market and mindshare, but there is nothing "honest and dese

The first two are total bullshit metrics. Basically any Github metric in isolation doesn't mean much. Anecdotally, I once worked on a ML framework in Rust[0]. For at least a few months after release the metrics looked good on paper (Top 5 Rust project by stars at the time) and also had a few smaller contributors. Sadly next to no actual adoption and no healthy community around it that was able to pick it up after we had to stop maintenance. Downloads are about as bad. Just have one or a few users that have CI or deployment patterns that download the package a lot, and your numbers lost any meaning. [0]: https://github.com/autumnai/leaf

> I get it, you don't like seeing Open Source (MIT/ZLIB/Apache2) posted about. No you don't get it. I love hearing about such products - from the people who love using it so much that they feel the need to spread the word around. Submissions about project news are also great, because they can be separately up/downvoted, and don't ride on the coattails of trending submissions. That plus deceitful marketing tricks ("ranked #2 on Github" for a buzzword keyword you picked out, doesn't mean shit) is clearly spam in my book. > and I don't profit from it Is it not true that you run a VC-funded company that is behind gun, as you have claimed on other occasions? If it's VC-funded there probably is a profit goal in the foreseeable timeline. > ~8K developers in our community Stars on Github doesn't translate to community members, especially if they

> 1. Why are you're learning a language at the same time you're trying to launch an MVP? And a fairly involved language such as rust. Back when we decided to build Leaf[0] we were in a situation where we needed a language with the characteristics similar to the ones of C, C++, Rust (embeddable, no runtime, etc.). Before starting development on Leaf we didn't have any extensive experience in any of those languages, and I still think that Rust was the right choice for the project. I'd guess that the requirements of the MVP were similar. Since he also noted that it's his first time programming full-time, he had to learn _some_ language. Sure, it's not optimal to learn a core competency of your business while founding it, but I can also tell you from personal experience that sometimes that's still a better choice than the alternatives. > And

> - Neural network programs are usually not large and therefore do not need the type safety that Rust offers TensorFlow Fold [1] uses static type checking at model compilation time, presumably because it is meant to consume structured data, and needs to know what the opaque tensors it passes around are supposed to represent. I don't fully comprehend that type system, and debugging type errors was annoying (huge stacktrace full of passing type info around), but after I managed to imitate it well enough to hack up my own blocks, I didn't investigate further. A language-level type system like Rust's would probably have made things easier for me. EDIT: I just remembered that there's also Leaf [2], which claims to be among the faster neural network libraries (although their comparison is a bit outdated). Evidently there are people seriously pu

You mean on AWS/Azure? Because I have to develop a framework (https://github.com/autumnai/leaf) with it, and there is no way I am going to introduce any more complexity than necessary that early.

We would love to have them and compare their performance with recurrent layers of other frameworks[1]. There exists an issue for the implementation of recurrent layers in Leaf (#73)[2]. [1]: http://autumnai.com/deep-learning-benchmarks.html [2]: https://github.com/autumnai/leaf/issues/73

There is Leaf[1], the Hacker's Machine Learning Framework, which has GPU (CUDA, OpenCL) support for Machine Learning in Rust. James linked to it in the community section of his post, at the end. [1]: https://github.com/autumnai/leaf

We're actually growing a rather nice machine learning ecosystem on the Rust side, though obviously it's much less mature than the C/C++ solutions. See https://github.com/autumnai/leaf/blob/063ce978004b8bf4b7fc74... for an example.

We are developing the Rust Machine Intelligence Framework Leaf[1] for which we created the portable High-Performance Computation Framework Collenchyma [2], which abstracts over CUDA, OpenCL and commen host CPU. Although we are ready to bring Machine Learning to OpenCL supported devices, the OpenCL ecosystem lacks the fundamental kernels, tooling and library that already exist for the CUDA ecosystem (e.g. cuDNN[3]). But we looking forward to support OpenCL, maybe SPIR-V accelerates the process. [1]: https://github.com/autumnai/leaf [2]: https://github.com/autumnai/collenchyma [3]: https://developer.nvidia.com/cudnn