[viff-devel] Optimizing preprocessing

[Marcel Keller]

Janus Dam Nielsen wrote:
> 
> On 21/10/2009, at 20.28, Marcel Keller wrote:
>> Martin Geisler wrote:
>>> Janus Dam Nielsen <janus.nielsen at alexandra.dk 
>>> <mailto: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).
> I would still like to stress that Shares are the basic values in VIFF. 
> The interface is then designed in such a way, so that we can do various 
> optimizations, but computing on field elements (a particular 
> representation of a share) is an optimization, which I am very happy 
> that the interface allows us to do. But it is still an optimization. 

I agree that the design maybe is not optimal semantically, IMHO because 
Shares are Deferreds. This leads to the situation that whenever a 
callback returns a Share, the Deferred code converts it into the result 
carried by the Share. However, a list of Shares returned by a callback 
is not converted.

>>>> 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?
> I can agree on this as well, as long as we don't make field elements 
> canonical.

You mean that the preprocessing infrastructure should not be restricted 
to FieldElements but can handle other items such as the tuples used by 
the Orlandi runtime. Is that correct? It was never my plan to introduce 
this restriction. I just want to get rid of the Deferreds in the 
preprocessing pool because I think that they are unnecessary there.