On 5/8/2013 11:35 AM, Chandler Carruth wrote:> Interestingly newer, supposedly "more secure" digest algorithms are > also very often significantly faster. I don't think we want any of the > ones mentioned here, I think we want one of the candidates is the SHA3 > competition which had truly stellar software implementation > throughput. I'm hoping to add support for such a digest algorithm to > LLVM soon, as there are many folks who want to consume this > information: modules, merge function pass, debug info, and the linker.Nice, Is it performant in size as well as speed too ?. Because lld would need to store this information for every atom thats mergeable. What are the SHA-3 variants that you think would suite these needs ? Thanks Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 5/8/2013 11:35 AM, Chandler Carruth wrote: > >> Interestingly newer, supposedly "more secure" digest algorithms are also >> very often significantly faster. I don't think we want any of the ones >> mentioned here, I think we want one of the candidates is the SHA3 >> competition which had truly stellar software implementation throughput. I'm >> hoping to add support for such a digest algorithm to LLVM soon, as there >> are many folks who want to consume this information: modules, merge >> function pass, debug info, and the linker. >> > Nice, Is it performant in size as well as speed too ?. Because lld would > need to store this information for every atom thats mergeable. >How about using only the first 80 (or 96 or 128) bits of the digest?> What are the SHA-3 variants that you think would suite these needs ? > > > Thanks > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/1253d46f/attachment.html>
On Wed, May 8, 2013 at 7:33 PM, Rui Ueyama <ruiu at google.com> wrote:> On Wed, May 8, 2013 at 10:29 AM, Shankar Easwaran <shankare at codeaurora.org > > wrote: > >> On 5/8/2013 11:35 AM, Chandler Carruth wrote: >> >>> Interestingly newer, supposedly "more secure" digest algorithms are also >>> very often significantly faster. I don't think we want any of the ones >>> mentioned here, I think we want one of the candidates is the SHA3 >>> competition which had truly stellar software implementation throughput. I'm >>> hoping to add support for such a digest algorithm to LLVM soon, as there >>> are many folks who want to consume this information: modules, merge >>> function pass, debug info, and the linker. >>> >> Nice, Is it performant in size as well as speed too ?. Because lld would >> need to store this information for every atom thats mergeable. >> > > How about using only the first 80 (or 96 or 128) bits of the digest? >This is exactly the right pattern (although the chunk size is usually 32, 64, 128, 256, 512). You trade off collision resistance against space. I think for atoms, you want to burn space in order to *not* compare them at all. I would suggest storing 256 bits at least.> > >> What are the SHA-3 variants that you think would suite these needs ? > >I want to look at the implementation complexity. The winner (and the official SHA3 algorithm), BMW and Skein are all worth looking at.> >> >> Thanks >> >> Shankar Easwaran >> >> -- >> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted >> by the Linux Foundation >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130508/ff705a02/attachment.html>