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

Add rand back #87

Open
burdges opened this issue Jun 12, 2023 · 2 comments
Open

Add rand back #87

burdges opened this issue Jun 12, 2023 · 2 comments

Comments

@burdges
Copy link
Collaborator

burdges commented Jun 12, 2023

Revert c333370 and fix rand. We've way less churn in rand today, and this syscall surely hurt performance ala paritytech/polkadot-sdk#732

@koute
Copy link
Collaborator

koute commented Jun 12, 2023

Whether this eats up a lot of performance or not very much depends on 1) how many calls we're making, and 2) which exact version of Linux the user's running (IIRC there were some performance optimizations done to getrandom).

Nevertheless, this is a good idea.

My runtime SIMD detection PR was recently merged in curve25519-dalek, so as soon as there's a new release I'll be making a PR switching to the new version and releasing a new schnorrkel. I can also take care of this issue then if you want. (Unless you want to do it yourself earlier.)

@burdges
Copy link
Collaborator Author

burdges commented Jun 12, 2023

Oh either way.

We've no reason for a separate rand feature I think. If getrandom works then ThreadRng works. As an aside, getrandom's custom feature should simplify life for possible cargo patch users (hardware wallets?), so afaik that's not a concern either.

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

No branches or pull requests

2 participants