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

Field for jit #1834

Merged
merged 63 commits into from
Oct 2, 2024
Merged

Field for jit #1834

merged 63 commits into from
Oct 2, 2024

Conversation

chriseth
Copy link
Member

@chriseth chriseth commented Sep 24, 2024

Very basic support for the fe type. It only supports up to 64 bits and no operations on the field element.

@chriseth chriseth changed the base branch from main to functions_as_expressions September 27, 2024 08:37
@chriseth chriseth marked this pull request as draft September 27, 2024 08:57
@chriseth chriseth marked this pull request as ready for review September 27, 2024 09:35
@chriseth chriseth marked this pull request as draft September 27, 2024 09:36
let f = compile(
"
namespace std::array;
let len = 8;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does len do in here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the degree of the main?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is std::array::len. It needs to be there, otherwise it is not found when it's used. The value does not matter because it's a built-in and is overwritten.

Base automatically changed from functions_as_expressions to main September 27, 2024 14:52
@chriseth chriseth marked this pull request as ready for review September 30, 2024 13:10
@chriseth chriseth mentioned this pull request Oct 1, 2024
#![allow(unused_parens)]

#[derive(Clone, Copy)]
struct FieldElement(u64);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we define it from scratch, instead of using the implementation we already have? Would it take too long to compile? Is there a plan to support larger fields?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are several possibilities, but I first wanted to check if JIT compilation is feasible at all. With the crate we currently use, it takes sooo much longer. Also, for the JIT it would be sufficient to use a crate that only supports one specific field, while our current number create supports all fields that we currently have.

The first milestone is being able to evaluate array expressions efficiently. For that, we do not need arithmetic on field elements.

Copy link
Member

@lvella lvella left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@leonardoalt leonardoalt added this pull request to the merge queue Oct 2, 2024
Merged via the queue into main with commit bc19641 Oct 2, 2024
14 checks passed
@leonardoalt leonardoalt deleted the field_for_jit branch October 2, 2024 09:36
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.

5 participants