Using x86 intrinsics for carry-less multiplication

[benjaminsavage]

I HATE THIS.

I give up. After a bunch of Googling, I just can't figure out how to safely convert from a __m128i to something normal like a u128.

It's kind of funny that the actual carryless multiplication function isn't unsafe, it's just casting it back to a value that isn't safe.

I mean, the struct is so simple, it's just:

    pub struct __m128i(i64, i64);

So if only the struct members were not private, I would just call:

let intermediate_result = intrinsic_result.1;

If someone wants to commandeer this PR and find a way to land it, please go for it!

[akoshelev]

I just can't figure out how to safely convert from a __m128i to something normal like a u128.

You may need an extra step to go from __m128i to to Simd type but after that you should be able to view it as [u64; 2].

it is a bit annoying I agree, that's why I appreciate standard libraries :)

[akoshelev]

Could be wrong but I think this wouldn't work on ARM because it uses different instruction set for carry-less multiplies. Lots of folks use M1 Mac (ARM) so we probably need to support both x86 and ARM and define 3 sets of multiplication instructions: no clmul support (basically what we had before), x86 with clmul support and ARM with clmul support.

In other words, something like this should be enough

#[cfg(all(
    target_arch = "x86_64",
    target_feature = "pclmulqdq"
))]
fn mul(a: 64, b: 64) -> u128 // or [u64; 2]
{
   ... Intel intrinsics  
}

#[cfg(all(
    target_arch="aarch64",
    target_feature="neon"
)]
fn mul(a: 64, b: 64) -> u128 // or [u64; 2]
{
   ... ARM intrinsics  
}

#[cfg(not(any(all(
    target_arch="aarch64",
    target_feature="neon"), all(
    target_arch = "x86_64",
    target_feature = "pclmulqdq"
)))]
fn mul(a: 64, b: 64) -> u128 // or [u64; 2] 
{
   no hardware support, standard multiply
}

some reference materials and I would be happy to help if needed:
rust-lang/stdarch#318
https://github.com/geky/gf256/blob/master/src/xmul.rs

[martinthomson]

This will need feature detection.

We can maybe assume the existence of these instructions and avoid having to deal with cpuid instructions (which are even worse than this), but we at least need to make this conditional on CPU architecture. Otherwise our Mac users will be unable to run this.

I might be able to pick this up, but I can't guarantee that I'll have time for it.

[benjaminsavage]

I'd say this is very lo-pri as it:
1.) Does not affect communication costs
2.) Doesn't unlock any new functionality
3.) Makes the code significantly less readable
4.) Isn't (yet) identified as a bottleneck

I suggest we just keep this draft around for a while and only pick it up once we run out of higher-impact stuff to do =).