Hi folks
Martin Geisler wrote:
[email protected] writes:
Hi Tomas and others,
http://hg.viff.dk/viff/rev/c8810dc507f3
changeset: 766:c8810dc507f3
user: Martin Geisler <[EMAIL PROTECTED]>
date: Tue May 20 14:18:27 2008 +0200
summary: Fixed memory leak.
It turned out that we kept references to empty deques in
incoming_data without ever releasing them. This caused the memory
usage to grow as more and more communication was done.
Could you please try your gigantic computations again and see if this
helps in your case?
Nope, memory usage has grown.
viff-0.4:
~630,000kB
viff-f993269c2660:
~690,000kB
And this is per party (three of them in all).
But I do see a difference: In 0.4 the memory usage was constantly max'ed
out. In f993269c2660, two parties can finish early and then free
essentially all their memory. Later they then reallocate ~0.5GB.
So something good is definitely happening, but it doesn't solve my
problem :-(
And just to describe my "gigantic" computation, it's actually not so
big: I load 100,000 shares (of Z_7 :-) from disk, reconstruct the
associated values, and print them.
Saying 4 bytes/field-element (say using 32-bit integers as could be done
easily in C), and 400,000 field-elements (100,000 shares from each of
the three parties and 100,000 reconstructed secrets) this amounts to
around an astonishing 400kB (per party).
Or alternatively: Using ~(6/4)kB = ~12,000 bits per 32-bit field-element.
One positive thing here is that I've gotten an idea of how to
potentially remove /some/ of that overhead (honest-but-curious only).
The observation is that we don't need to store all shares and
reconstruct at the end. We can just keep track of the sum of the shares
(times their lambda's) we've recieved. Whenever a new one arrives we add
it to that accumulator. This might not make a big difference in a
3-party setting, but if many (e.g. 10) parties are involved, then this
seems like a good idea to reduce memory requirements.
Regards,
Tomas
_______________________________________________
viff-devel mailing list (http://viff.dk/)
[email protected]
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk
