-
Notifications
You must be signed in to change notification settings - Fork 1k
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
speed up Uint160.CompareTo and Uint256.CompareTo function #552
Conversation
# Conflicts: # neo/Network/TcpRemoteNode.cs
@lightszero I didn't manage to merge with your local master branch... I think it's a permission problem, or perhaps your PR should be changed to another branch (other than lightszero:master). See: #553 Using that structure, four tests are done now:
All seem correct. Timings are similar too... current winner is original approach (2 or 1), although in one case lights approach was actually faster. |
test case data has some problem. make some equal data will be good. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add some UT for this change?
@shargon https://github.com/igormcoelho/neo/tree/benchmarks_uint |
now result is like this,with 50% equal data Elapsed=00:00:01.1170521 Sum=-1244 |
Congratulations @lightszero, you were right about 3 times faster:
So I guess we will keep |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Congratulations Lights!
@lightszero nice job, should we unroll the loop for the UInt160 as @igormcoelho suggested so it can take advantage of 64bit comparisons? |
Ok, tests are merged now: #553 |
I made this little optimization, lightszero#2 take a look please @lightszero |
totally agree. |
@lightszero can you propose a final version? |
uint* lpx = (uint*)px; | ||
uint* lpy = (uint*)py; | ||
//160 bit / 32 bit step -1 | ||
for (int i = (160 / 32 - 1); i >= 0; i--) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were going to unroll to use 1 uint
comparison and 2 ulong
comparisons instead of 5 uint
comparisons?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes,can do more test to find a fast way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we resolve this, @jsolman? Maybe we could add this change in another PR after another tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be switched later
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dismissed the review; this comment can be left open though while the PR can still be approved.
Maybe in an effort to maintain compatibility in the future should the dotnetcore2.x get support for big endian architecture, we should use |
Change requested was just a suggested improvement.
If we make |
I agree with you @shargon, all UInt should have internal byte[] |
If everyone thinks it's better with the protected data, I can make the changes |
@shargon let's merge this now and continue improving this in other PR. |
speed up bytes.CompareTo X3 times maybe more.