Why is there need to move memory? Hardware cannot DMA data into non-page-aligned memory? Or Linux doesn't want to load non-aligned data?
The Linux page cache keeps data page-aligned so if you want the data to be unaligned Linux will copy it.
Rust std fs slower than Python? No, it's hardware
151–160 of 255 posts
Re: Rust std fs slower than Python? No, it's hardware
#152I'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…
I don't understand why Python gets shit for being a slow language when it's slow but no credit for being fast when it's fast just because "it's not really Python". If I write Python and my code is fast, to me that sounds like Python is fast, I couldn't care less whether it's because the implementation is in another language or for some other reason.
Because when people talk about Python performance they're talking about the performance of Python code itself, not C/Rust code that it's wrapping.
Pretty much any language can wrap C/Rust code.
Why does it matter?
1. Having to split your code across 2 languages via FFI is a huge pain.
2. You are still writing some Python. There's plenty of code that is pure Python. That code is slow.
Re: Rust std fs slower than Python? No, it's hardware
#153Re: Rust std fs slower than Python? No, it's hardware
#154Earlier quoted context omitted.
Isn't the high startup cost what FSRM is intended to solve? > With the new Zen3 CPUs, Fast Short REP MOV (FSRM) is finally added to AMD’s CPU functions analog to Intel’s X86_FEATURE_FSRM. Intel had already introduced this in 2017 with the Ice Lake Client microarchitecture. But now AMD is obviously using this feature to increase the performance of REP MOVSB for short and very short operations. This improvement applies…
Fast is relative here. These are microcoded instructions, which are generally terrible for latency: microcoded instructions don't get branch prediction benefits, nor OoO benefits (they lock the FE/scheduler while running). Small memcpy/moves are always latency bound, hence even if the HW supports "fast" rep store, you're better off not using them. L2 is wicked fast, and these copies are linear, so prediction will be…
I'm not sure that your comment is responsive to the original post.
FSRM is fast on Intel, even with single byte strings. AMD claims to support FSRM with recent CPUs but performs poorly on small strings, so code which Just Works on Intel has a performance regression when running on AMD.
Now here you're saying `REP MOVSB` shouldn't be used on AMD with small strings. In that case, AMD CPUs shouldn't advertise FSRM. As long as they're advertising it, it shouldn't perform worse than the alternative.
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/2030515
https://sourceware.org/bugzilla/show_bug.cgi?id=30994
I'm not a CPU expert so perhaps I'm misinterpreting you and we're talking past each other. If so, please clarify.
Re: Rust std fs slower than Python? No, it's hardware
#155would be lovely if ${cpu_vendor} would document exactly how FSRM/ERMS/etc are implemented and what the expected behavior is
Re: Rust std fs slower than Python? No, it's hardware
#156Re: Rust std fs slower than Python? No, it's hardware
#157Re: Rust std fs slower than Python? No, it's hardware
#158Earlier quoted context omitted.
The reason the reliability & compatibility arguments don’t make sense to me is that jemalloc is still in use for rustc (again - not sure why they haven’t switched to mimalloc) which has all the same platform requirements as the standard library. There’s also no reason an alternate allocator can’t be used on Linux specifically because glibc’s allocator is just bad full stop. > It makes interactions with anything which…
> jemalloc is still in use for rustc (again - not sure why they haven’t switched to mimalloc) Performance of rustc matters a lot! If the rust compiler runs faster when using mimalloc, please benchmark & submit a patch to the compiler.
Any links to instructions on how to run said benchmarks?
Re: Rust std fs slower than Python? No, it's hardware
#159I'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…
I don't understand why Python gets shit for being a slow language when it's slow but no credit for being fast when it's fast just because "it's not really Python". If I write Python and my code is fast, to me that sounds like Python is fast, I couldn't care less whether it's because the implementation is in another language or for some other reason.
>I don't understand why Python gets shit for being a slow language when it's slow but no credit for being fast when it's fast just because "it's not really Python".
What's there to understand? When it's fast it's not really Python, it's C. C is fast. Python can call out to C. You don't have to care that the implementation is in another language, but it is.