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

F* extraction hangs #1172

Open
franziskuskiefer opened this issue Dec 9, 2024 · 2 comments
Open

F* extraction hangs #1172

franziskuskiefer opened this issue Dec 9, 2024 · 2 comments
Assignees

Comments

@franziskuskiefer
Copy link
Member

franziskuskiefer commented Dec 9, 2024

The following crate can not get extract to F* with hax right now. It allocates a lot of memory and uses CPU cycles but does not seem to finish (I stopped it after 10 minutes).

use hmac::{Hmac, Mac};
use sha2::Sha256;

pub fn hmac() {
    let mut m = Hmac::<Sha256>::new_from_slice(&[13; 16]).unwrap();
    m.update(&[9; 32]);
    let _mac = m.finalize().into_bytes().to_vec();
}

Use cargo add hmac sha2 to add the required dependencies.

@W95Psp
Copy link
Collaborator

W95Psp commented Dec 9, 2024

I just took a look at that:

  • to find what is slow in the engine cargo hax into --profile BACKEND is helpful
  • the AST import is very slow, despite the JSON being somehow small (1.4M)

Details:

info: hax[profiling]: Other (parse_options): 1604.573815ms, memory=68416271, 1 item
info: hax[profiling]: AST import: 111876.683539ms, memory=36565152608, 8 items
info: hax[profiling]: reject_RawOrMutPointer: 11712.153839ms, memory=936238220, 8 items
info: hax[profiling]: TransformHaxLibInline: 13310.437220ms, memory=936242543, 8 items
info: hax[profiling]: Specialize: 11294.574264ms, memory=2557814909, 8 items
info: hax[profiling]: DropSizedTrait: 11630.991998ms, memory=2557806758, 8 items
info: hax[profiling]: SimplifyQuestionMarks: 12669.82560ms, memory=936238685, 8 items

Action items:

  • measure and trace functions in THIR import to understand what is that slow

@W95Psp W95Psp self-assigned this Dec 18, 2024
@W95Psp
Copy link
Collaborator

W95Psp commented Dec 19, 2024

I looked at this issue yesterday.
In import_thir, the slow part is not so much importing, but renaming local instance names.
The problem is not about this specific operation, but about visitors: types are repeated a lot, and visiting such an AST is slow.

This issue exists with every visitor and phase in the AST, and I'm not sure how to deal with that.

One thing I tried is getting rid of Sized constraints, but that was not enough. Also, I tried to memoize some nodes in the import phase, but that doesn't impact much the performances.

We may need to do some sort of automatic memoization in the visitors and/or the phases, but since OCaml is an effectful language, that might be hard to do.
The good news is since we generate ourselfs visitors, we can do whatever we want.

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