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

Optimize TotalWrapper #64

Merged
merged 6 commits into from
Oct 15, 2024
Merged

Conversation

isaacl
Copy link
Member

@isaacl isaacl commented Oct 12, 2024

Because of the use of evidence, the types for TotalWrapper are not being elided, leading to 10-15 JVM instruction methods for OpaqueInt::atMost. This is especially problematic because these methods are tagged 'inline', so they are significantly increasing size of the methods which use OpaqueInts.

I've verified these changes now correctly elide types entirely, but this implementation is extremely fragile. Because scala sees evidence for conversion, it will implicitly use the evidence given a chance, which we don't want.

The best I could come up with is a scary warning. :-\

@isaacl isaacl force-pushed the optimizeTotalWrapper branch from 24d41a0 to ec0466a Compare October 14, 2024 19:09
@isaacl isaacl changed the title WIP Optimize TotalWrapper Optimize TotalWrapper Oct 14, 2024
@isaacl isaacl marked this pull request as ready for review October 14, 2024 19:12
@isaacl
Copy link
Member Author

isaacl commented Oct 14, 2024

ready for review, I guess

@isaacl isaacl force-pushed the optimizeTotalWrapper branch from ec0466a to b5ed135 Compare October 14, 2024 19:19
Because of the use of evidence, the types for TotalWrapper
are not being elided, leading to 10-15 JVM instruction methods
for OpaqueInt::atMost.  This is especially problematic because these
methods are tagged 'inline', so they are significantly increasing
size of the methods which use OpaqueInts.

I've verified these changes now correctly elide types entirely,
but this implementation is extremely fragile. Because scala sees
evidence for conversion, it will implicitly use the evidence given
a chance, which we don't want.

The best I could come up with is a scary warning. :-\
@isaacl isaacl force-pushed the optimizeTotalWrapper branch from b5ed135 to 2ba4f3b Compare October 14, 2024 19:25
@isaacl
Copy link
Member Author

isaacl commented Oct 14, 2024

I also looked at whether using @specialized made any difference here, after noticing that the Eq implementation had it.
As far as I can tell, it doesn't make a difference. So I didn't add it.

@lenguyenthanh
Copy link
Member

Scala 3 hasn't implemented specialized yet.

They are used in lila.
Add back `OpaqueInt`::`unary_-` which got removed accidentally
during experimentation.
- Add extension methods similar to OpaqueInt
@isaacl isaacl force-pushed the optimizeTotalWrapper branch from 92689a3 to b2ee2f5 Compare October 14, 2024 21:58
@ornicar
Copy link
Collaborator

ornicar commented Oct 15, 2024

great explanation in the source comment!

@ornicar ornicar merged commit 9f63ff6 into lichess-org:master Oct 15, 2024
1 check passed
ornicar added a commit to lichess-org/lila that referenced this pull request Oct 15, 2024
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.

3 participants