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

Rust std fs slower than Python? No, it's hardware

xuanwo.io

Post reply on HN
Print view View original

81–90 of 255 posts

Re: Rust std fs slower than Python? No, it's hardware

#81

Post by crabbone »

quietbritishjim wrote: post #18

I'm a bit confused about the premise. This is not comparing pure Python code against some native (C or Rust) code. It's comparing one Python wrapper around native code (Python's file read method) against another Python wrapper around some native code (OpenDAL). OK it's still interesting that there's a difference in performance, but it's very odd to describe it as "slower than Python". Did they expect that the Python…

> individually, highly optimised.

Now why would you expect that?

What happened to OP is a pure chance. CPython's C code doesn't even care about const-consistency. It's flush with dynamic memory allocations, bunch of helper / convenience calls... Even stuff like arithmetic does dynamic memory allocation...

Normally, you don't expect CPython to perform well, not if you have any experience working with it. Whenever you want to improve performance you want to sidestep all the functionality available there.

Also, while Python doesn't have a standard library, since it doesn't have a standard... the library that's distributed with it is mostly written in Python. Of course, some of it comes written in C, but there's also a sizable fraction of that C code that's essentially Python code translated mechanically into C (a good example of this is Python's binary search implementation which was originally written in Python, and later translated into C using Python's C API).

What one would expect is that functionality that is simple to map to operating system functionality has a relatively thin wrapper. I.e. reading files wouldn't require much in terms of binding code because, essentially, it goes straight into the system interface.

Re: Rust std fs slower than Python? No, it's hardware

#82

Post by qerti »

marcosdumay wrote: post #65
zerr wrote: post #54

Earlier quoted context omitted.

[flagged]

It's about making misuse difficult. Rust doesn't actually restrict much. It would take looking at lots of details, but my impression is that it's less restrictive than C.

The rust compiler refuses to compile code which doesn’t adhere to a strict set of rules guaranteeing memory safety. Unless you intentionally call an unsafe block, misuse in this sense is impossible, not just difficult.

Re: Rust std fs slower than Python? No, it's hardware

#83

Post by singron »

nh2 wrote: post #75
a1o wrote: post #33

> Rust developers might consider switching to jemallocator for improved performance I am curious if this is something that everyone can do to get free performance or if there are caveats. Can C codebases benefit from this too? Is this performance that is simply left on table currently?

Be aware `jemalloc` will make you suffer the observability issues of `MADV_FREE`. `htop` will no longer show the truth about how much memory is in use. * https://github.com/jemalloc/jemalloc/issues/387#issuecomment... * https://gitlab.haskell.org/ghc/ghc/-/issues/17411 Apparently now `jemalloc` will call `MADV_DONTNEED` 10 seconds after `MADV_FREE`: https://github.com/JuliaLang/julia/issues/51086#issuecomment... So w…

Note that glibc has a similar problem in multithreaded contexts. It strands unused memory in thread-local pools, which grows your memory usage over time like a memory leak. We got lower memory usage that didn't grow over time by switching to jemalloc.

Example of this: https://github.com/prestodb/presto/issues/8993

Re: Rust std fs slower than Python? No, it's hardware

#84

Post by db48x »

qerti wrote: post #82
marcosdumay wrote: post #65

Earlier quoted context omitted.

It's about making misuse difficult. Rust doesn't actually restrict much. It would take looking at lots of details, but my impression is that it's less restrictive than C.

The rust compiler refuses to compile code which doesn’t adhere to a strict set of rules guaranteeing memory safety. Unless you intentionally call an unsafe block, misuse in this sense is impossible, not just difficult.

But other types of misuse are not. For example, a naive program might do many reads into a small buffer instead of one read into a large buffer.

Re: Rust std fs slower than Python? No, it's hardware

#85

Post by Yoric »

qerti wrote: post #82
marcosdumay wrote: post #65

Earlier quoted context omitted.

It's about making misuse difficult. Rust doesn't actually restrict much. It would take looking at lots of details, but my impression is that it's less restrictive than C.

The rust compiler refuses to compile code which doesn’t adhere to a strict set of rules guaranteeing memory safety. Unless you intentionally call an unsafe block, misuse in this sense is impossible, not just difficult.

Just stating the obvious: breaking memory safety is only one subset of all the possible misuse available in the space of manners of using an API, data structure, etc.

Re: Rust std fs slower than Python? No, it's hardware

#87

Post by vlovich123 »

Pop_- wrote: post #35
a1o wrote: post #33

> Rust developers might consider switching to jemallocator for improved performance I am curious if this is something that everyone can do to get free performance or if there are caveats. Can C codebases benefit from this too? Is this performance that is simply left on table currently?

Switching to non-default allocator does not always brings performance boost. It really depend on your workload, which requires profiling and benchmarking. But C/C++/Rust and other lower level languages should all at least be able to choose from these allocators. One caveat is binary size. Custom allocator does add more bytes to executable.

I don’t know why people still look to jemalloc. Mimalloc outperforms the standard allocator on nearly every single benchmark. Glibc’s allocator & jemalloc both are long in the tooth & don’t actually perform as well as state of the art allocators. I wish Rust would switch to mimalloc or the latest tcmalloc (not the one in gperftools).

Re: Rust std fs slower than Python? No, it's hardware

#88

Post by TillE »

a1o wrote: post #33

> Rust developers might consider switching to jemallocator for improved performance I am curious if this is something that everyone can do to get free performance or if there are caveats. Can C codebases benefit from this too? Is this performance that is simply left on table currently?

jemalloc and mimalloc are very popular in C and C++ software, yes. There are few drawbacks, and it's really easy to benchmark different allocators against eachother in your particular use case.

Re: Rust std fs slower than Python? No, it's hardware

#89

Post by diamondlovesyou »

AMD's string store is not like Intel's. Generally, you don't want to use it until you are past the CPU's L2 size (L3 is a victim cache), making ~2k WAY too small. Once past that point, it's profitable to use string store, and should run at "DRAM speed". But it has a high startup cost, hence 256bit vector loads/stores should be used until that threshold is met.
Post reply on HN