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

171–180 of 255 posts

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

#171

Post by analog31 »

qd011 wrote: post #104
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…

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 think the confusion comes from people not having a good understanding of what an interpreted programming language does, and what actual portion of time is spent in high versus low level code. I've always assumed that most of my programs amount to a bit of glue thrown in between system calls.

Also, when we talk about "faster" and "slower," it's not clear the order of magnitude.

Maybe an analysis of actual code execution would shed more light than a simplistic explanation that the Python interpreter is written in C. I don't think the BASIC interpreter in my first computer was written in BASIC.

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

#172

Post by jll29 »

fsniper wrote: post #41

The article itself is a great read and it has fascinating info related to this issue. However I am more interested/concerned about another part. How the issue is reported/recorded and how the communications are handled. Reporting is done over discord, which is a proprietary environment which is not indexed, or searchable. Will not be archived. Communications and deliberations are done over discord and telegram, which…

> Reporting is done over discord, which is a proprietary environment which is not indexed, or searchable. Will not be archived.

That's why I don't accept the response "but there's Discord now" whenever I moan about USENET's demise. Back in the days before it, every post was nicely searchable by DejaNews (later Google).

We need to get back to open standards for important communications (e.g. all open source projects that are important to the Internet/WWW stack and core programming and libraries).

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

#173

Post by hobofan »

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

Yeah, but even if you'd take this on as your responsibility (while it should really be the CPU vendor fixing it), you would like to resolve it much lower in the stack, like the Rust compiler/standard library or LLVM, and not individually in any Rust library that happens to stumble upon that problem.

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

#174

Post by saagarjha »

munch117 wrote: post #161
cozzyd wrote: post #145

Earlier quoted context omitted.

Because the offset is entirely due to space for the PyObject header.

The PyObject header is a target for optimisation. Performance regressions are likely to be noticed, and if a different header layout is faster, then it's entirely possible that it will be used for purely empirical reasons. Trying different options and picking the best performing one is not luck, even if you can't explain why it's the best performing.

You can expect the Python developers to look very closely at any benchmark that significantly benefits from adding random padding to the object header. Performance isn’t just trying a bunch of random things and picking whatever works the best, it’s critical to understand why so you know that the improvement is not a fluke. Especially since it is very easy to introduce bias and significantly perturb the results if you don’t understand what’s going on.

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

#175

Post by jll29 »

xuanwo wrote: post #6
sgift wrote: post #3

Either the author changed the headline to something less clickbaity in the meantime or you edited it for clickbait Pop_- (in that case: shame on you) - current headline: "Rust std fs slower than Python!? No, it's hardware!"

Sorry for the clickbaity title, I have changed it based on others advice.

Thanks for this unexpected, thriller-like read.

I'm impressed by your perseverance, how you follow through with your investigation to the lowest (hardware) level.

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

#176

Post by hobofan »

richardwhiuk wrote: post #49
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…

You are going to be disappointed when you find out there's lots of architecture and CPU specific code in software libraries and the kernel.

That's completely fine in kernels and low-level libraries, but if I find that in a library as high-level as opendal, I'll definitely mark it down as a code smell.

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

#177

Post by saagarjha »

fweimer wrote: post #124
giancarlostoro wrote: post #114

Earlier quoted context omitted.

So correct me if I am wrong but does this mean you need to compile two executables for a specific compile time build? Or is it just you need to compile it from specific hardware? Wondering what the fix would be, some sort of runtime check?

The exact nature of the fix is unclear at present. During dynamic linking, glibc picks a memcpy implementation which seems most appropriate for the current machine. We have about 13 different implementations just for x86-64. We could add another one for current(ish) AMD CPUs, select a different existing implementation for them, or change the default for a configurable cutover point in a parameterized implementation.

This code is in the kernel, so dynamic linking and glibc is not really relevant.

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

#178

Post by saagarjha »

ww520 wrote: post #127
giancarlostoro wrote: post #114

Earlier quoted context omitted.

So correct me if I am wrong but does this mean you need to compile two executables for a specific compile time build? Or is it just you need to compile it from specific hardware? Wondering what the fix would be, some sort of runtime check?

Since the CPU instructions are the same, instruction patching at startup or install time can be used. Just patch in the correct instructions for the respective hardware.

This is generally a bad idea because it requires code modification, which has security implications. Most implementations will bring in multiple implementations and select the right one at startup (amortizing the indirect call into something like the GOT which already exists).

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

#179

Post by saagarjha »

the8472 wrote: post #143
giancarlostoro wrote: post #114

Earlier quoted context omitted.

So correct me if I am wrong but does this mean you need to compile two executables for a specific compile time build? Or is it just you need to compile it from specific hardware? Wondering what the fix would be, some sort of runtime check?

The sibling comments mention the hardware specific dynamic linking in glibc that's used for function calls. But if your compiler inlines memcpy (usually for short, fixed-sized copies) into the binary then yes you'll have to compile it for a specific CPU to get optimal performance. But that's true for all target-dependent optimizations. More broadly compatible routines will still work on newer CPUs, they just won yiel…

They are, glibc already has an ERMS code path for memcpy.

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

#180

Post by saagarjha »

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

It’s not a trivial fix. Besides the fix likely being in microcode (where AMD figures out why aliasing is broke for addresses that are close to page-aligned), even a software mitigation would be complex because the kernel cannot actually use vector instructions that are typically used for the fallback path when ERMS is not available.
Post reply on HN