n must be smaller than the index type max value

[ShallMate]

Professor, I recently learned to run OKVS in RR22. When I run the function perfPaxosImpl<8>. I use -n 1000000 to try to build an OKVS with n=1000000. But it told me: n must be smaller than the index type max value. How to solve this?

[ShallMate]

Ok, I should use <32> or <64> to run it. But I don't quite understand why? Professor can you explain briefly? In addition, my running time is about 3.5 seconds, which is not very consistent with the paper. Do I need to set anything?

[ladnir]

Running time? Use silver... Read the program command line help info.

Okvs with u8? As an optimization you can use a u8 as an index for the okvs. As such, your index can have values between 0 and 255. This works great if you don't exceed this range. However, n=1000000 clearly would require indexing beyond this. u32 should always work. In some cases u16 should work.

Smaller index get better running time due to it taking up less memory and getting better cache utilization.

[ShallMate]

OK, Professor. But are Silver and OKVS also connected? What I read in the paper is that Silver is the encoding of VOLE. But what I want to run is OKVS. If I run PSI, then I can directly use setMultType(oc::MultType::slv5) to make Silent VOLE use Silver encoding. But I just want to run the encoding and decoding of OKVS, is this also related to Silver? Because I actually just run perfPaxosImpl(cmd), and its total running time is 3.5 seconds. If Silver can also optimize OKVS, then how can I set the encoding of OKVS to Silver, just like setMultType(oc::MultType::slv5).

[ladnir]

Silver is not related to okvs. If you want okvs then you can forget about silver. You should use Baxos, not Paxos.

[ladnir]

Silver makes the psi faster. Baxos makes the paxos faster. Baxos is paxos with with the binning optimization

[ShallMate]

But, prof. I also tried running the perfBaxos function, which is supposed to run Baxos. but. It still takes me about 3.3 seconds to complete -n 1000000 encoding and decoding. is this normal? Because the whole PSI doesn't take so long, does it? But this is just a sub-process of PSI.

[ladnir]

No, that doesn't seem normal. Hard to say what the problem is...

You can add -v to see if encode or decode is slow.

PS, I'm not a professor ;)

[ShallMate]

OK, I'll try again with -v. By the way, what should I call you? thanks for your help.

[ShallMate]

Hello, let me call you Dr. Peter for now. I used -v parameter. Got the following result. Does this show where the problem is?

[ladnir]

No ha. Are you on a slow computer? Did you build with debug?

[ShallMate]

No, I'm not running on a very slow computer. Because I only want to run OKVS, and I have installed libOTE and related dependencies locally. I directly separated the source code part of OKVS from volePSI. That is, OKVS is compiled separately, but I don't think this should have an impact on performance, right? Like the following.

[ladnir]

When you built libOTe was sse enabled? You can see this by calling the libOTe build.py and look for ENABLE_SSE.

Did you build your code in release mode?

[ShallMate]

I executed cmake -DCMAKE_BUILD_TYPE=Release . . Then the time was shortened to 0.7s, thank you very much. This is comparable to the efficiency of OKVS in non-clustering mode in the paper. Is clustering not working? Can I start clustering with enable SSE when compiling libOTE?

[ladnir]

Clustering is Baxos.

Sse just makes it faster in general.

[ShallMate]

OK, thank you very much. Dr. Peter.

[ShallMate]

Dr. Peter. I have recompiled libOTE with -DENABLE_SSE=ON. The running time of perfBaxos dropped to 0.5s. It still looks slower than the experimental results in the paper, but it is also much faster than the beginning, thank you. There is that I use -DENABLE_SSE=ON to enable SSE, which is correct? Do I need -DENABLE_MRR_TWIST=ON? Because I found that in many places in the libOTE source code, it seems that ENABLE_MRR_TWIST must be enabled to enable ENABLE_SSE.