Re: [viff-devel] Optimizing preprocessing
Hi Janus, 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!. Computing directly on the field elements is hacking the abstractions of VIFF. I don't think so. Since I work with VIFF, it treats field elements as they would be shares with threshold 0. You can multiply and add field elements and shares. Furthermore, if you open to shares and multiply them, VIFF doesn't multiply locally, but executes the multiplication for shares of higher threshold. You have to do the following to achieve local multiplication: a = open(share_a) b = open(share_b) c = gather_shares([a, b]) c.addCallback(lambda (a, b): a * b) Therefore, I think that VIFF computes on field elements as well as on shares almost equally. 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 believe that if you would implement an OrlandiTuple class and overload operators there with the current _plus, _minus, and _const_mul functions, the OrlandiRuntime could reuse the add, sub, and lin_comb functions from PassiveRuntime and maybe even the mul function from BasicActiveRuntime. The OrlandiTuple would then be something equivalent to a FieldElement in the older runtimes. 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
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!. 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. On 08/10/2009, at 20.11, Marcel Keller wrote: Dear friends of VIFF, I have a proprosal to optimize preprocessing in VIFF, which I would like to put up for discussion. Notation: - D(x): a Deferred object whose callback function will be called with x - S(x): same for a Share object - F: a FieldElement object - [x, ...]: a Python list - (x, ...): a Python tuple Current situation: The two generate_triples() functions in the active runtimes return n, D([(S(F), S(F), S(F)), ...]), where n denotes the length of the list. Runtime.preprocess() puts one D(S(F), S(F), S(F)) per program counter in the preprocessing pool and uses util.deep_wait() to return a Deferred whose callback is called when all field elements are available. The get_triple() functions return D(S(F), S(F), S(F)), either taken from the preprocessing pool, or by calling generate_triples() and adding an extra callback to extract the first triple. My proposal: The generate_triples() functions return [D([F, F, F]), ...], and Runtime.preprocess() puts one [F, F, F] per program counter in the preprocessing pool. There is no need for deep_wait, we can just use gatherResults on the Deferreds return by the generator functions. The generator functions can use gatherResults to get D([F, F, F]) from [S(F), S(F), S(F)]. The get_triple() functions return [F, F, F], True if there is a triple in the pool, and [S(F), S(F), S(F)], Falseotherwise. For the multiplication in BasicActiveRuntime it doesn't make a difference whether FieldElements or Shares are returned. Future applications which require Shares can wrap the FieldElements in Shares if the Boolean is True. Benchmarks: - 1 multiplications in parallel with active security using PRSS - 4% faster preprocessing - 5% faster online operation - 50 MB less memory used - 10 AES blocks in parallel using masked exponentiation with active security using PRSS - 10% faster preprocessing - 10% faster online operation - 140 MB less memory used Further considerations: - I don't see any problem for replacing FieldElement with anything that does not contain Deferreds in any form. - Probably, it would also be possible to leave the generator functions as they are and use something similar to deep_wait(). However, I consider it as an overhead. - One could also always wrap the FieldElements in Shares, but this would again be an overhead. 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] Broken build!
Hi everybody, The build is broken: That is unfortunate, thanks for notifying. I will fix it as soon as possible. Janus, you added this code to benchmark.py: def update_args(runtime, options): args = {} if options.args != "": for arg in options.args.split(','): id, value = arg.split('=') args[id] = long(value) runtime.setArgs(args) return runtime Yes I did. What is that supposed to do? It is supposed to be a way for providing arguments for runtimes, which are unique for a given runtime. We don't have a setArgs method anywhere, If you use the --args commandline argument then it is your responsibility that the runtime you use has a proper setArgs method. and we don't use the Java-like CamelCase coding style anyway. Right, I will change that, as soon as possible. You're not trying to parse the command line, right? (we have optparse for that) I believe that the commandline arguments should be general to all runtimes. 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
[viff-devel] Broken build!
Hi everybody, The build is broken: http://buildbot.viff.dk/waterfall Janus, you added this code to benchmark.py: def update_args(runtime, options): args = {} if options.args != "": for arg in options.args.split(','): id, value = arg.split('=') args[id] = long(value) runtime.setArgs(args) return runtime What is that supposed to do? We don't have a setArgs method anywhere, and we don't use the Java-like CamelCase coding style anyway. You're not trying to parse the command line, right? (we have optparse for that) -- Martin Geisler VIFF (Virtual Ideal Functionality Framework) brings easy and efficient SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/. ___ viff-devel mailing list (http://viff.dk/) viff-devel@viff.dk http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk