You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue was already mentioned in benchmark folder itself, see more info in that folder's README, but basically
'logrow' can be chosen arbitrarily between min(log_2(number of rows), log_2(lookup range)) to max(log_2(number of rows), log_2(lookup range)). The trade off is that if we choose lower logrow value , we will face with more "columns for non-linearity table".
For now, based on our experiment, the best value to select logrow is to select the lowest logrow in the range such that ceiling(lookup_range/2^logrow) <=5
Hence,
We should incorporate this optimization into zkstats itself natively
Due to some changes in zkstats flow from merging PR#34, we should update our benchmark folder accordingly
The text was updated successfully, but these errors were encountered:
This issue was already mentioned in benchmark folder itself, see more info in that folder's README, but basically
'logrow' can be chosen arbitrarily between min(log_2(number of rows), log_2(lookup range)) to max(log_2(number of rows), log_2(lookup range)). The trade off is that if we choose lower logrow value , we will face with more "columns for non-linearity table".
For now, based on our experiment, the best value to select logrow is to select the lowest logrow in the range such that ceiling(lookup_range/2^logrow) <=5
Hence,
The text was updated successfully, but these errors were encountered: