Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?

Subject: Re: [boost] Any interest in hashing algorithms SHA and/or FNV1a?
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2013-11-14 14:11:36

On 11/14/2013 1:54 PM, foster brereton wrote:
> On Thu, Nov 14, 2013 at 9:24 AM, Jeff Flinn <Jeffrey.Flinn_at_[hidden]> wrote:
>
> [snip]
>
>> all the code but the call to perform_algorithm() deal with buffering, which
>> ends up being redundant with the buffering typically provided by client
>> code. The boost vault hash api exposes a process_block() method avoiding
>> redundant buffering. This allows me to do something like:
>>
>> boost::crypto::md5 h;
>>
>> boost::for_each
>>   (block_range
>> , [h&](const block& b){ h.process_block(b); other(b); });
>>
>> h.input(tail_data_ptr, tail_data_count);
>>
>> h.digest();
>
> [snip]
>
> I see what you mean now about the double-buffering, and my hash code
> is guilty of the same offense. I can look into modifying it to expose
> the process_block routine, however...
>
> I have been doing profiling of my SHA implementations, and copying the
> data around doesn't even show up on the radar -- the vast majority of
> the time, by far, is in the actual digest routine. The profile for MD5
> may look different, but at least in the case of SHA I don't know how
> much the straight-buffer-processing gains you.

It may not show up in profiling in isolation. My actual case defines 
h.process_block() as

CompositeHash<md5, sha1> h;

with process_block defined as:

CompositeHash<md5, sha1>::process_block(block& b)
{
    m_h1.process_block(b);
    m_h2.process_block(b);
}

and then I've got a nested hash:

NestedHash<CompositeHash<md5, sha1>> h;

you get the idea.

So it adds up - at a minimum all of the redundant buffering could be 
inhibiting optimizations possible with out the redundant buffering;

Jeff