One of the main reasons (the other being personal learning) people write these minimal dependency free implementations is exactly for speedup, so it's a fair question. If the author has other motivations that's fine, but it's very interesting to see how fast you can get once you strip out some of the overhead of the common frameworks.

The performance comparison would be interesting to me.

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.

The comparison really, seriously, doesn't make any sense.

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.

You can implement an idiomatic CNN in PyTorch or TF and compare their performance to this implementation. It's a perfectly reasonable comparison.

People make CNN’s in both. There’s classes for them, too. It’s reasonable to ask how a readable implementation compares to an optimized one.

You 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.

PyTorch and Tensorflow are arguably the two most practical neural network frameworks in the profession.

They both let you build and train a model of nn layers. Tensorflow via keras and pytorch via torch.nn.Module.

How is that not functionally the same?

You won't learn anything, and attemping to derive any info is likely to be extremely unfair to Vulkan, which was the stated purpose of said comparison.

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 do implementations from scratch/paper myself. I know the value of this. I do my own personal research using graph neural networks recreationally. I was replying to someone who thought the two ubiquitous libraries people use for almost identical functionality were somehow different.

Not sure what you mean, maybe they weren't either.