Live data from Hacker News

Deep Neural Networks from Scratch in Zig

monadmonkey.com

11–20 of 34 posts

Re: Deep Neural Networks from Scratch in Zig

#11
This is interesting, thanks. I know this is just a demo, but I'm convinced we're going to see a swing back to simple, purpose written NNs for many simple applications, when the alternative is bringing in a couple GB of python and cuda libraries, which is serious overkill for something on the scale of MNIST (which many real problems are).

That said, I'm curious about how well the compiler can optimize matrix operations, in Zig or other, say C or Rust, and when it's worth linking in BLAS or mkl some other library. I wonder if there is a sweet spot where it's worth doing.

Re: Deep Neural Networks from Scratch in Zig

#12

> I would guess the constant memory allocation and frees in the training loop are the bottleneck No, the bottleneck would be not utilizing the idling GPU.

Using the CPU with quantized weights on GPT models makes sense, an example is llama.cpp, that’s because these models are constrained by memory bandwidth and not compute (low arithmetic density)

https://github.com/ggerganov/llama.cpp

Re: Deep Neural Networks from Scratch in Zig

#14

It would be cool too see a port of llama.cpp and ggml to Zig https://github.com/ggerganov/llama.cpp https://github.com/ggerganov/ggml

I wonder how much of the heavy lifting on GGML can be done with `zig translate-c ggml.c`

GGML seems to be just one gigantic 10K LOC C file anyways...

Re: Deep Neural Networks from Scratch in Zig

#15

> I would guess the constant memory allocation and frees in the training loop are the bottleneck No, the bottleneck would be not utilizing the idling GPU.

You can go 100x faster using SIMD on the CPU, instead of doing the linear algebra by hand, then another order of magnitude or two on the GPU.

Re: Deep Neural Networks from Scratch in Zig

#16
I've been working on mix of ML performance and abstraction for a while and this is a breath of fresh air. Zig is truly a fascinating language, and the semantics revealed in this post are surprisingly powerful.

"By hard coding the forward and backward methods at comptime we have some more comfort with the general correctness and expected errors we would receive if we passed in incorrectly shaped data at runtime."

This solves the issues of shape checking incredibly cleanly. Python libraries have been struggling with this for a decade. It seems like you could also extending comptime usage to also calculate allocations ahead of time.

Honestly, this whole thing makes me want to invest quite a bit of time into using Zig. Great post!

Re: Deep Neural Networks from Scratch in Zig

#17
Machine learning feels a lot like cpu fabrication in that a homegrown solution is almost certainly going to be inferior to just taking whats on the market and configuring it to fit your needs. If you aren't going to specialize in this field, is there a point in learning how to roll your own ML anymore?

Re: Deep Neural Networks from Scratch in Zig

#18

> I would guess the constant memory allocation and frees in the training loop are the bottleneck No, the bottleneck would be not utilizing the idling GPU.

Pls see the post from version_five nearby: https://news.ycombinator.com/item?id=35699260

> simple, purpose written NNs for many simple applications [... as opposed to] python and cuda libraries

Re: Deep Neural Networks from Scratch in Zig

#20

Lacking a Linear Algebra / Tensor library is what kills performance for DNN. For example, this kind of element by element manipulation must be avoided: while (i What are the options for vector / matrix / tensor operations in zig?

1. The compiler will vectorize simple operations like that pretty well.

2. Zig has built-in @Vector types that are fixed-size data types designed to compile down to things like SIMD as efficiently as possible given that you might be asking it to do 16x operations on a CPU only supporting 8x width SIMD. You'd often write your high-level code as a runtime-known iteration count over those comptime-known vector widths.

2a. Inline assembly or inspecting the architecture before choosing the @Vector width are both options, so you can write your high-level code with that information in mine if necessary (e.g., to make bolt vector quantization work well in Zig I'm pretty sure you need to inline-assembly one of the swizzling operations).

3. You can always link to LAPACK and friends. Zig has a great c interface.

4. Matrix/tensor ops aren't built-in. That doesn't matter for a lot of what this demo shows since it'll be RAM/cache bandwidth bound, but you'd definitely need to link in or hand-code inner product routines to have better asymptotics and cache friendliness if you were doing too many large matrix multiplies.

5. Wrapping any of the above into a library would be pretty easy. That sort of code is easy to write, so I haven't looked to see what other people have made in that space, but I'm sure there's something.

Post reply on HN