n must be smaller than the index type max value about volepsi HOT 16 CLOSED

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?

from volepsi.

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.

from volepsi.

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).

from volepsi.

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

from volepsi.

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

from volepsi.

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.

from volepsi.

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 ;)

from volepsi.

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

from volepsi.

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

from volepsi.

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

from volepsi.

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.

from volepsi.

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?

from volepsi.

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?

from volepsi.

Clustering is Baxos.

Sse just makes it faster in general.

from volepsi.

OK, thank you very much. Dr. Peter.

from volepsi.

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.

from volepsi.