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

71–80 of 149 posts

Re: Python vs. Rust for Neural Networks

#71

Post by ImNotTheNSA »

skohan wrote: post #46
melling wrote: post #29

Earlier quoted context omitted.

I wouldn’t call Swift a tedious language. With type inference, immutability, etc, Swift is far from tedious: http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=stri... http://www.h4labs.com/dev/ios/swift_cookbook.html?topic=dict... It’s not quite as nice as Python but it’s an enjoyable language.

Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler which is giving me more correctness guarantees than Python is capable of. IMO Swift strikes the best balance between strictness and productivity of any language I've worked with.

> Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler

boy do I have a continent full of python developers to introduce you to... “python - by any means necessary” is their motto.

But in all seriousness, there are a lot of people (where I work) who started with python and have been daily driving it for so long that any other language is too tedious to get started with. Even if it means writing unreadable, hacky python, python still wins out for them.

I suspect there are a lot of similar people in data science.

Re: Python vs. Rust for Neural Networks

#72

Post by corndoge »

kuzehanka wrote: post #65
danielscrubs wrote: post #51

Earlier quoted context omitted.

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 w…

Good lord, hopefully latency isn't 2.5 seconds!

Re: Python vs. Rust for Neural Networks

#73

Post by ImNotTheNSA »

atoav wrote: post #55
gridlockd wrote: post #49

Earlier quoted context omitted.

Calling C (or C++) code from Python is not only totally doable, it's what all the popular libraries do. Furthermore, most ML stuff runs on the GPU, which also is C-like code. Hence, Rust offers no performance benefit that isn't already there. It really only offers safety and modern language features, at the cost of being tedious to use.

A bit snarky isn’t it? I explained why it isn’t irrational to use Rust — nowhere did I say you have to use Rust or that Rust is the only solution to that problem (which it obviously isn’t). Assuming the person opposite doesn’t know things is an extra unpleasant move on your part and I am not sure why you feel attacked by any of what I wrote. For the record, I also use C and I know that expert level C can beat naive R…

Sounds like you’re over reading into what was essentially a two-point comment... there was no snarkiness in that comment at all - just a statement that rust is not really offering much benefit for this circumstance. Yeesh... projection

Re: Python vs. Rust for Neural Networks

#74

Post by ImNotTheNSA »

sgillen wrote: post #2

>> Is rust suitable for data science workflows? >> 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. I'm not sure rust is really aiming to be something used for data sc…

> I'm not sure rust is really aiming to be something used for data science workflows

I’m not totally convinced rust knows what it’s aiming to be, other than replacing c++...

Re: Python vs. Rust for Neural Networks

#75

Post by llukas »

ImNotTheNSA wrote: post #66
skohan wrote: post #60

Earlier quoted context omitted.

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 versio…

Can you name breaking changes in between python 3.x versions?

Re: Python vs. Rust for Neural Networks

#76

Post by daenz »

tldr: The bottleneck is in the linear algebra libraries. Unoptimized Rust is 2x faster than unoptimized Python. Optimized Python is 2x faster than unoptimized Rust because it can vectorize matrix multiplications, but Rust can't.

My takeaway: stick to a GPU where everything is more parallel.

Re: Python vs. Rust for Neural Networks

#77

Post by gbrown »

kuzehanka wrote: post #65
danielscrubs wrote: post #51

Earlier quoted context omitted.

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 w…

Not everyone operates at that scale, and not every data science workload is DNN based

I agree with your general point, however, but the role I'd hope for with Rust is not optimizing the top level, but replacing the mountains of C++ with something safer and equally performant.

Re: Python vs. Rust for Neural Networks

#78

Post by mplanchard »

llukas wrote: post #75
ImNotTheNSA wrote: post #66

Earlier quoted context omitted.

> 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 versio…

Can you name breaking changes in between python 3.x versions?

Python 3.7 made async a reserved word, which broke the widely used celery package up until their most recent release.

Raising a StopIterationErorr in a generator in 3.7 now raises instead of ending the iteration, which broke several functions at my workplace.

3.8 has several further backwards incompatible changes incoming: https://docs.python.org/3.8/whatsnew/3.8.html#changes-in-pyt...

Re: Python vs. Rust for Neural Networks

#79

Post by sjwright »

corndoge wrote: post #72
kuzehanka wrote: post #65

Earlier quoted context omitted.

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 w…

Good lord, hopefully latency isn't 2.5 seconds!

I can’t even. How could you ever get 2500 msec on transit? That’s like circling the globe ten times.

Re: Python vs. Rust for Neural Networks

#80

Post by ddragon »

jimbokun wrote: post #68
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?

Definitely, since Julia has the same approach as Python of allowing quick and dirty solutions for data analysis/modelling, but with a much larger scope even when you don't have complete library support. In a few hours you can make a functional pytorch clone (and just using special GPU arrays you get it running on GPUs) with similar performance [1], and within a day (given a very good understanding of the language) a method that compiles the gradient directly from unmodified Julia code [2]. Plus native matlab-like goodness such as multi-dimensional arrays, so you don't have a separate library for fast operations and you can just use normal loops or whatever you want.

But while Julia targets Python fast and concise (while not compromising speed or power), it does not target the slower but more correct (though there is a culture of testing, which is quite important for math-oriented problems since the type system will not catch the most subtle and troublesome problems). There is space for a language to do exploratory/research work that can be quickly deployed in a fast iterative cycle and another for the new Spark/Flink or critical production areas that needs to take the extra effort (like self-driving cars), which could be Rust (or Scala, or Haskell, or Swift or stay with C++/Fortran).

[1] https://github.com/MikeInnes/diff-zoo

[2] http://blog.rogerluo.me/2019/07/27/yassad/

Post reply on HN