Show HN: Richard – A CNN written in C++ and Vulkan (no ML or math libs) (github.com)
This started out as a personal effort to learn more about machine learning. It's currently a CLI app where you give it a JSON file specifying your network architecture and hyperparameters and point it to your training data, then invoke it again in 'eval' mode with some data it's not seen before and it will try to classify each sample.
I don't see many other people using Vulkan for GPGPU, and there may be many good reasons for that, but I wanted to try something a bit different.
I've made every attempt to make the code very clean and readable and I've written up the math in documentation/math.pdf, so hopefully this is a useful learning resource for anyone interested in how neural nets work under the hood.
I'll be continuing to add new features over the coming months.
26 comments
[ 3.9 ms ] story [ 74.7 ms ] threadYou shouldn’t be so quick to accuse people of wrongdoing. It helps to try to understand where they’re coming from. In this case, evaluating multiple styles of implementation.
How is that not functionally the same?
PyTorch and TensorFlow have been developed and fine-tuned over many years by large teams of expert engineers. They incorporate numerous performance optimizations, including advanced memory management, kernel fusion, and auto-tuning of hyperparameters.
Richard, as a single-person educational project, simply cannot match this level of optimization. The scope and feature set of the projects are vastly different.
PyTorch and TensorFlow are comprehensive ecosystems that include not just the core computational graphs, but also high-level APIs, pre-trained models, data loading and augmentation pipelines, distributed training support, and more.
PyTorch and TensorFlow are often evaluated on large, complex models with millions of parameters, trained on massive datasets. Richard's examples, as shown in the README, use much smaller models and datasets.
I wish I could think of a good analogy off the top of my head...I've only gotten as far as testing the viability of carbon fiber tires for a highway-bound semi via someone's hobby pinewood derby car where they lovingly crafted novel carbon fiber tires from scratch. No one did anything wrong and both are achievements. It's just a category error.
I'm curious to know how close we can get to these frameworks by directly using Vulkan for GPGPU.
Especially as an indicator of the feasibility of rewriting core components like cuFFT and cuDNN in Vulkan.
It's like asking if anyone has benchmarked gnuCOBOL on OS/2 against LLVM ML IR.
You might be interested in llama.cpp's Vulkan backend_s_, that's more of an apples to apples comparison.
I'm definitely going to be looking at this. Hope you had fun making it.
how well does Vulcan api fit Neural Net primitives [ matmul / relu / backprop / tensor arrays ] ?
Also.. do you think the in-browser WebGPU api, the successor to webGL, is a good api for NN ?
There are no Vulkan constructs corresponding to those things. Vulkan lets you run compute shaders written in GLSL, HLSL, or any language for which there exists a compiler that outputs SPIR-V. Vulkan doesn’t have its own shader language. Deciding how to break the problem down into separate shader programs each with different workgroup sizes is a challenge.
And the end result performs very poorly compared with tensorflow. However, I haven’t yet put much effort into optimisation, so I expect there’s some easy performance gains to be made.
I don’t know anything about WebGL or WebGPU.
Context: I am interested in writing GPU-code as well (for ML too, but also for custom physic simulation). I also think, that compute-shaders are the way to go. But my intution says, that openCL would be simpler than vulcan.
Question: Have you considered alternatives to vulcan's compute shaders? (e.g. opencl instead of vulcan, or maybe some other ways entirely to run GPU code, such as rust-gpu)
> don't see many other people using Vulkan for GPGPU, and there may be many good reasons for that
I think the main of these reasons is nVidia’s contributions to the ecosystem. It’s much easier to call library functions implemented by cuDNN or cuBLAS first-party library, than it is to write and dispatch compute shaders to multiply these matrices.
However, for use cases when hardware costs are substantial compared to software development costs, using Vulkan or D3D can be a reasonable thing to do. nVidia is too greedy, in the EULA of their drivers they forbid to use GeForce GPUs in data centres. For people who need GPGPU on their servers, that paragraph of text sometimes makes nVidia hardware an order of magnitude more expensive than AMD hardware.
A big reason is that C++ for Vulkan (SPIR-V) isn't quite there, while CUDA does C, C++20 (minus modules currently), Fortran, Haskell, Java, C#, Julia, Python JITs, and anything else that might target PTX.
SPIR was a late response after Khronos realized the world wasn't willing to be stuck with C for GPGPU, and the tooling is still catching up to PTX.