Re: [boost] [gsoc][student] Proposal

Subject: Re: [boost] [gsoc][student] Proposal
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2009-03-23 07:53:46

On Sat, Mar 21, 2009 at 3:36 AM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
>>
>> On Fri, Mar 20, 2009 at 6:49 PM, Mathias Gaunard
>> <mathias.gaunard_at_[hidden]> wrote:
>
>>> You write the algorithm generically, then you can have specific cases.
>>> You don't build genericity on top of specific cases.
>>>
>>
>> Hum, there are many highly generic linear algebra c++ libraries that
>> do exactly that calling BLAS and friends for specific cases.
>
> uBLAS has its own generic implementation for everything it provides.
> It can only call BLAS in specific cases, as you say: it's only a
> specialization.
>
> You can specialize generic code, but you cannot build a generic
> implementation from a specialization.
>

Except when you can, if you can reduce all generic cases to a few
specialized cases. See my previous email.

The key here is that a generic crypto algorithm is only generic on the
range type, not on the value type: all crypto algorithms always work
on ranges of bytes (generating a range of bytes from a generic range
of objects is completely orthogonal and best left to a serialization
library).

In fact to get decent performance, all crypto algorithm
implementations I know work on contiguous chunks of bytes (you do not
need the whole range to be contiguous, but at least parts of it should
be). There is little or no gain in making such an implementation
generic. On the other hand, writing a range generic interface on top
of such a library would be useful and relatively simple.

Again, look at the OpenSSL EVP layer as a good low level
non-generic[*] crypto interface

-- 
gpd