Open jimouris opened 5 years ago
Hmm, thanks for reporting this. It looks like this is caused by the ramput()
function calls in this example, which are compiled to constraints using a Merkle tree-based approach.
I'll try to look in to this more closely soon, but for now, you may want to check out this example, which is re-written to use a permutation network to compile computations that use RAM more efficiently.
Note that using this approach, there is no need to explicitly call a function like ramput()
. The compiler automatically handles ordinary statements which require a concept of RAM, such as an array access where the array index depends on the input to the computation. Section 3 of this paper has more information on how such constructs are compiled to constraints.
Thanks for the response. I was wondering why those ramput/ramget
commands were necessary, but it seems clear now. binary_search_fast.c
does the work for me, feel free to close the issue.
A follow-up question: are these ramput_fast
commands expected?
I could understand ramget_fast
's, as binary search incurs logSIZE number of random reads. However, after playing with parameters, it seems that binary_search_fast.c incurs the same number of ramput_fast
's as the length of the input array (SIZE, by default). Could we get rid of these ramput_fast
's? Asking because binary search has this nice logarithmic cost, the benefit of which will be gone if a linear number of ramput_fast
's are needed...
Hello,
bellow is the trace of command
./pepper_compile_and_setup_V.sh binary_search binary_search.vkey binary_search.pkey
:Other files (such as
mm_pure_arith
orbase_2_log
) run smoothly.Thanks in advance, Dimitris