data61
from sint to sbitvec
Describe the result Hello, I run the code below: y = sint(5) x = sbitvec(y, 3, 3) print_ln('%s', [x.v[0].reveal(), x.v[1].reveal(), x.v[2].reveal()])
and it takes 200s (including offline time). I want to know if this is running normally or if there is a problem with my settings.
It takes 12 seconds on my laptop. Which version are you using, and which hardware?
The version I am using is mp-spdz 0.4.0. Command: ./compile.py test ./mascot-party.x -N 2 -I -p 0 test ./mascot-party.x -N 2 -I -p 1 test And it runs on a virtual machine and is configured with 4 cores (vCPU) and 8 GiB
Are you using VirtualBox? There is a known performance issue there: https://mp-spdz.readthedocs.io/en/latest/troubleshooting.html#windows-virtualbox-performance
It doesn't work. And the output is: [1, 0, 1] Compiler: ./compile.py testgc -Y 86 triples of Tinier left 76 triples of SPDZ gfp left Significant amount of unused triples of SPDZ gfp distorting the benchmark. For more accurate benchmarks, consider reducing the batch size with --batch-size. ~1023 edaBits of size 3 left Significant amount of unused edaBits of size 3. This protocol has a large minimum batch size, which makes this unavoidable for small programs. ~1023 edaBits of size 40 left Significant amount of unused edaBits of size 40. This protocol has a large minimum batch size, which makes this unavoidable for small programs. 1020 triples of Tinier left Significant amount of unused triples of Tinier distorting the benchmark. This protocol has a large minimum batch size, which makes this unavoidable for small programs. Detailed costs: 2129 integer inputs 100829 integer openings Spent 3.11756 seconds (0.00054 MB, 21 rounds) on the online phase and 238.716 seconds (25395.3 MB, 129718 rounds) on the preprocessing/offline phase. Communication details: Broadcasting 1.58768 MB in 63805 rounds, taking 4.94915 seconds Exchanging one-to-one 22867.4 MB in 804 rounds, taking 28.8209 seconds Receiving directly 16.7831 MB in 16151 rounds, taking 1.22507 seconds Receiving one-to-one 2509.22 MB in 8615 rounds, taking 6.16236 seconds Sending directly 14.585 MB in 16126 rounds, taking 0.285591 seconds Sending one-to-one 2509.22 MB in 8615 rounds, taking 0.856656 seconds Sending to all 2.19814 MB in 25 rounds, taking 0.00137091 seconds Sending/receiving 0.249568 MB in 15598 rounds, taking 0.571096 seconds CPU time = 227.135 The following benchmarks are including preprocessing (offline phase). Time = 241.866 seconds Data sent = 25395.3 MB in ~129739 rounds (party 0 only) Global data sent = 50790.5 MB (all parties) Actual cost of program: 1 Input tuples (1 0) Type bit 6 Triples edaBits 1 of length 3 (strict) 1 of length 40 (strict) Coordination took 0.205979 seconds Coordination took 2.81251 seconds
I'm afraid I still cannot reproduce this. I have downloaded the 0.4.0 release, and I'm getting the following output:
Using statistical security parameter 40
[1, 0, 1]
Significant amount of unused edaBits of size 3. This protocol has a large minimum batch size, which makes this unavoidable for small programs.
Significant amount of unused edaBits of size 40. This protocol has a large minimum batch size, which makes this unavoidable for small programs.
Significant amount of unused triples of Tinier distorting the benchmark. This protocol has a large minimum batch size, which makes this unavoidable for small programs.
The following benchmarks are including preprocessing (offline phase).
Time = 10.7153 seconds
Data sent = 780.797 MB in ~3433 rounds (party 0 only; use '-v' for more details)
Global data sent = 1561.59 MB (all parties)
There is considerably less communication. Particularly, there is no mention of input tuples being used. Can you confirm that it still happens with a fresh download of any release? Furthermore, what is the output of the compilation?
I download mp-spdz-0.4.1. The output of the compilation: ./compile.py -Y testgc
Default bit length for compilation: 64
Default security parameter for compilation: 40
Compiling file Programs/Source/testgc.mpc
Writing to Programs/Schedules/testgc.sch
Writing to Programs/Bytecode/testgc-0.bc
Hash: 4129f0f997b731fdf2303ac3f3be1586a5c678047879692210fd9f2f33c330b7
Program requires at most:
1 strict edabits of length 40
1 strict edabits of length 3
1 integer opens
2 bit triples
4 virtual machine rounds
And it also takes 200s. The output is as follows:
Using statistical security parameter 40
Setup took 0.0380388 seconds.
[1, 0, 1]
Compiler: ./compile.py -Y testgc
86 triples of Tinier left
76 triples of SPDZ gfp left
Significant amount of unused triples of SPDZ gfp distorting the benchmark. For more accurate benchmarks, consider reducing the batch size with --batch-size.
~1023 edaBits of size 3 left
Significant amount of unused edaBits of size 3. This protocol has a large minimum batch size, which makes this unavoidable for small programs.
~1023 edaBits of size 40 left
Significant amount of unused edaBits of size 40. This protocol has a large minimum batch size, which makes this unavoidable for small programs.
1024 triples of Tinier left
Significant amount of unused triples of Tinier distorting the benchmark. This protocol has a large minimum batch size, which makes this unavoidable for small programs.
Detailed costs:
2128 integer inputs
100829 integer openings
Spent 0.00151466 seconds (0.000435 MB, 17 rounds) on the online phase and 242.633 seconds (25418.2 MB, 6326 rounds) on the preprocessing/offline phase.
Communication details:
Broadcasting 0.069152 MB in 2109 rounds, taking 1.63941 seconds
Exchanging one-to-one 22867.4 MB in 804 rounds, taking 34.3243 seconds
Receiving directly 16.6218 MB in 725 rounds, taking 0.43369 seconds
Receiving one-to-one 2534.11 MB in 903 rounds, taking 7.57955 seconds
Sending directly 14.4238 MB in 701 rounds, taking 0.0258165 seconds
Sending one-to-one 2534.11 MB in 903 rounds, taking 1.52764 seconds
Sending to all 2.19804 MB in 24 rounds, taking 0.00220287 seconds
Sending/receiving 0.002784 MB in 174 rounds, taking 0.00712242 seconds
CPU time = 233.389
The following benchmarks are including preprocessing (offline phase).
Time = 242.709 seconds
Data sent = 25418.2 MB in ~6343 rounds (party 0 only)
Global data sent = 50836.4 MB (all parties)
Actual preprocessing cost of program:
Type bit
2 Triples
edaBits
1 of length 3 (strict)
1 of length 40 (strict)
Coordination took 0.027285 seconds
Coordination took 0.0292511 seconds
Command line: ./mascot-party.x -N 2 -I -p 0 testgc -v
How did you obtain the binary? Did you compile the C++ code? If so, did you change anything in CONFIG or CONFIG.mine?
I see. This is a major cost factor as the communication grows quadratically in the modulus length, and your choice enables a prime modulus of about 800 bits. If that wasn't your intention, you should remove this and recompile. Otherwise, cowgear-party.x might be a better choice in terms of efficiency.
Sorry, I have another problem. I found from sint to sbitvec may take 0.0015 seconds online and 10 seconds offline. Is it possible to perform offline operations in advance and then execute the /Mascot party. x - N 2- I - p 0 test only requires online time to complete.
You can achieve this using separate preprocessing with mascot-offline.x: https://mp-spdz.readthedocs.io/en/latest/readme.html#preprocessing-as-required
If you're only interested in the online phase benchmark, you can also skip the offline phase benchmark entirely: https://mp-spdz.readthedocs.io/en/latest/readme.html#online-only-benchmarking
I have used mascot-offline.x before mascot-party.x. But after using the mascot-offline.x, executing the /Mascot party. x - N 2- I - p 0 test still needs 10 seconds offline.
I have encountered another problem. I use ./Fake-Offline.x 2 -e 256,
then execute
./mascot-party.x -F -N 2 -p 0 testgc
./mascot-party.x -F -N 2 -p 1 testgc
However, the output is as follows:
Using statistical security parameter 40 Fatal error at testgc-0:9 (SEDABIT): error opening Player-Data//2-p-832/edaBits-256-P1, have you generated edaBits, for example by running './Fake-Offline.x -e 256 ...'?
the CONFIG.mine is
MOD = -DGFP_MOD_SZ=13 MY_CFLAGS += -DINSECURE
When I use Fake-Offline.x in the scenario of four parties, it doesn't work. I found there are several files in the 2-p-832 folder, including edabits-256-P0 and so on. But there are only 5 files in the 4-p-832 folder, just including params data file and MAC keys for four parties.
For two parties, I use ./Fake-Offline.x 2 -e 256
For four parties, I use ./Fake-Offline.x 4 -e 256
When I use ./Fake-Offline.x 4 -e 256, I found that the output does not include 4-p-832 files.
Then I use ./Fake-Offline.x 4 -e 256 -lgp 832, the output is
WARNING: insecure preprocessing Writing to file in Player-Data//4-p-832/ terminate called after throwing an instance of 'wrong_gfp_size' what(): gfpvar_<X, L> wrong size for modulus 14319451959237480602209391966837419245360869586085326264720724851155532002676452079672642132912314187714679754609499860037198430378536688350222513020782289810256437153989606051133400630739489388122520004115872623737965276803368791807679393553237147777. Maybe change MAX_MOD_SZ to 26. Aborted (core dumped)
This means you have to put MY_CFLAGS += -DMAX_MOD_SZ=26 in CONFIG.mine and then run make Fake-Offline.x.