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

51–60 of 255 posts

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

#51

Post by CuriousCosmic »

jpc0 wrote: post #43
hobofan wrote: post #29

Earlier quoted context omitted.

If that's a bug that only happens with AMD CPUs, I think that's totally fair. If we start adding in exceptions at the top of the software stack for individuals failures of specific CPUs/vendors, that seems like a strong regression from where we are today in terms of ergonomics of writing performance-critical software. We can't be writing individual code for each N x M x O x P combination of hardware + software + work…

> We can't be writing individual code for each N x M x O x P combination of hardware + software + workload + configuration That is kind of exactly what you would do when optimising for popular platforms. If this error occurs on an AMD Cpu used by half your users is your response to your user going to be "just buy a different CPU" or are you going to fix it in code and ship a "performance improvement on XYZ platform"…

Nobody said "just buy a different CPU" anywhere in this discussion or the article. And they are pinning the root cause on AMD which is completely fair because they are the source of the issue.

Given that the fix is within the memory allocator, there is already a relatively trivial fix for users who really need it (recompile with jemalloc as the global memory allocator).

For everyone else, it's probably better to wait until AMD reports back with an analysis from their side and either recommends an "official" mitigation or pushes out a microcode update.

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

#52

Post by dietrichepp »

Waterluvian wrote: post #48
pmontra wrote: post #47

> However, mmap has other uses too. It's commonly used to allocate large regions of memory for applications. Slack is allocating 1132 GB of virtual memory on my laptop right now. I don't know if they are using mmap but that's 1100 GB more than the physical memory.

I’m not sure allocations mean anything practical anymore. I recall OSX allocating ridiculous amounts of virtual memory to stuff but never found OSX or the software to ever feel slow and pagey.

The way I describe mmap these days is to say it allocates address space. This can sometimes be a clearer way of describing it, since the physical memory will only get allocated once you use the memory (maybe never).

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

#53

Post by ansible »

jpc0 wrote: post #43
hobofan wrote: post #29

Earlier quoted context omitted.

If that's a bug that only happens with AMD CPUs, I think that's totally fair. If we start adding in exceptions at the top of the software stack for individuals failures of specific CPUs/vendors, that seems like a strong regression from where we are today in terms of ergonomics of writing performance-critical software. We can't be writing individual code for each N x M x O x P combination of hardware + software + work…

> We can't be writing individual code for each N x M x O x P combination of hardware + software + workload + configuration That is kind of exactly what you would do when optimising for popular platforms. If this error occurs on an AMD Cpu used by half your users is your response to your user going to be "just buy a different CPU" or are you going to fix it in code and ship a "performance improvement on XYZ platform"…

The fix is that AMD needs to develop, test and deploy a microcode update for their affected CPUs, and then the problem is truly fixed for everyone, not just the people who have detected the issue and tried to mitigate it.

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

#56

Post by yjftsjthsd-h »

Attummm wrote: post #14
MrJohz wrote: post #13

Earlier quoted context omitted.

It's worth reading the article. In this case, it seems to have been a hardware issue - as such, not directly related to Rust, C, or Python, but triggered by an instruction that was only called by some file loading routines. It's a very cool deep dive into debugging these sorts of issues.

Although true that it's great article. It states that python is faster then c, that is not possible since python is build with c. There could be other reasons such libs or implementation. Also note that the issue he had was not resolved. The comment was about that python is seen as slow. But that is not always the case. Once a dev is able to understand the difference between the python and c parts. Python can be quit…

> It states that python is faster then c, that is not possible since python is build with c. There could be other reasons such libs or implementation.

In a really strict sense it's impossible to talk about the speed of languages, since any turing complete language could be implemented in any other. In practice when people say X is faster than Y, they mean in practice as actually used; it's completely possible, for instance, that if you ask a large pool of C programmers to... I dunno, sum ten billion integers, and the same to a large pool of Python programmers, most of the C devs will reach for a `for` loop and most of the Python devs will reach for numpy and get vectorization for free, and if that's the case then it's reasonable to say that Python is faster. Or in the actual case at hand, writing the same(ish) program in Rust and Python on the same hardware does result in the Python version being faster, even though it's a bug from that exact hardware not getting along with something under the hood in the Rust version.

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

#59

Post by byteknight »

dietrichepp wrote: post #52
Waterluvian wrote: post #48

Earlier quoted context omitted.

I’m not sure allocations mean anything practical anymore. I recall OSX allocating ridiculous amounts of virtual memory to stuff but never found OSX or the software to ever feel slow and pagey.

The way I describe mmap these days is to say it allocates address space. This can sometimes be a clearer way of describing it, since the physical memory will only get allocated once you use the memory (maybe never).

But is it not still limited by allocating the RAM + Page/Swap size?

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

#60

Post by p3n1s »

londons_explore wrote: post #45

So the obvious thing to do... Send a patch to change the "copy_user_generic" kernel method to use a different memory copying implementation when the CPU is detected to be a bad one and the memory alignment is one that triggers the slowness bug...

Not obvious. Seems like if it can be corrected with microcode just have people use updated microcode rather than litter the kernel with fixes that are effectively patchable software problems.

The accepted fix would not be trivial to anyone not already experienced with the kernel. But more important, it obviously isn’t obvious what is the right way to enable the workaround. The best way is to probably measure at boot time, otherwise how do you know which models and steppings are affected.

Post reply on HN