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

Issue with runtime_observation_count #756

Closed
lqwk opened this issue Aug 15, 2022 · 1 comment
Closed

Issue with runtime_observation_count #756

lqwk opened this issue Aug 15, 2022 · 1 comment
Assignees
Labels
Question Further information is requested

Comments

@lqwk
Copy link
Contributor

lqwk commented Aug 15, 2022

❓ Questions and Help

As mentioned in our previous communications, I tried adding debugging logs into the code to print out the runtime_observation_count and corresponding callstacks to debug why we are seeing only 1 observation for starting runtimes.

See the debug logs in this branch.

Repro

The command I tested this with is:

python -m llvm_autotuning.tune -m \
    experiment=my-exp \
    outputs=/tmp/logs \
    executor.cpus=32 \
    num_replicas=1 \
    autotuner=nevergrad \
    autotuner.optimization_target=runtimeseries \
    autotuner.search_time_seconds=120 \
    benchmarks=single_benchmark_for_testing

and I got the following logs

Details

  • I verified that the runtime_observation_count is setup properly when we create the optimization target: debug logs

  • I saw that the previous_runtimes had a correct number of observations of 30 but during reset, the observation count was 1: debug logs and I couldn't figure out why.

  • I also saw that there was a time when the runtime_observation_count was set to 1: debug logs. The logs of the corresponding callstack is also printed here.

@lqwk lqwk added the Question Further information is requested label Aug 15, 2022
@ChrisCummins
Copy link
Contributor

Hey, I'm going to need your help debugging this, as logs and stacktraceds aren't useful to me without knowing the details of your code, and the repro command requires changes that aren't in upstream CompilerGym.

Could you please reduce your repro example to a standalone snippet of code that runs against an unmodified CompilerGym package and demonstrates the issue? Then I can run it on my end and see what the underlying problem is.

Cheers,
Chris

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants