Live data from Hacker News

Python vs. Rust for Neural Networks

ngoldbaum.github.io

51–60 of 149 posts

Re: Python vs. Rust for Neural Networks

#51

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…

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 performance is slow even when shuffling to Numpy.

Re: Python vs. Rust for Neural Networks

#53

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…

[deleted]

Re: Python vs. Rust for Neural Networks

#54

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…

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'm by no means a specialized data scientist, but I've done some (very surface-level) text crunching with both the TF/Numpy stack and Rust.

To me, the nice thing about switching to Rust for that kind of stuff was that it dramatically raised the bar of what I could do before reaching for those hyper-optimized descriptive libraries.

Want to calculate the levenshtein distances of the cross product of 100k strings? Sure, just load it into a Vec, find a levenshtein library on crates.io, and it'll probably be fast enough.

Could it be done in Python? Sure, but with Rust I didn't have to think about how to do it in a viable amount of time. Does that mean that Rust is going to take over the DS world? Probably not in the short term, Rust currently can't compete with Python's DS ecosystem.

But if I'm doing something that I don't know will fit into an existing Python mold (that I know about) then I'll strongly consider using it.

Re: Python vs. Rust for Neural Networks

#55
post #21

Earlier quoted context omitted.

As somebody who programs in both Python and Rust (and likes both languages) I think Rust's place would be parts of the code that have to be fast, and that you want to get right. Calling Python code from Rust or Rust from Python is totally doable, and there is in my view no reason why you shouldn't use both in the use cases that suit them. And the speed part is serious. Some guy once asked for the fastest tokenizer in…

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 Rust at any time (expert level Rust should allow you to do literally the same thing you do in C, just wrapped in a “I can handle this”-unsafe block.

Your response tells more about yourself than it does about the subject at hand. Rust isn’t stealing your cookies and nor am I.

Re: Python vs. Rust for Neural Networks

#56

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'm by no means a specialized data scientist, but I've done some (very surface-level) text crunching with both the TF/Numpy stack and Rust. To me, the nice thing about switching to Rust for that kind of stuff was that it dramatically raised the bar of what I could do before reaching for those hyper-optimized descriptive libraries. Want to calculate the levenshtein distances of the cross product of 100k strings? Sure,…

> But if I'm doing something that I don't know will fit into an existing Python mold (that I know about) then I'll strongly consider using it.

The thing is, for anything performance intensive and scientific, you're almost guaranteed to find a Python binding.

It has all these bindings because scientists are almost always writing either Python, C++, or Fortran (with a smattering of R or Octave on the side).

Want to do linear algebra? NumPy is always there, otherwise you can go lower level: https://docs.scipy.org/doc/scipy/reference/linalg.blas.html

Old-school optimization? https://www.roguewave.com/sites/rw/files/attachments/PyIMSLS...

Computer vision? https://pypi.org/project/opencv-python/

In fact, I'd basically argue against using most language-native implementations of algorithms where performance is at stake, because most implementations don't have all the algorithmic optimizations.

Re: Python vs. Rust for Neural Networks

#57
post #44

Earlier quoted context omitted.

Numerical stability sounds like floating point artifacts are a problem, could a specification/verification language with more exact arithmetic semantics help?

Its not about floating point artifacts. Especially as full IEEE floats are completely deterministic and have exact semantics. It’s something more fundamental. Similar issues happens elsewhere in numerical computation. See https://en.m.wikipedia.org/wiki/Numerical_stability

I’d phrase it as, “It’s not _just_ about floating point artefacts.” Rounding is a source of error inherent to storing arbitrary precision numbers in finite space, floating point numbers are just a very common way to do that. Numerical stability is basically about information loss, typically when adding a very small number to a very large number causing information about the small number to be rounded out.

It happens with ints too, but it is so much more obvious than with floats that no one would be surprised.

Repeating i += 0.1 a million times will produce the same value as i += 0.2 a million times if i is an int, since the rounding will make both effectively i += 0.

Re: Python vs. Rust for Neural Networks

#58
post #18

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…

Yes exactly: Python is dominant at the moment, because it has a head start, but it's not because Python is uniquely suited to the problem by any means.

This is the same logic one might have used to conclude that the LAMP stack would be dominant forever in web development if you took a snapshot of the world in 2004.

Re: Python vs. Rust for Neural Networks

#59
"The first step here was to figure out how to load the data. That ended up being fiddly enough that I decided to break that off into its own post." this is exactly why we have R and pandas!! Julia is doing an increasingly excellent job of it as well.

Re: Python vs. Rust for Neural Networks

#60

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…

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 virtual environment, and the fact that it doesn't seem to really have a single "right way" to deal with dependency management. It's a bit like the story with imports in Javascript: those problems were never really solved, and the popular solutions are just sort of bolted on to the language.

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.

Post reply on HN