Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python vs. Rust for Neural Networks

ngoldbaum.github.io

Post reply on HN
Print view View original

131–140 of 149 posts

Re: Python vs. Rust for Neural Networks

#131

Post by MiroF »

lreichold wrote: post #127
MiroF wrote: post #101

Earlier quoted context omitted.

The tooling for Swift 4 TF is not anywhere near satisfactory. I can't even seem to get it on my computer without installing XCode (and that's on an apple computer) I should be able to pull a docker image and have s4tf immediately at my fingertips

Not local, but you can start using S4TF immediately via Google Colab. https://colab.research.google.com/github/tensorflow/swift/bl...

if I’m going to be developing, I need a compiler, not a REPL or a notebook. Haven’t managed to find that

Re: Python vs. Rust for Neural Networks

#132

Post by pohl »

kahnjw wrote: post #108
danielscrubs wrote: post #88

Earlier quoted context omitted.

Every small thing counts when you have big data which is exactly why you need performance everywhere, if Rust can help with that I don’t mind switching my team to that. The problem are usually when you do novel feature engineering not the actual model training. But I was a C++ dev before checking the assembly for performance optimization so I guess I have more wiggle room to see when things are not up to snuff. If I…

This is just not true. The python runtime is not the bottleneck. DL frameworks are DSLs written on top of piles of highly optimized C++ code that is executed as independently from the python runtime as possible. Optimizing the python or swapping it out for some other language is not going to buy you anything except a ton of work. We can argue about using rust to implement the lower level ops instead of c++. That migh…

The python runtime is not the bottleneck.

This smells like an overgeneralization. Often things that aren’t a bottleneck in the context of the problems you’ve faced might at least be an unacceptable cost in the context of the 16.6 ms budget someone else is working within.

Re: Python vs. Rust for Neural Networks

#133

Post by ldng »

kuzehanka wrote: post #105
danielscrubs wrote: post #88

Earlier quoted context omitted.

Every small thing counts when you have big data which is exactly why you need performance everywhere, if Rust can help with that I don’t mind switching my team to that. The problem are usually when you do novel feature engineering not the actual model training. But I was a C++ dev before checking the assembly for performance optimization so I guess I have more wiggle room to see when things are not up to snuff. If I…

Novel feature engineering? Like this? https://towardsdatascience.com/python-performance-and-gpus-1...

I see a graph on ... logarithmic scale ? No unit ? I don't know what that benchmark means.

Re: Python vs. Rust for Neural Networks

#134

Post by skohan »

MiroF wrote: post #131
lreichold wrote: post #127

Earlier quoted context omitted.

Not local, but you can start using S4TF immediately via Google Colab. https://colab.research.google.com/github/tensorflow/swift/bl...

if I’m going to be developing, I need a compiler, not a REPL or a notebook. Haven’t managed to find that

The Dockerfile in the swift-jupyter repo is a superset of what you need. You could remove the lines dealing with jupyter and you'd be left with a Docker container with the s4tf compiler.

https://github.com/google/swift-jupyter/blob/master/docker/D...

Re: Python vs. Rust for Neural Networks

#135

Post by vbarrielle »

ddragon wrote: post #111
MiroF wrote: post #95

Earlier quoted context omitted.

Python should and will be replaced, but not at all for any of the reasons mentioned in this thread. A good ML language is going to need smart and static typing. I am so tired of having to run a whole network just to figure out that there's a dimension mismatch because I forgot to take a transpose somewhere - there is essentially no reason that tensor shapes can't just be inferred and these errors caught pre-runtime.

Do you have an example of a tensor library that keep track of shapes and detect mismatches at compile time? I had the impression that even in static languages having tensors with the exact shape as a parameter would stress the compiler, forcing it to compile many versions of every function for every possible size combination, and the output of a function could very well have a non deterministic or multiple possible s…

There's a research language that supports compile-time checking of array dimensions: futhark [1]. It's an interesting language that compiles to CUDA or OpenCL. However it's probably not ready for production (not sure if there's even good linear algebra implementations yet). It does feature interesting optimizations to account for the possible size ranges of the arrays (the development blog is very instructive in that respect).

[1] https://futhark-lang.org/

Re: Python vs. Rust for Neural Networks

#136

Post by marmaduke »

MiroF wrote: post #104
asdjlkadsjklads wrote: post #64

Earlier quoted context omitted.

Yea, this whole discussion feels weird to me. Different use cases. I love Rust (and dislike Py lol), but from everything i hear a highly dynamic frontend (like Py) has little downsides to authors of ML/etc. All of the hotpaths are in other already because Python is so slow. The only downside i've seen is sometimes the programmer will want more safety. In such a scenario Rust for the "frontend" would be very useful. S…

A dynamic language can be super frustrating to develop with because you have to keep tensor dimensions memorized in your head or in comments

How is à statically typed language going to help with tensor dimensions?

Re: Python vs. Rust for Neural Networks

#137

Post by timClicks »

MiroF wrote: post #106
timClicks wrote: post #43

I think it's quite impressive actually that someone can pick up Rust and manage to out-perform Numpy in their first project. BLAS implementations are decades-long exercises in optimization. In my own experience, Rust has been excellent for the more boring side of data science - churning through TBs of input data.

This is a common phenomenon (as anyone who has tried to rewrite the standard library buffer cache can tell you) - the reason is that these algorithms are oftentimes optimized to perform decently on the very very worst cases which means that they'll be slightly slower overall

Ah, that's a thought that I hadn't considered. Avoiding pathological worst case behavior does sound like a reasonable thing for a well-used library to do.

Re: Python vs. Rust for Neural Networks

#138

Post by MiroF »

skohan wrote: post #134
MiroF wrote: post #131

Earlier quoted context omitted.

if I’m going to be developing, I need a compiler, not a REPL or a notebook. Haven’t managed to find that

The Dockerfile in the swift-jupyter repo is a superset of what you need. You could remove the lines dealing with jupyter and you'd be left with a Docker container with the s4tf compiler. https://github.com/google/swift-jupyter/blob/master/docker/D...

Thank you - I will give that a try!

Re: Python vs. Rust for Neural Networks

#140

Post by ddragon »

vbarrielle wrote: post #135
ddragon wrote: post #111

Earlier quoted context omitted.

Do you have an example of a tensor library that keep track of shapes and detect mismatches at compile time? I had the impression that even in static languages having tensors with the exact shape as a parameter would stress the compiler, forcing it to compile many versions of every function for every possible size combination, and the output of a function could very well have a non deterministic or multiple possible s…

There's a research language that supports compile-time checking of array dimensions: futhark [1]. It's an interesting language that compiles to CUDA or OpenCL. However it's probably not ready for production (not sure if there's even good linear algebra implementations yet). It does feature interesting optimizations to account for the possible size ranges of the arrays (the development blog is very instructive in that…

Thanks, I'll look into it.

Julia for example does have an array library that does compile-time shape inference (StaticArrays), but it cannot scale for large arrays (over 100 elements) exactly because it gets too hard for the compiler to keep track, I'm definitely curious about possible solutions.

Post reply on HN