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

Small perf adjustments for ShortWeierstrassProjectivePoint operations #842

Merged

Conversation

tcoratger
Copy link
Contributor

Small perf adjustments for ShortWeierstrassProjectivePoint operations

Description

  • In the double operation, the pull request implements an early return strategy to check if self is the neutral element before performing any further calculations. If self is indeed the neutral element, the function immediately returns a clone of self. This optimization enhances performance by avoiding unnecessary computations, resulting in faster execution.

  • The pull request optimizes the operate_with_affine function by reordering the sequence of operations. Previously, the function performed certain calculations before checking if self or other were neutral elements. This resulted in unnecessary computation overhead. The pull request rectifies this by placing the neutral element check at the beginning of the function. If either self or other is the neutral element, the function terminates early, saving computational costs and improving overall efficiency.

Type of change

Please delete options that are not relevant.

  • Optimization

Checklist

  • Linked to Github Issue
  • Unit tests added
  • This change requires new documentation.
    • Documentation has been added/updated.
  • This change is an Optimization
    • Benchmarks added/run

@tcoratger tcoratger requested a review from a team as a code owner March 11, 2024 10:59
@MauroToscano
Copy link
Collaborator

I don't think the first optimization is right. The early return adds an additional branch, so it may make the average case slower, and we usually don't care about optimizing the neutral element case. You need to bench this and compare it, but I highly doubt the additional branch is worth.

@codecov-commenter
Copy link

codecov-commenter commented Mar 12, 2024

Codecov Report

Attention: Patch coverage is 87.50000% with 1 lines in your changes are missing coverage. Please review.

Project coverage is 72.32%. Comparing base (52042bf) to head (444379c).

Files Patch % Lines
math/src/elliptic_curve/short_weierstrass/point.rs 87.50% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #842      +/-   ##
==========================================
- Coverage   72.32%   72.32%   -0.01%     
==========================================
  Files         147      147              
  Lines       33820    33823       +3     
==========================================
+ Hits        24459    24461       +2     
- Misses       9361     9362       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@tcoratger
Copy link
Contributor Author

I don't think the first optimization is right. The early return adds an additional branch, so it may make the average case slower, and we usually don't care about optimizing the neutral element case. You need to bench this and compare it, but I highly doubt the additional branch is worth.

Here is the benchmark for the double case (for the general situation):

  • Before:
point Projective Double | Lambdaworks
                        time:   [364.85 ns 364.97 ns 365.09 ns]
Found 7 outliers among 100 measurements (7.00%)
  5 (5.00%) high mild
  2 (2.00%) high severe
  • After:
point Projective Double | Lambdaworks
                        time:   [364.55 ns 365.17 ns 366.33 ns]
                        change: [-0.1313% +0.0010% +0.1993%] (p = 1.00 > 0.05)
                        No change in performance detected.
Found 10 outliers among 100 measurements (10.00%)
  4 (4.00%) high mild
  6 (6.00%) high severe

@entropidelic entropidelic added this pull request to the merge queue Mar 22, 2024
@entropidelic entropidelic removed this pull request from the merge queue due to a manual request Mar 22, 2024
@entropidelic entropidelic added this pull request to the merge queue Mar 22, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Mar 22, 2024
@tcoratger
Copy link
Contributor Author

@entropidelic Let me know if there is something to do here

@diegokingston diegokingston added this pull request to the merge queue Oct 1, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Oct 1, 2024
@diegokingston diegokingston added this pull request to the merge queue Oct 4, 2024
Merged via the queue into lambdaclass:main with commit e25a464 Oct 4, 2024
7 of 8 checks passed
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.

6 participants