Speedup float pack / unpack

[ruema]

Feature or enhancement

Proposal:

The code for packing and unpacking floating point numbers is typically a single memory operation on modern CPUs. However, the current implementation is much more complex.

The functions PyFloat_Pack4, PyFloat_Pack8, PyFloat_Unpack4, and PyFloat_Unpack8 can be refactored to allow compilers to produce more optimal machine code.

For example, using struct.pack(">d", 1.34) is approximately 1.2 times faster.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-122534 Speedup float pack / unpack #122535
• gh-122534: Speedup float pack / unpack #122536

[terryjreedy]

Why did you close the PR? Unwilling to sign the CLA? Something else? Should this issue be closed?

[nineteendo]

Another PR was created, but it currently only includes the news entry: #122536

EDIT by TJR: the second PR now duplicates the first.

[ruema]

the email address was not set correctly in the git commits. So I had to create a new branch. Sorry for that.

EDIT by TJR: With corrected email, 2nd PR has CLA signed.

[Ri-yaB]

Hi all,

I’ve reviewed this issue and the linked PRs. This optimization sounds impactful for performance-critical applications.

@ruema , could you provide benchmarks comparing the current implementation with the proposed changes? Additionally, is there a test case that highlights the performance gain?

If there’s any specific area where I can contribute, such as reviewing the new branch or writing tests, please let me know.

Best regards,
Riya

[Ri-yaB]

Subject: Thoughts on Optimizing Float Pack/Unpack

Hi everyone,
I’ve been exploring the topic and have a few ideas that might help with optimizing the float packing and unpacking functions. Here’s what I came up with:

1. Simplify the Current Code: The existing functions, PyFloat_Pack4, PyFloat_Pack8, PyFloat_Unpack4, and PyFloat_Unpack8, seem a bit more complex than they need to be. Refactoring them to use direct memory operations could align better with modern CPU optimizations. For instance, in Python, struct.pack achieves good performance:

`import struct

def pack_float(value, fmt=">d"):
return struct.pack(fmt, value)

def unpack_float(data, fmt=">d"):
return struct.unpack(fmt, data)[0]
`

2. Consider JIT Compilation for Optimization: Exploring Just-In-Time (JIT) compilation could also be beneficial. It allows for dynamic optimization, potentially reducing overhead. Tools like Numba might be worth experimenting with during prototyping.

3. Benchmark the Changes: Before finalizing anything, it’d be helpful to compare performance between the current and proposed methods. Setting up a benchmarking script for various scenarios, including edge cases, could provide valuable insights.

4. Test for Edge Cases: It’s crucial to verify behavior for special values like NaN, Infinity, and very small (denormalized) numbers. This ensures the updated implementation remains robust and compatible across different architectures.

5. Batch Processing for Performance Gains: If there’s scope to process multiple floats simultaneously, leveraging SIMD (Single Instruction, Multiple Data) operations might be a way to significantly improve speed. This could be a bit more involved but might be worth exploring for larger datasets.

I’d love to hear what others think about these ideas. If any of this sounds worth pursuing, I’m happy to dive deeper or help test things further!

Best,
Riya

[da-woods]

@Ri-yaB it looks like you're digging up old PRs/issues and posting very generic AI "reviews" on them. Much of it is pretty irrelevant to what's written here. For example on Point 1- this is a proposal to write C code to make the implementation of struct.pack faster, so using Python's struct.pack to implement it is a complete non-starter.

This is kind of review is just creating noise and isn't going to make you popular here (or on many other open-source projects).

[skirpichev]

For example, using struct.pack(">d", 1.34) is approximately 1.2 times faster.

pr thread has very different timings