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

61–70 of 149 posts

Re: Python vs. Rust for Neural Networks

#61

Post by bigred100 »

tanilama wrote: post #12

Nobody writing NN in Python, they are just describing it. For NN or DL in general, the correctness doesn't really lie too much on the code quality level, like ownership Rust people love to talk about. It is more about Numeric stability under/overflow and such. Choice of programming language offers limited help here. I don't think Rust has a killer app for ML/DL community to offer as of now, the focus is vastly differ…

There’s plenty of issues beyond that. For example, many people aren’t gonna use a library that doesn’t have a good AS engine.

Re: Python vs. Rust for Neural Networks

#62

Post by archgoon »

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.

> I think it's quite impressive actually that someone can pick up Rust and manage to out-perform Numpy in their first project.

They didn't. At the end of the article they discuss this.

"In fact it’s worse than that. One of the exercises in the book is to rewrite the Python code to use vectorized matrix multiplication. In this approach the backpropagation for all of the samples in each mini-batch happens in a single set of vectorized matrix multiplication operations. This requires the ability to matrix multiplication between 3D and 2D arrays. Since each matrix multiplication operation happens using a larger amount of data than the non-vectorized case, OpenBLAS is able to more efficiently occupy CPU caches and registers, ultimately better using the available CPU resources on my laptop. The rewritten Python version ends up faster than the Rust version, again by a factor of two or so."

The original python code was written to be easily understood; not performant. Shifting more of the work to the libraries improved the performance.

Re: Python vs. Rust for Neural Networks

#63

Post by tammysmith »

I have been seeing some strange calls from my husband phone and yet am unable to locate his phone or even get the number that have been calling him. i was so lucky enough that i went online to hire a hacker who was gonna help me in tracking my husband phone and also giving me access to his phone. while i was searching i saw jamesscotthacker@gmail.com as the best and i hired him this hacker was so good that he delivered me with my husband call logs,whatsapp,facebook, pictures, deleted call logs, all calls where recorded from last year till date i also had access to his text messages and also deleted messages. all this i had access right on my phone just with a very cheap price you can also text him :1(323)4214332

Re: Python vs. Rust for Neural Networks

#64

Post by asdjlkadsjklads »

marmaduke wrote: post #16

Rust seems more suitable for implementing the next OpenBLAS. While Julia's single language mantra is great, as long as things like Python exist, there will be a need for C/C++/Rust.

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.

So we have two concerns, frontend and backend. For the backend Rust would perfectly acceptable, but i'm not sure it is fixing a safety issue/etc in other (C/etc) languages - aka, perhaps little value in the backend. For the frontend it only has value in some areas.

Regardless, i love Rust and would totally welcome any tooling to keep me in Rust. However i'm not an ML person hah.

Re: Python vs. Rust for Neural Networks

#65

Post by kuzehanka »

danielscrubs wrote: post #51
kuzehanka wrote: post #20

Earlier quoted context omitted.

I've had a few Rust lovers come and mention this project to me recently. None of them had any data science or ML experience. None of them knew that Python is just used to define the high level architecture. At the same time, comparatively tedious languages like Rust will never attract data science practitioners. They don't care about the kind of safety it brings, they don't care about improving performance in a compo…

I am a data scientist and I care. The time when you could just do proof of concepts or a PowerPoint presentation is long behind us. So now we have to start to take it into production, which means we get the exact same problems as SE has always had. Iff Rust helps us take it into production we will use it. But it’s a lot of land to cover to reach Pythons libraries so I’m not holding my breath. That said, Pythons perfo…

I must be missing something. Modern data science workloads involve fanning out data and code across dozens to hundreds of nodes.

The bottlenecks, in order, are: inter-node comms, gpu/compute, on-disk shuffling, serialisation, pipeline starvation, and finally the runtime.

Why worry about optimising the very top of the perf pyramid which will make the least difference? Why worry if you spent 1ms pushing data to numpy when that data just spent 2500ms on the wire? And why are you even pushing from python runtime to numpy instead of using arrow?

Re: Python vs. Rust for Neural Networks

#66

Post by ImNotTheNSA »

skohan wrote: post #60
xxxpupugo wrote: post #28

Earlier quoted context omitted.

CUDA is an important part of the story. I think the industry is moving to 'MLIR' solution (Yes, there is a Google project called exactly that, but I am referring to the general idea here), where the network is defined and trained in one place, then the weights are exported, delegated to optimized runtime to be executed. If such trend furthers down, then there will be very little reason to replace Python as the glue l…

Personally I hope for alternatives because I don't find Python that nice to work with compared to other languages. It's not awful, but I really miss having type and nullability errors detected by the compiler and reported to me with meaningful error messages. Also there are a few weird things with the Python workflow, like dealing with Python2 vs Python3, and generally having to run everything in the context of a vir…

> like dealing with Python2 vs Python3, and generally having to run everything in the context of a virtual environment, and the fact that it doesn't seem to really have a single "right way" to deal with dependency management.

Not to mention, this problem seems to be getting worse, not better. People are moving off of python 2.7, which was kind of the de-facto LTS release of python... leaving (currently) no LTS version of python and no clear path for the community to establish a new LTS version that the community will still support — there are so many releases with so many breaking changes in python 3 within the last few years that there is seemingly no consensus and no way to compromise.

> It's amazing how many great tools there are available in Python, but it does sometimes seem like it's an under-powered tool which has been hacked to serve bigger problems than it was intended for.

This is becoming more and more clear with every release of python IMO. The language is evolving too quickly for it to be used on large developments, but it’s still being used for that.

We have an entire test framework and libraries for high performance embedded systems level testing which is written entirely in python. The amount of high speed operations (timing tests, measurements, etc) is very obviously overwhelming for the intention of the language and libraries, yet the company keeps pushing ahead with this stuff. In order to mitigate the issue, we are developing more high speed embedded systems to offload the work from the test framework and report measurements to the framework. I think it’s quickly becoming extremely expensive and will only become more expensive — the framework is extremely “pythonic” to the point of being unreadable, using a number of hacks to break through the python interpreter. Jobs much better allocated to readable C++ libraries are being implemented in unreadable python spaghetti code with no clear architecture - just quick-and-dirty whatever-it-takes python.

I love python but I think it’s a quick-and-dirty language for a reason. What python does well cannot be beat by other languages (for example, prototyping), but I think it is often misused, since people can get something up and running quickly and cleanly in python, but it eventually has diminishing (and even negative) returns.

Re: Python vs. Rust for Neural Networks

#67

Post by [deleted] »

danielscrubs wrote: post #51
kuzehanka wrote: post #20

Earlier quoted context omitted.

I've had a few Rust lovers come and mention this project to me recently. None of them had any data science or ML experience. None of them knew that Python is just used to define the high level architecture. At the same time, comparatively tedious languages like Rust will never attract data science practitioners. They don't care about the kind of safety it brings, they don't care about improving performance in a compo…

I am a data scientist and I care. The time when you could just do proof of concepts or a PowerPoint presentation is long behind us. So now we have to start to take it into production, which means we get the exact same problems as SE has always had. Iff Rust helps us take it into production we will use it. But it’s a lot of land to cover to reach Pythons libraries so I’m not holding my breath. That said, Pythons perfo…

[deleted]

Re: Python vs. Rust for Neural Networks

#68

Post by jimbokun »

tanilama wrote: post #12

Nobody writing NN in Python, they are just describing it. For NN or DL in general, the correctness doesn't really lie too much on the code quality level, like ownership Rust people love to talk about. It is more about Numeric stability under/overflow and such. Choice of programming language offers limited help here. I don't think Rust has a killer app for ML/DL community to offer as of now, the focus is vastly differ…

Not a data scientist, but isn’t Julia better positioned to challenge Python for ML workflows than Rust?

Re: Python vs. Rust for Neural Networks

#69

Post by axelf4 »

dmos62 wrote: post #18
ageofwant wrote: post #9

This approach I think is missing the point. You will write highly optimized libraries in Rust, and then use those in Python. This is why Python has eaten the world. Not because its the best at any one thing, except bringing all those things together - at which it is unparalleled, and is unlikely to be surpassed anytime soon. numpy, scipy, pandas, tensorflow all those have very little actual Python code, its c++ and e…

I think you're being unnecessarily dismissive of discussions surrounding python's fitness, and I find your remark "that's exactly how it should be" confusing. Python is an ok interface language, in that it's script-like, dynamically typed and simple to comprehend. It's popular, which makes on-boarding efficient due to the sheer volume of tutorials online. And, it has built up a large ecosystem, because of the last tw…

I concur. Python is a shit language and it's only merit is filling a niche at the right time and place.

Re: Python vs. Rust for Neural Networks

#70

Post by lucasbonatto »

tldr "Right now I have to say that the answer is “not yet”. I’ll definitely reach for rust in the future when I need to write optimized low-level code with minimal dependencies. However using it as a full replacement for python or C++ will require a more stabilized and well-developed ecosystem of packages."
Post reply on HN