Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Created dummy entry generator for benchmark #273

Merged
merged 6 commits into from
Mar 12, 2024
Merged

Created dummy entry generator for benchmark #273

merged 6 commits into from
Mar 12, 2024

Conversation

sifnoc
Copy link
Member

@sifnoc sifnoc commented Mar 7, 2024

  • The current benchmark is limited by its capacity to handle polynomials for a relatively small number of users, specifically generating proofs for only 16 or 64 users in its benchmarking code. To address this limitation, it is necessary to dynamically initialize entries based on the specified number of users, N_USERS, instead of relying on entry data from a CSV file, which constrains us to a fixed user count.
  • Fixed the number of user, N_USERS in the benchmark code, kzg.rs with maximum number of user within given K
  • Also, Replaced N_ASSETS to N_CURRENCIES

@sifnoc sifnoc requested a review from alxkzmn March 7, 2024 12:03

// Demonstrating that a higher value of K has a more significant impact on benchmark performance than the number of users
#[cfg(not(feature = "no_range_check"))]
{
const K: u32 = 18;
const N_USERS: usize = 16;
const N_USERS: usize = (1 << 17) + (1 << 16) - 6;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you try to replace it with 2^K-6?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And if it works, apply it everywhere throughout the benchmark.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, that is worked. Similarly, we can apply this to N_POINTS as follows:

const N_POINTS = N_CURRENCIES + 1;


// Demonstrating that a higher value of K has a more significant impact on benchmark performance than the number of users
#[cfg(not(feature = "no_range_check"))]
{
const K: u32 = 18;
const N_USERS: usize = 16;
const N_USERS: usize = (1 << 17) + (1 << 16) - 6;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And if it works, apply it everywhere throughout the benchmark.

@@ -59,7 +58,7 @@ fn bench_kzg<

let mut entries: Vec<Entry<N_CURRENCIES>> = vec![Entry::init_empty(); N_USERS];
let mut cryptos = vec![Cryptocurrency::init_empty(); N_CURRENCIES];
parse_csv_to_entries::<&str, N_CURRENCIES>(csv_path, &mut entries, &mut cryptos).unwrap();
let _ = generate_dummy_entries(&mut entries, &mut cryptos);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think let _ is unnecessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is for warning, but this one would be fix with for #273 (comment)


// This is for testing purposes with a large dataset instead of using a CSV file
pub fn generate_dummy_entries<const N_CURRENCIES: usize>(
entries: &mut [Entry<N_CURRENCIES>],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case it should be ok to return the (entries, currencies) from the function instead of passing in and filling the mutable arrays (which is used in parser to save the memory).

@sifnoc sifnoc requested a review from alxkzmn March 11, 2024 03:35

// Demonstrating that a higher value of K has a more significant impact on benchmark performance than the number of users
#[cfg(not(feature = "no_range_check"))]
{
const K: u32 = 18;
const N_USERS: usize = 16;
const N_USERS: usize = 2usize.pow(K - 1) + 2usize.pow(K - 2) - 6; // Which is equal to (1 << 17) + (1 << 16) - 6
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain the value 2^(K-1)-2^(K-2)-6? Why in the case of K=17 you're using 2^(K-1)-6?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the correct max value should be 2^K - 6.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unable to provide a clear explanation for the failure of the $2^K - 6$ benchmark. Attempting to run it resulted in an error: 'vk generation should not fail: NotEnoughRowsAvailable { current_k: 17 }'.

Copy link
Member Author

@sifnoc sifnoc Mar 11, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has led me to believe that the maximum value for N_USER might be within the range between $2^{(K - 1)}$ and $2^K - 6$.

Copy link
Contributor

@alxkzmn alxkzmn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the correct max value for the number of users in the circuit should be 2^K-6.

Copy link
Contributor

@alxkzmn alxkzmn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The maximum possible number of entries should be determined in #274.

@sifnoc
Copy link
Member Author

sifnoc commented Mar 12, 2024

Updated the maximum number of entries at here 3489dd1
The maximum N_USER is $2^{K} - 2^{16} - 6$

@sifnoc sifnoc merged commit 69505f2 into v2 Mar 12, 2024
6 checks passed
@sifnoc sifnoc deleted the v2-dummmy-entries branch March 12, 2024 08:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants