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

Remove unstable features #417

Open
3 of 4 tasks
nbgl opened this issue Jan 3, 2022 · 3 comments
Open
3 of 4 tasks

Remove unstable features #417

nbgl opened this issue Jan 3, 2022 · 3 comments

Comments

@nbgl
Copy link
Contributor

nbgl commented Jan 3, 2022

We should work towards making Plonky2 compile on stable.

Unstable features that need to either be removed from Plonky2 or that need to be stabilized in Rust:

  • asm_sym Used in one asm! block but I can easily remove it and just pass a pointer.
  • generic_const_exprs Used by PackedField (in from_arr/to_arr); these methods can be removed, although having to do so will make me curse Rust's half-baked type system. I think it's also used in the plonky2 crate, but I'm not sure where.
  • specialization There are two traits that use this: Square and Packable. The default implementation of the former is just for convenience and can be removed. The latter has a default implementation so Rust can prove that every Field is Packable. We can remove the default impl if we merge both traits.
  • stdsimd Used for Neon support in Poseidon. Also used for packed AVX-512 arithmetic in AVX-512 packed Goldilocks #400. ARM Poseidon can be done in pure asm, removing the need for intrinsics. We can replace AVX-512 with AVX2 when compiling on stable, at a performance penalty.
@unzvfu
Copy link
Contributor

unzvfu commented May 10, 2023

Removed the generic_const_exprs feature from the field crate in #1020 and from the plonky2 crate in #1024.

@Nashtare
Copy link
Collaborator

Nashtare commented Aug 2, 2023

Would the EVM crate also be aimed for compiling on stable? If so, we'd need to remove the let_chains and generic_const_exprs features.
The first one would be easy to do, and perf. penalty (if any) by the two nested loops wouldn't be an issue as this is only used for building the Kernel. Removing the latter would be more painful though.

@eightfilms
Copy link
Contributor

I'm also assuming here that the same goal is desired in starky? But that means that Stark::COLUMNS and Stark::PUBLIC_INPUTS have to be removed.

eightfilms added a commit to 0xmozak/plonky2 that referenced this issue Oct 21, 2023
This PR mostly lifts 0xPolygonZero#1246
down into the lib level into the starky crate, getting rid of the
unstable `generic_const_exprs` feature from the crate entirely. This
should work towards the 0xPolygonZero#417
as well.

This would probably warrant a minor version bump in the starky crate to
0.2.0, since this would be an API change for anyone relying on starky.
@Nashtare Nashtare modified the milestones: Misc., System strengthening Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

4 participants