[EMAIL PROTECTED] writes:

> Quoting Mikkel Krøigård <[EMAIL PROTECTED]>:
>
>> Citat Martin Geisler <[EMAIL PROTECTED]>:
>>
>> > I've looked at the GMPY code, and it is a fairly straightforward
>> > wrapper for the GMP library, as you describe.
>> >
>> > But I don't know if it makes it easier for us to benchmark just
>> > because it is split into its own C code...
>>
>> I never said it would. If you use this approach, it is easy to see
>> how much is spent on the dangerous arithmetic, but I guess a
>> profiler could tell you how much time Python spends on the
>> functions implementing the operators anyway.
>
> If that's the case, then it doesn't make sense w.r.t. the profiling
> to use GMPY. I was assuming the profiler could not give you
> information that was so fine-grained.

Some time ago I build in support for the normal Python profiler in all
VIFF programs, so if you run the benchmark with --profile you get
results like this for 4000 multiplications:

         889364 function calls (762586 primitive calls) in 17.830 CPU seconds

   Ordered by: internal time, call count
   List reduced from 192 to 40 due to restriction <40>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
         44    7.350    0.167   12.177    0.277 selectreactor.py:82(doSelect)

The line above says that the internal time spend on 44 calls to
doSelect was 7.35 seconds. The cumtime includes time spend in
functions called from doSelect, most importantly the actual select
call done there. I interpret this to mean that the program slept for 5
seconds (12 - 7 = 5) out of the 18 seconds it ran.

First one should note that this sleeping includes the 3 second
countdown done by the benchmark and the time it takes for the programs
connect to each other initially (the data is for Player 3/3 and this
player waits for Player 1 and 2).

Second, the profiling slows things down -- I'm not sure exactly how
much, but maybe with a factor or 2. So it is the relative numbers
which are important.


70684/41342    2.330    0.000    8.669    0.000 defer.py:306(_runCallbacks)
       6666    0.648    0.000    1.768    0.000 shamir.py:30(share)

This player did a total of 6666 Shamir sharings: it was responsible
for 8000/3 = 2666 of the initial 8000 Shamir sharings, and then it did
4000 resharings as part of the secure multiplications.

      36007    0.601    0.000    0.765    0.000 field.py:371(__mul__)

This is the overloaded multiplication operator for field elements, the
one in pure Python code.

85360/41360    0.543    0.000    5.057    0.000 defer.py:168(addCallbacks)
     104021    0.427    0.000    0.427    0.000 field.py:339(__init__)

Total number of field elements created: 104021. This includes very
short-lived objects created from an expression like "x + y + z" where
"x + y" create a temporary field element which is then added to z.

      13338    0.364    0.000    0.798    0.000 runtime.py:627(_expect_share)
      31998    0.358    0.000    0.483    0.000 field.py:342(__add__)

Additions in the field. The Shamir sharing and recombination does
addition.

       8004    0.319    0.000    1.615    0.000 runtime.py:203(__init__)
       4000    0.275    0.000    0.708    0.000 shamir.py:95(recombine)

This is the time it takes to recombine 4000 Shamir shares.

      13340    0.263    0.000    4.463    0.000 runtime.py:286(stringReceived)
       8000    0.251    0.000    1.538    0.000 runtime.py:1041(shamir_share)

The time it took to do the initial Shamir sharing of 8000 numbers.

         48    0.249    0.005    4.712    0.098 basic.py:345(dataReceived)
28015/21342    0.234    0.000    4.212    0.000 defer.py:283(_startRunCallbacks)
49350/21350    0.226    0.000    4.613    0.000 defer.py:185(addCallback)
28015/21342    0.216    0.000    4.381    0.000 defer.py:229(callback)
20002/12002    0.212    0.000    7.126    0.001 runtime.py:372(inc_pc_wrapper)

Program counter book-keeping.

      28010    0.196    0.000    0.403    0.000 runtime.py:80(__init__)
      13338    0.190    0.000    0.347    0.000 abstract.py:164(write)
32006/28004    0.171    0.000    1.420    0.000 runtime.py:227(_callback_fired)
      13338    0.170    0.000    0.170    0.000 runtime.py:593(_expect_data)
      12006    0.159    0.000    1.238    0.000 runtime.py:611(_exchange_shares)
       4000    0.155    0.000    2.674    0.001 runtime.py:1025(_shamir_share)
       9332    0.141    0.000    0.270    0.000 random.py:148(randrange)
       9332    0.129    0.000    0.129    0.000 random.py:218(_randbelow)
      13338    0.120    0.000    0.467    0.000 basic.py:357(sendString)
      13336    0.118    0.000    0.585    0.000 runtime.py:325(sendData)
       4000    0.112    0.000    5.460    0.001 runtime.py:791(mul)
       8000    0.109    0.000    4.392    0.001 
runtime.py:553(schedule_callback)
      13338    0.078    0.000    0.124    0.000 runtime.py:629(<lambda>)
      13343    0.078    0.000    0.157    0.000 tcp.py:260(startWriting)
          1    0.076    0.076    1.961    1.961 benchmark.py:182(begin)
       8000    0.072    0.000    3.809    0.000 runtime.py:573(callback_wrapper)
      28014    0.069    0.000    0.069    0.000 defer.py:162(__init__)
         49    0.069    0.001    0.069    0.001 tcp.py:364(writeSomeData)
       4000    0.062    0.000    0.978    0.000 runtime.py:1076(_recombine)
          1    0.060    0.060    5.650    5.650 benchmark.py:230(run_test)
      13343    0.058    0.000    0.080    0.000 abstract.py:267(startWriting)
      13336    0.056    0.000    0.640    0.000 runtime.py:329(sendShare)
       9332    0.051    0.000    0.321    0.000 random.py:212(randint)

Let me know if you have ideas for other things to test, different ways
to sort and select output, etc...

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multi-Party Computation) to Python. See: http://viff.dk/.
_______________________________________________
viff-devel mailing list (http://viff.dk/)
[email protected]
http://lists.viff.dk/listinfo.cgi/viff-devel-viff.dk

Reply via email to