[WIP] simd-buffers

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.

[tarcieri]

Implements the following SIMD types, as proposed in RustCrypto/traits#444:

• U128 (portable)
• U256 (x86/x86_64 only)
• U128x8 (portable)

These types are largely "storage only" and don't implement arithmetic (if we needed that, stdsimd/packed_simd would be a better choice)

The implementation does expose optimized XOR intrinsics, however, which seems to be the main thing useful in a portable cryptographic context, at least as far as our current usages of SIMD go.

The x86 backend exposes unsafe target_feature(enable = "...") functions as part of its API, intended to be used/inlined within SIMD backends for particular algorithms.

[tarcieri]

Based on my high-level survey in RustCrypto/traits#444 the main SIMD types we need are:

• U128x8 (AES, POLYVAL/GHASH)
• U256x4 (ChaCha20, Poly1305)

This PR presently only implements U128x8 as a POC, which is the only one which is reasonably easy to do in a portable manner.

If we decide this approach is actually a good idea I can take a look at adding U256x4 as a follow-up, but it might end up being x86-only unless there's a good reason to have a portable implementation.

[newpavlov]

I am still not sure if this approach will work well in practice, so before merging this and relevant PRs I would like to see how it will affect the downstream crates, i.e. I suggest prototyping the full chain of changes off the PR branches.

[tarcieri]

@newpavlov yep, that was my plan: prototype it end-to-end on a bunch of branches and see if we can get some meaningful performance wins out of it, then discuss it more

[tarcieri]

Going to go ahead and close this.

I think there are some other ways to address this without introducing an additional crate.

An interesting one would be supporting conversions between certain crypto-bigint types and SIMD registers.