Re: [viff-devel] Orlandi preprocessing

[Janus Dam Nielsen]

It is correct both in theory and in practice, so please don't limit  
the items per call!


On 22/10/2009, at 20.33, Ivan Damgård wrote:


I have not been following the discussion in detail, but it's true that
the more items you request, the smaller the amortized cost, at least
in theory. I also think it would be a very good idea to involve  
either Jesper
or Claudio in this, if there is any place where you are in doubt at  
all.


regards, Ivan

On 22/10/2009, at 20.17, Marcel Keller wrote:


Hi Janus,

I remember you saying today that the preprocessing in the  
OrlandiRuntime is more efficient per item the more items are  
requested. Is that correct? I ask because in my optimizations, I  
limited the items being preprocessed per call in order to save  
memory. I would of course drop that because it doesn't really  
affect the other cases.


Best regards,
Marcel
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk






Janus Dam Nielsen

Research and Innovationspecialist, PhD.
CENTRE FOR IT-SECURITY

THE ALEXANDRA INSTITUTE LTD.

T +45 42 22 93 56
E janus.niel...@alexandra.dk
W alexandra.dk


___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Re: [viff-devel] Orlandi preprocessing

[Ivan Damgård]

I have not been following the discussion in detail, but it's true that
the more items you request, the smaller the amortized cost, at least
in theory. I also think it would be a very good idea to involve  
either Jesper

or Claudio in this, if there is any place where you are in doubt at all.

regards, Ivan

On 22/10/2009, at 20.17, Marcel Keller wrote:


Hi Janus,

I remember you saying today that the preprocessing in the  
OrlandiRuntime is more efficient per item the more items are  
requested. Is that correct? I ask because in my optimizations, I  
limited the items being preprocessed per call in order to save  
memory. I would of course drop that because it doesn't really  
affect the other cases.


Best regards,
Marcel
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk


___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Re: [viff-devel] Orlandi preprocessing

[Claudio Orlandi]

Correct!

On Thu, Oct 22, 2009 at 11:17 AM, Marcel Keller  wrote:
> Hi Janus,
>
> I remember you saying today that the preprocessing in the OrlandiRuntime is
> more efficient per item the more items are requested. Is that correct? I ask
> because in my optimizations, I limited the items being preprocessed per call
> in order to save memory. I would of course drop that because it doesn't
> really affect the other cases.
>
> Best regards,
> Marcel
> ___
> viff-devel mailing list (http://viff.dk/)
> viff-devel@viff.dk
> http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
>
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

[viff-devel] Orlandi preprocessing

[Marcel Keller]

Hi Janus,

I remember you saying today that the preprocessing in the OrlandiRuntime 
is more efficient per item the more items are requested. Is that 
correct? I ask because in my optimizations, I limited the items being 
preprocessed per call in order to save memory. I would of course drop 
that because it doesn't really affect the other cases.


Best regards,
Marcel
___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Re: [viff-devel] Optimizing preprocessing

[Janus Dam Nielsen]

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.

Then by all means go ahead and speed up the preprocessing. :)



Janus Dam Nielsen

Research and Innovationspecialist, PhD.
CENTRE FOR IT-SECURITY

THE ALEXANDRA INSTITUTE LTD.

T +45 42 22 93 56
E janus.niel...@alexandra.dk
W alexandra.dk


___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Re: [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 > 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.

___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Re: [viff-devel] Optimizing preprocessing

[Janus Dam Nielsen]

On 21/10/2009, at 20.28, Marcel Keller wrote:

Martin Geisler wrote:

Janus Dam Nielsen  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.



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.




Janus Dam Nielsen

Research and Innovationspecialist, PhD.
CENTRE FOR IT-SECURITY

THE ALEXANDRA INSTITUTE LTD.

T +45 42 22 93 56
E janus.niel...@alexandra.dk
W alexandra.dk


___
viff-devel mailing list (http://viff.dk/)
viff-devel@viff.dk
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk