[viff-devel] Optimizing preprocessing

[Marcel Keller]

Martin Geisler wrote:
> Janus Dam Nielsen <janus.nielsen at alexandra.dk> writes:
> 
>> Hi Marcel,
>>
>> I am not opposed to your suggestion. However I would like to point out
>> that in VIFF you compute on shares and not field elements!
> 
> Well, we've actually made the outer runtime interfaces in such a way
> that add, mul, xor, etc... accept both integers, FieldElements and
> Shares. The methods then wrap their input as needed -- or they *dont*
> wrap it if that leads to a short cut (e.g., constant multiplication)

I agree (see also my answer).

>> Computing directly on the field elements is hacking the abstractions
>> of VIFF. Computation on field elements or rather the representation of
>> a Share can be useful as an optimization, however this optimization
>> should be confined within applications or runtimes, and should not
>> progress over interface boundaries as I fear you are suggesting.
> 
> I think we are in agreement: public methods on the runtimes will keep
> returning Shares. Methods used internally in runtimes can return other
> things as needed. To me it sounds like a better API to require
> preprocessing functions to return a list of Deferreds:
> 
>   [D(?), D(?), ...],
> 
> instead of a Deferred list of tuples containing Deferreds :-)
> 
> I think it will simplify the interface nicely, at least for consumers.
> Using simpler types also leads to less memory usage which has a positive
> effect on performance, as Marcel notes. So let's go for it.

So this makes 2 votes in favour of it and 1 against it. Maybe we should 
have a meeting to discuss it. What do you think?

Best regards,
Marcel