Unexpected behavior (high time) after sampling dabits

[abdelrahaman aly]

Hi Everybody,

I was wondering if you could help me with something. I have encountered an unexpected behavior, while working with the dabit instruction. Imagine the following:

I have a function that does this 3 simple steps:

 

* Sample, some 64 bits randomness using the dabits instruction (some r in mod 2 and mod p, and their respective bit expansions).

* Use it for masking, mod p. e.g. (c = sint(1) + r_p)

* An opening e.g., c.reveal() 

I can call the function 128 consecutive times, and it behaves as it should. However on the 129th call the opening would take several orders of magnitude more to be executed (although im not sure, it could be constant).  

I was wondering if somebody else has noticed something similar, and if you might have any advice. Any help is appreciated. 

Kr,

A.

For clarity you can also observe the following example of the above (mamba):

########## EXAMPLE ##########
def sampling():

'''

please use any custom implementation for 

get_random_from_dabit_list, that you might have,

if not I could provide one. '''

    r_p, R_p, r_2, R_2 = get_random_from_dabit_list(64) 
    c = sint(5) + r_p
    c_open= c.reveal()
    return c_open

limit =150
b = sint(-1)
d = sint(1)

#as advised to measure only the online time.

open_channel_with_return(0)
h = sint.get_private_input_from(0, 0)
f = b*d

start_timer(1)
counter = 0
for i in range(limit/10):
    start_timer(2+i)
    for j in range(10):
         counter = counter + 1
         if counter == 129:
             start_timer(70+j)
             sampling()
             stop_timer(70+j)
         else:
             sampling()
    stop_timer(2+i)
stop_timer(1)

[Nigel Smart]

dabits are produced in the *online* phase and in batches.
Hence at some point you get to a position where the *online*
phase stalls as it now needs to go get more. So are you
not sure that it is the getting dabits which takes a bit
longer and not the opening?

Nigel

On 09/12/2021 15:01, abdelrahaman aly wrote:
> Hi Everybody,
> I was wondering if you could help me with something. I have encountered
> an unexpected behavior, while working with the dabit instruction.
> Imagine the following:
>
> I have a function that does this 3 simple steps:

> * Sample, some 64 bits randomness using the dabits instruction (some /r/

> --
> You received this message because you are subscribed to the Google
> Groups "SPDZ/SCALE-MAMBA Discussion Group" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to spdz+uns...@googlegroups.com
> <mailto:spdz+uns...@googlegroups.com>.
> To view this discussion on the web, visit
> https://groups.google.com/d/msgid/spdz/a3d2f4b5-0495-4f7a-87e2-09cc8d4185e0n%40googlegroups.com
> <https://groups.google.com/d/msgid/spdz/a3d2f4b5-0495-4f7a-87e2-09cc8d4185e0n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[abdelrahaman aly]

Hi Nigel,

I see, that makes sense. If its done online, I guess there is not much that can be done. So to answer your question, say, I don't do the opening on iteration 129, its timing would be ok, but then this dead time would appear on the next timer. It maybe of course that I'm doing also something wrong, but at least that is what it seems like. 

Thanks so much for your answer,

Abdel

[abdelrahaman aly]

Sorry, I also forgot to ask, would it be possible to, say, change the size of the batches?

[titouan...@gmail.com]

Hi,

If I understood your code correctly you have a slowdown after sampling 128*64=8192 dabits, which indeed corresponds to the default number of dabits sampled in one batch.

You can try playing with the kdaBitsPerLoop defined in src/config.h .

If you encounter a bug while doing so do let me know!

Best,

Titouan

[abdelrahaman aly]

Thanks Titouan!

Super well spotted mate! Indeed changing the parameter, affects the behavior and moves the cost around... So yeah, indeed is this batch cost for dabits. I haven't seen any bug as of yet, but if I do I will ;).