You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently, AutoTuner handles the GPU profiles.
In order to automatically map CPU configs to GPU configurations, we want to reuse the logic that is already defined in the AutoTuner.
Describe the solution you'd like
Refactor AutoTuner to support the logic for both Profiler/Qualification
Describe alternatives you've considered
Rewrite a separate Spark configuration mapper implies we have duplicate logic for tunining the configurations.
That's the main reason we should do it
The content you are editing has changed. Please copy your edits and refresh the page.
Signed-off-by: Ahmed Hussein (amahussein) <a@ahussein.me>
FixesNVIDIA#700
This is an incremental step toward the full automation of App migration to GPU.
- Add Qual arg `--auto-tuner` to toggle the AutoTuner module. Default is Off.
- Add Qual arg `--worker-info` to pass the GPU worker info to the Qual's AutoTuner.
- When AutoTuner is enabled, the Qual tool will launch the AutoTuner module to make some basic recommendations/comments based on the Spark/Env properties.
- A new folder `rapids_4_spark_qualification_output/tuning` is created which contains a text formatted file for each app. Each file is named after the AppID.
- No unit-tests is added for now because: 1- the recommendations are based on the Profiler's implementation; and the feature is disabled by default.
- There will be followup to incrementally split the logic of the AutoTuner into two classes that aim to tailor the rules/policies of the recommendations to the CPU applications.
Is your feature request related to a problem? Please describe.
Currently, AutoTuner handles the GPU profiles.
In order to automatically map CPU configs to GPU configurations, we want to reuse the logic that is already defined in the AutoTuner.
Describe the solution you'd like
Refactor AutoTuner to support the logic for both Profiler/Qualification
Describe alternatives you've considered
Rewrite a separate Spark configuration mapper implies we have duplicate logic for tunining the configurations.
That's the main reason we should do it
Tasks
The text was updated successfully, but these errors were encountered: