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

61–70 of 255 posts

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

#61

Post by londons_explore »

p3n1s wrote: post #60
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…

I don't think AMD does microcode updates for performance issues do they? I thought it was strictly correctness or security issues.

If the vendor won't patch it, then a workaround is the next best thing. There shouldn't be many - that's why all copying code is in just a handful of functions.

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

#62

Post by Attummm »

yjftsjthsd-h wrote: post #56
Attummm wrote: post #14

Earlier quoted context omitted.

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 in…

The NumPy library doesn't utilize Python's C layer for its memory management.

Instead, it maintains its own memory space. Consequently, transferring data from the Python environment into NumPy or vice versa is relatively slow.

The process of opening a file and travesing its data within Python relies heavily on the C code behind the scenes, resulting in near-C performance.

However, if one were to write an algorithm along the lines of LeetCode - one that has a time complexity of n*2 - Python's performance will be slower compared to other languages. This difference could range from a factor of one to potentially even a hundred.

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

#63

Post by TylerE »

meneer_oke wrote: post #40
Pop_- wrote: post #23

Earlier quoted context omitted.

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.

C is a very wide target. There are plenty of things that one can do “in C” that no human would ever write. For instance, the C code generated by languages like nim and zig that essentially use C as a sort of IR.

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

#64

Post by wbkang »

byteknight wrote: post #59
dietrichepp wrote: post #52

Earlier quoted context omitted.

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?

I don't think so, but it's difficult to find an actual reference. For sure it does overcommit like crazy. Here's an output from my mac:

% ps aux | sort -k5 -rh | head -1

xxxxxxxx 88273 1.2 0.9 1597482768 316064 ?? S 4:07PM 35:09.71 /Applications/Slack.app/Contents/Frameworks/Slack Helper (Renderer).app/...

Since ps displays vsz column in KiB, 1597482768 corresponds to 1TB+.

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

#65

Post by marcosdumay »

zerr wrote: post #54
royjacobs wrote: post #2

I was prepared to read the article and scoff at the author's misuse of std::fs. However, the article is a delightful succession of rabbit holes and mysteries. Well written and very interesting!

[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.

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

#66

Post by meneer_oke »

TylerE wrote: post #63
meneer_oke wrote: post #40

Earlier quoted context omitted.

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.

C is a very wide target. There are plenty of things that one can do “in C” that no human would ever write. For instance, the C code generated by languages like nim and zig that essentially use C as a sort of IR.

That is true, With C allot of possible

> However, python by default has a small offset when reading memories while lower level language (rust and c)

Yet if the runtime is made with C, then that statement is incorrect.

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

#67

Post by bri3d »

royjacobs wrote: post #2

I was prepared to read the article and scoff at the author's misuse of std::fs. However, the article is a delightful succession of rabbit holes and mysteries. Well written and very interesting!

This was such a good article! The debugging was smart (writing test programs to peel each layer off), the conclusion was fascinating and unexpected, and the writing was clear and easy to follow.

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

#68

Post by p3n1s »

londons_explore wrote: post #61
p3n1s wrote: post #60

Earlier quoted context omitted.

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…

I don't think AMD does microcode updates for performance issues do they? I thought it was strictly correctness or security issues. If the vendor won't patch it, then a workaround is the next best thing. There shouldn't be many - that's why all copying code is in just a handful of functions.

A significant performance degradation due to normal use of the instruction (FSRM) not otherwise documented is a correctness problem. Especially considering that the workaround is to avoid using the CPU feature in many cases. People pay for this CPU feature now they need kernel tooling to warn them when they fallback to some slower workaround because of an alignment issue way up the stack.
Post reply on HN