5 ms·

120ms to 30ms: Python to Rust

37 points by 0xedb 2y ago

gumby 2y ago
What I get from this is that the python interpreter is better than I would have guessed.
- dagss 2y ago
  Same, until I read "C library accessed through Python"
  - atiedebee 2y ago
    Well, depending on how much python is written around the C library, you'll get a lot of overhead. There's also the fact that having everything be compiled simultaneously results in the optimizer being able to get a lot more work done.
- constantcrying 2y ago
  If you are using python as a way to more easily address a C library, it works very well and can be reasonably fast. The moment you are using "pure" python on large datasets the whole thing starts to crumble.
galkk 2y ago
Almost always when I start prototyping something in python, I wish that I stopped half-way where I am now and switched to something else. Most recent example - converting huge amount of xml files to parquet. I started very fast with python + pyarrow, but when I realized that parallelizing execution would help enormously, I hit GIL or picking/unpickling/multiprocessing costs. It did work in python, in the end, but I feel that writing that in Rust/C# (even if I don't know Rust besides tutorials) in the end would be much more performant.
- deleted 2y ago
  [deleted]
- dmw_ng 2y ago
  > converting huge amount of xml files > pickling Sounds like if this is the tooling and the task at hand, about the most complex things that should be passing through the pickler are partitioned lists of filenames rather than raw data. E.g. you can have each partition generate a parquet for combining in a final step (pyarrow.concat_tables() looks useful), or if it were some other format you were working with, potentially sending flat arrays back to the parent process as giant bytestrings or similar This is not to say the limitations don't suck, just that very often there are simple approaches to avoid most of the pain
  - deleted 2y ago
    [deleted]
- alberth 2y ago
  You can quickly build prototypes with LuaJIT and it’s also quite performant. It’s worth giving it a try if you haven’t before.
- nomel 2y ago
  GIL has been relieved in Python 3.12: https://realpython.com/python312-subinterpreters/ https://realpython.com/python312-subinterpreters/ But, I have the same sentiment. Although, I find writing quick C++ extensions (swig is incredible) is a good balance.
- jmakov 2y ago
  ray.io
- _niki_s_ 2y ago
  Looks like Mojo will fix that
  - itishappy 2y ago
    Right, by switching languages.
jti107 2y ago
use the right tool for the right job. your software requirements and design document should drive the language and the tools you use.
- fullstackchris 2y ago
  what i was thinking as well... i love these performance improvement posts but at the same time had to think what kind of choice was it to originally reach for python in the first place if the task was to do a lot of heavy concurrent task management???
bin_bash 2y ago
I enjoy both languages quite a bit, but a 4x improvement is more of a testament to python than it is to rust imo!
- nolroz 2y ago
  How do you mean? Would you expect it to be much slower?
  - flohofwoe 2y ago
    Yeah, IME Python can be about 100x slower than a native solution. The original solution was a combination of a C library and Python wrapper code, so 4x makes sense for eliminating the Python part.
pjmlp 2y ago
Could be renamed as 120ms to 30ms: Python to "AOT compiled language".
Havoc 2y ago
Noticed similar scale of improvement when testing the two on cloud functions. Just comes down to whether you need speed of building it or speed of program
Talinx 2y ago
That is a lot of text for not determining why the new solution is faster. The only relevant part: > Before our migration, the old pipeline utilized a C library accessed through a Python service, which buffered and bundled data. This was really the critical aspect that was causing our latency. How much speed up would there have been if they moved to a Rust wrapper around the same C library? Using something other than Python is almost always going to be faster. This Reddit post does not give any insights into which aspects of Python lead to small/large performance hits. They show that it was the right solution for them with ample documentation which is great, but they don't provide any generalizable information.
gregors 2y ago
Am I the only one thinking "why wasn't it better?" Guess I'm never satisfied

37 points by 0xedb 2y ago

gumby 2y ago

What I get from this is that the python interpreter is better than I would have guessed.

dagss 2y ago
Same, until I read "C library accessed through Python"
- atiedebee 2y ago
  Well, depending on how much python is written around the C library, you'll get a lot of overhead. There's also the fact that having everything be compiled simultaneously results in the optimizer being able to get a lot more work done.
constantcrying 2y ago
If you are using python as a way to more easily address a C library, it works very well and can be reasonably fast. The moment you are using "pure" python on large datasets the whole thing starts to crumble.

galkk 2y ago

Almost always when I start prototyping something in python, I wish that I stopped half-way where I am now and switched to something else. Most recent example - converting huge amount of xml files to parquet. I started very fast with python + pyarrow, but when I realized that parallelizing execution would help enormously, I hit GIL or picking/unpickling/multiprocessing costs. It did work in python, in the end, but I feel that writing that in Rust/C# (even if I don't know Rust besides tutorials) in the end would be much more performant.

deleted 2y ago
[deleted]
dmw_ng 2y ago
> converting huge amount of xml files > pickling Sounds like if this is the tooling and the task at hand, about the most complex things that should be passing through the pickler are partitioned lists of filenames rather than raw data. E.g. you can have each partition generate a parquet for combining in a final step (pyarrow.concat_tables() looks useful), or if it were some other format you were working with, potentially sending flat arrays back to the parent process as giant bytestrings or similar This is not to say the limitations don't suck, just that very often there are simple approaches to avoid most of the pain
- deleted 2y ago
  [deleted]
alberth 2y ago
You can quickly build prototypes with LuaJIT and it’s also quite performant. It’s worth giving it a try if you haven’t before.
nomel 2y ago
GIL has been relieved in Python 3.12: https://realpython.com/python312-subinterpreters/ https://realpython.com/python312-subinterpreters/ But, I have the same sentiment. Although, I find writing quick C++ extensions (swig is incredible) is a good balance.
jmakov 2y ago
ray.io
_niki_s_ 2y ago
Looks like Mojo will fix that
- itishappy 2y ago
  Right, by switching languages.

jti107 2y ago

use the right tool for the right job. your software requirements and design document should drive the language and the tools you use.

fullstackchris 2y ago
what i was thinking as well... i love these performance improvement posts but at the same time had to think what kind of choice was it to originally reach for python in the first place if the task was to do a lot of heavy concurrent task management???

bin_bash 2y ago

I enjoy both languages quite a bit, but a 4x improvement is more of a testament to python than it is to rust imo!

nolroz 2y ago
How do you mean? Would you expect it to be much slower?
- flohofwoe 2y ago
  Yeah, IME Python can be about 100x slower than a native solution. The original solution was a combination of a C library and Python wrapper code, so 4x makes sense for eliminating the Python part.

pjmlp 2y ago

Could be renamed as 120ms to 30ms: Python to "AOT compiled language".

Havoc 2y ago

Noticed similar scale of improvement when testing the two on cloud functions. Just comes down to whether you need speed of building it or speed of program

Talinx 2y ago

That is a lot of text for not determining why the new solution is faster. The only relevant part: > Before our migration, the old pipeline utilized a C library accessed through a Python service, which buffered and bundled data. This was really the critical aspect that was causing our latency. How much speed up would there have been if they moved to a Rust wrapper around the same C library? Using something other than Python is almost always going to be faster. This Reddit post does not give any insights into which aspects of Python lead to small/large performance hits. They show that it was the right solution for them with ample documentation which is great, but they don't provide any generalizable information.

gregors 2y ago

Am I the only one thinking "why wasn't it better?" Guess I'm never satisfied