Hi Eric, On Fri, Dec 13, 2019 at 4:28 AM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > Now, it's possible that the performance gain outweighs this, and I too would > like to have the C implementation of Poly1305 be faster. So if you'd like to > argue for the performance gain, fine, and if there's a significant performance > gain I don't have an objection. But I'm not sure why you're at the same time > trying to argue that *adding* an extra implementation somehow makes the code > easier to audit and doesn't add complexity... Sorry, I don't mean to be confusing, but I clearly haven't written very well. There are two things being discussed here, 32-bit and 64-bit, rather than just one. Let me clarify: - The motivation for the 64-bit version is primarily performance. Its performance isn't really in dispute. It's significant and good. I'll put this in the commit message of the next series I send out. - The motivation for the 32-bit version is primarily to have code that can be compared line by line to the 64-bit version, in order to make auditing easier given the situation with two implementations and also for general cleanliness. I think there's enormous value in having the other implementation be "parallel". Rather than two totally different and foreign implementations, we have two related and comparable ones. That's a good thing. As a *side note*, it might also be slightly faster than the one it replaces, which is great and all I guess, but not the primary motivation of the 32-bit version. Does that make sense? That's why I appear to simultaneously be arguing that performance matters and doesn't matter. The motivation for the 64-bit version is performance. The motivation for the 32-bit version is cleanliness. Two things, which are related. I'll make this clear in the commit message of the next series I send. Sorry again for being confusing. Jason
