Closed linkmauve closed 4 years ago
Curious if you could wire up Travis's aarch64 support so we could CI this
Do you know which flags their CPUs have? I’ll have a look at doing this CI thing after I’m done with sha256.
I've never actually used it, so I don't offhand
@linkmauve doesn't look like a224dd2 did the trick... perhaps move the arch
key to the toplevel?
@linkmauve ok, unrelated build failure this time but at least it attempted an ARM build.
That said, it seems like you'll probably need to go back to explicit build matrix entries for arm64
, but run tests specifically for sha1
and sha2
. Something like:
cargo test --package sha1 --package sha2
Whoops, my bad, --package sha-1
Hmm, it seems like that’s not the correct way to do it. And there is only one build now instead of three.
Whoops sorry, those are still the wrong package names. Try:
cargo test --package sha1-asm --package sha2-asm
That passes locally for me.
How do you test locally btw?
I was just making sure the command worked. It didn't actually test on ARM (and it seems there aren't specifically tests for these crates, which is unfortunate)
I can try to add them retroactively if we can get the build working.
Yay, it works!
Nice! Let me do another pass on this and I can merge it.
Not sure if I have access to release the associated crates though, unfortunately.
My main worry with merging this as-is is the lack of test vectors. You can probably reuse the ones from the sha-1
and sha2
crates.
I’ve already tested it with those, it was how I found most of the bugs while writing this code. ^^
That's good, but it'd also be good if they ran in CI too.
This would add a test dependency on digest, do you really want that? Or maybe I could just copy the implementations, but meh.
This would add a test dependency on digest, do you really want that?
I can merge this as/is and we can circle back on that.
Here are some benchmarks on my Nintendo Switch:
Without this patch (or without
--features=asm
):With this patch:
Only the SHA-256 function is implemented, my console doesn’t support the sha512 extension.
There are probably scheduling fixes to be made, I haven’t paid any attention to latency.
I have also compared to OpenSSL, this implementation is up to 20% slower, probably because it does a function call every 64 bytes, instead of a tight loop.