Live data from Hacker News

Tinygrad will be the next Linux and LLVM

twitter.com

31–39 of 39 posts

Re: Tinygrad will be the next Linux and LLVM

#31

no it won't, because while hitting ioctls in python is cute https://github.com/tinygrad/tinygrad/blob/master/extra/hip_g... it is definitely not shippable

Umm, why not? We wrote entire NVIDIA, AMD, and QCOM drivers in that style. https://github.com/tinygrad/tinygrad/blob/master/tinygrad/ru... https://github.com/tinygrad/tinygrad/blob/master/tinygrad/ru... https://github.com/tinygrad/tinygrad/blob/master/tinygrad/ru...

Because it's slow duh

Re: Tinygrad will be the next Linux and LLVM

#32

Earlier quoted context omitted.

Umm, why not? We wrote entire NVIDIA, AMD, and QCOM drivers in that style. https://github.com/tinygrad/tinygrad/blob/master/tinygrad/ru... https://github.com/tinygrad/tinygrad/blob/master/tinygrad/ru... https://github.com/tinygrad/tinygrad/blob/master/tinygrad/ru...

Because it's slow duh

This sounds like prejudice. Have you benchmarked it?

Re: Tinygrad will be the next Linux and LLVM

#33

Earlier quoted context omitted.

Because it's slow duh

This sounds like prejudice. Have you benchmarked it?

Yes I literally duplicated your approach for my driver stack last week and surprise surprise the FFI overhead into libc is too high.

Re: Tinygrad will be the next Linux and LLVM

#34

> Without CPUs, we can be freed from the tyranny of the halting problem. Can someone please explain to me what this even means in this context? Serious question.

Think of it as unwinding a program all the way until it's just a list of instructions. You can know exactly how long that program will take, and it will always take that same time.

Wouldn’t this also imply a lack of Turing completeness, and thus not be good for general purpose computing?

Re: Tinygrad will be the next Linux and LLVM

#36

Earlier quoted context omitted.

This sounds like prejudice. Have you benchmarked it?

Yes I literally duplicated your approach for my driver stack last week and surprise surprise the FFI overhead into libc is too high.

FFI? This isn't how GPUs work...they are MMIO (mostly)

Those drivers are faster than anything else when used to run fixed command queues (what neural network runs are)

Re: Tinygrad will be the next Linux and LLVM

#37
post #20

Earlier quoted context omitted.

> he wants to be able to express programs, and even an operating system, as a directed acyclic graph of logical binary operations, so that you can have consistent and deterministic runtime behavior. So how is this different from digital logic synthesis for CPLD/FPGA or chip design we have been doing over the last decades?

FPGAs are (prematurely) optimized for the wrong things, latency and utilization. The hardware is heterogeneous, and there isn't one standard chip. Plus they tend to be expensive. The idea is to be able to compile/run like you can now with your Von Neuman machine. FPGA compile runs can sometimes take days! And of course, chips take months and quite a bit of money for each try through the loop.

With FPGAs I can sample a hundred high precision ADCs in parallel and feed them through DSP, process 10Gb ethernet at line rate, etc with deterministic outcomes (necessary given safety and regulatory considerations). They integrate well with CPUs and other coprocessors - heterogeny isn't wrong. Plus training a NN model also takes days! To be fair not always, but for the above applications my build time was hours to many-hours anyway.

I grant the hardware is absurdly expensive at the high end, but I really don't think application wise the comparison is apples to apples.

Hotzs saying literally everything with an io pin or actuator will be driven solely by NN (driven by tinygrad) seems to me maybe 1/3 self promotion, 1/3 mania, some much smaller amount incisive at best.

Re: Tinygrad will be the next Linux and LLVM

#39
post #38

no it won't, because while hitting ioctls in python is cute https://github.com/tinygrad/tinygrad/blob/master/extra/hip_g... it is definitely not shippable

I can't say anything on the performance, but inline assembly in Python is crazy

It's not inline assembly it's just ioctl through ctypes via libc.
Post reply on HN