Anyone else feeling the frequency illusion with rep movsb?
Rust std fs slower than Python? No, it's hardware
31–40 of 255 posts
Re: Rust std fs slower than Python? No, it's hardware
#32>Rust std fs slower than Python!? No, it's hardware! >... >Python features three memory domains, each representing different allocation strategies and optimized for various purposes. >... >Rust is slower than Python only on my machine. if one library performs wildly better than the other in the same test, on the same hardware, how can that not be a software-related problem? sounds like a contradiction. Maybe should b…
The root cause is AMD's bad support for rep movsb (which is a hardware problem). However, python by default has a small offset when reading memories while lower level language (rust and c) does not, which is why python seems to perform better than c/rust. It "accidentally" avoided the hardware problem.
That extra 0x20 (32 byte) offset is the size of the PyBytes object header for anyone wondering; 64 bits each for type object pointer, reference count, base pointer and item count.
Re: Rust std fs slower than Python? No, it's hardware
#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?
Re: Rust std fs slower than Python? No, it's hardware
#34> 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?
I think it's pretty much free performance that's being left on the table. There's slight cost to binary size. And it may not perform better in absolutely all circumstances (but it will in almost all).
Rust used to use jemalloc by default but switched as people found this surprising as the default.
Re: Rust std fs slower than Python? No, it's hardware
#35> 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.
Re: Rust std fs slower than Python? No, it's hardware
#36Disclaimer: The title has been changed to "Rust std fs slower than Python!? No, it's hardware!" to avoid clickbait. However I'm not able to fix the title in HN.
What's the TLDR on how... hardware performs differently on two software runtimes?
Re: Rust std fs slower than Python? No, it's hardware
#37Disclaimer: The title has been changed to "Rust std fs slower than Python!? No, it's hardware!" to avoid clickbait. However I'm not able to fix the title in HN.
What's the TLDR on how... hardware performs differently on two software runtimes?
One of the very first things in the article is a TLDR section that points you to the conclusion.
> In conclusion, the issue isn't software-related. Python outperforms C/Rust due to an AMD CPU bug.
Re: Rust std fs slower than Python? No, it's hardware
#38Disclaimer: The title has been changed to "Rust std fs slower than Python!? No, it's hardware!" to avoid clickbait. However I'm not able to fix the title in HN.
What's the TLDR on how... hardware performs differently on two software runtimes?
AMD's implementation of `rep movsb` instruction is surprisingly slow when addresses are page aligned. Python's allocator happens to add a 16-byte offset that avoids the hardware quirk/bug.
Re: Rust std fs slower than Python? No, it's hardware
#39Earlier quoted context omitted.
What's the TLDR on how... hardware performs differently on two software runtimes?
One of the very first things in the article is a TLDR section that points you to the conclusion. > In conclusion, the issue isn't software-related. Python outperforms C/Rust due to an AMD CPU bug.
It is software-related.
Just the CPU perform badly on some software instruction.
Re: Rust std fs slower than Python? No, it's hardware
#40>Rust std fs slower than Python!? No, it's hardware! >... >Python features three memory domains, each representing different allocation strategies and optimized for various purposes. >... >Rust is slower than Python only on my machine. if one library performs wildly better than the other in the same test, on the same hardware, how can that not be a software-related problem? sounds like a contradiction. Maybe should b…
The root cause is AMD's bad support for rep movsb (which is a hardware problem). However, python by default has a small offset when reading memories while lower level language (rust and c) does not, which is why python seems to perform better than c/rust. It "accidentally" avoided the hardware problem.
It doesn't seem faster. Seem would imply that it isn't the case.
It is faster currently on that setup.
But since python runtime is written in C, the issue can't be Python vs C.