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.

Sign up for GitHub

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

Jump to bottom

Replace big.Int with uint256.Int #1581

Open
roman-khimov opened this issue Dec 1, 2020 · 3 comments · May be fixed by #2928
Open

Replace big.Int with uint256.Int #1581

roman-khimov opened this issue Dec 1, 2020 · 3 comments · May be fixed by #2928
Labels
dependencies Dealing with project dependencies enhancement Improving existing functionality I4 No visible changes performance More of something per second S2 Regular significance U4 Nothing urgent

Comments

@roman-khimov
Copy link
Member

There is a promising library that we could reuse for our integer types (both in VM and native contracts): https://github.com/holiman/uint256. We need to try it out, benchmark and compare with our current implementation.
@roman-khimov roman-khimov added performance More of something per second refactoring labels Sep 9, 2022
@roman-khimov
Copy link
Member Author

roman-khimov commented Dec 15, 2022 •
edited

For the first iteration we need to try keeping public RPC interfaces with *big.Int types, but use uint256 in the VM, full compatibility is important here. Then benchmark it with VM tests we have (Bench*) and neo-bench (of course unit tests must work too). Then we'll see if it's worth it, if yes, we can gradually expand usage of this type in other places.

@ZhangTao1596
Copy link
Contributor

ZhangTao1596 commented Feb 16, 2023 •
edited

For the first iteration we need to try keeping public RPC interfaces with *big.Int types, but use uint256 in the VM, full compatibility is important here.

You mean we use uint256 inside evm but big.Int in arguments of evm public methods?
What about util.Uint256?

@roman-khimov
Copy link
Member Author

util.Uint256 is just a fancy way to represent "big" (compared to Uint160) hash. See neo-project/neo#938 also. For numbers that are real numbers (in that they're used for some arithmetic operations) we use *big.Int now mostly. uint256 library is supposed to be faster, but many of our interfaces rely on big.Int and we can't just throw it away, hence the requirement to keep these interfaces for now, exploring how uint256 can help us at the same time (there are some benchmarks in the vm code).

ZhangTao1596 added a commit to ZhangTao1596/neo-go that referenced this issue Feb 24, 2023
@ZhangTao1596
vm: use uint256.Int (fixes nspcc-dev#1581)
4ab7d7a
ZhangTao1596 added a commit to ZhangTao1596/neo-go that referenced this issue Feb 24, 2023
@ZhangTao1596
vm: use uint256.Int (fixes nspcc-dev#1581)
69a23b9
@ZhangTao1596 ZhangTao1596 linked a pull request Feb 24, 2023 that will close this issue
Draft
ZhangTao1596 added a commit to ZhangTao1596/neo-go that referenced this issue Mar 1, 2023
@ZhangTao1596
vm: use uint256.Int (fixes nspcc-dev#1581)
7af24ce
ZhangTao1596 added a commit to ZhangTao1596/neo-go that referenced this issue Mar 3, 2023
@ZhangTao1596
vm: use uint256.Int (fixes nspcc-dev#1581)
45fecd3
@roman-khimov roman-khimov added U4 Nothing urgent enhancement Improving existing functionality S2 Regular significance I4 No visible changes dependencies Dealing with project dependencies and removed refactoring labels Dec 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
dependencies Dealing with project dependencies enhancement Improving existing functionality I4 No visible changes performance More of something per second S2 Regular significance U4 Nothing urgent
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Use uint256.Int in vm ZhangTao1596/neo-go
2 participants
@roman-khimov @ZhangTao1596