Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implementing crc32c for AARCH64 #11

Closed
ossdev07 opened this issue Oct 24, 2019 · 2 comments
Closed

Implementing crc32c for AARCH64 #11

ossdev07 opened this issue Oct 24, 2019 · 2 comments

Comments

@ossdev07
Copy link

ossdev07 commented Oct 24, 2019

I know that there is a software implementation of this package for non-intel architectures, but that requires an extra environment variable to be declared. ie: "CRC32C_SW_MODE"
But my concern is that, why is it only limited to intel specific instructions set ? What if I want to use this package on ARM machine, and just because the environment variable isn't declared by default it would through me an error "Unsupported platform", even though the platform does support it and has dedicated registers for it.
Or maybe if we can just set the software implementation as the default fallback mechanism, in case we encounter a non-intel arch, we can surely let the user know that we're using software instead of hardware with appropriate logs. There is no point in failing the loading of module, just because its non-intel and the user hasn't declared the environment variable.
Is there any progress done on this front ?? Or maybe you can suggest a workaround ?

@ossdev07 ossdev07 changed the title Implementing crc2c for Aarch64 Implementing crc32c for AARCH64 Oct 24, 2019
@rtobar
Copy link
Contributor

rtobar commented Oct 24, 2019

Hi @ossdev07, I think there are two different points in your message, so I will address them separately.

Regarding the title of this ticket: our package doesn't currently support the optional ARMv8 crc32c instructions, mainly because we haven't had a use case that has pushed us to add it. However we'd be more than happy to accept such contribution, and make the package hardware-based implementation more generic rather than Intel-specific.

Regarding the selection of the software-based solution, this is mostly historical (you can see some discussion in #5). Changing this interface would be a breaking change (so it would mean an increase on the major version of the library), but I do agree that it would make sense to do it now that the library supports a good fallback software-based implementation. This point is completely separate from that of adding or not ARMv8 hardware-based crc32c support to the package though, so I'd rather we open a new issue to handle it separately.

@rtobar
Copy link
Contributor

rtobar commented Sep 2, 2020

A first version of this support has been implemented on the current master branch. It works on Linux only at the moment, where a ~2-3x performance improvement can be seen in systems under test. A new release will be pushed out soon to PyPI with this and other improvements.

@rtobar rtobar closed this as completed Sep 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants