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

[RFC] DietCode: An Auto-Scheduler for Dynamic Tensor Programs #72

Merged
merged 2 commits into from
May 31, 2022
Merged

[RFC] DietCode: An Auto-Scheduler for Dynamic Tensor Programs #72

merged 2 commits into from
May 31, 2022

Conversation

ArmageddonKnight
Copy link
Contributor

@ArmageddonKnight ArmageddonKnight changed the title Create 0072-dynamic-autoscheduler.md [RFC] DietCode: An Auto-Scheduler for Dynamic Tensor Programs May 12, 2022
@comaniac
Copy link
Contributor

As one of the co-authors, it glad to see this RFC finally out :)
cc @masahi @ZihengJiang @Laurawly @Hzfengsy @MasterJH5574 @jinhongyii please help review and share your thoughts. Thanks.

@junrushao
Copy link
Member

We are more than happy to collaborate on AutoTIR side to make good things happen :-)

Copy link
Member

@junrushao junrushao left a comment

Choose a reason for hiding this comment

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

LGTM

@areusch
Copy link
Contributor

areusch commented May 17, 2022

hey guys, thanks for the RFC! would you guys be up for doing a short walkthrough of it at a Community Meeting?

@comaniac
Copy link
Contributor

@ArmageddonKnight we might present/demo DietCode and introduce this RFC in a community meeting. Maybe in 5/25 or 6/1?

@ArmageddonKnight
Copy link
Contributor Author

@areusch @comaniac Sure. I would be happy to. I will be traveling on 6/1 so 5/25 looks good.

@areusch
Copy link
Contributor

areusch commented May 19, 2022

@ArmageddonKnight @comaniac ok--let me do some agenda shuffling (we now have 3 topics for that meeting) and hopefully we can accommodate your travel schedule here.

@junrushao
Copy link
Member

junrushao commented May 20, 2022

it’s definitely legit ask, but I would love to remind that as apache preferred approach, it would be better if technical discussion remains in an achievable way, so that the door is always open for all community participants to understand the technical discussion without having to appear at certain meeting at a certain time point (like early in the morning 😂) :-)

Perhaps it would be helpful if we take meeting notes and publicize it somewhere to help people who cannot join the meeting?

@areusch
Copy link
Contributor

areusch commented May 23, 2022

@junrushao1994 yep, we will post meeting notes here per the TVM Community Meeting guidelines.

@areusch
Copy link
Contributor

areusch commented May 24, 2022

@ArmageddonKnight just confirming, we have you on the agenda to discuss tomorrow

@ArmageddonKnight
Copy link
Contributor Author

@areusch Thank you for the reminder. I have put that on my calendar.

@ArmageddonKnight
Copy link
Contributor Author

@areusch BTW, may I ask whether there is anything I should prepare for the meeting? Alternatively, any particular thing that the community might be interested in? How much time am I given for the presentation?

Copy link
Contributor

@areusch areusch left a comment

Choose a reason for hiding this comment

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

adding a couple of questions here based on my understanding from the community meeting this morning

rfcs/0072-dynamic-autoscheduler.md Outdated Show resolved Hide resolved
rfcs/0072-dynamic-autoscheduler.md Outdated Show resolved Hide resolved
rfcs/0072-dynamic-autoscheduler.md Show resolved Hide resolved
rfcs/0072-dynamic-autoscheduler.md Show resolved Hide resolved
rfcs/0072-dynamic-autoscheduler.md Show resolved Hide resolved
rfcs/0072-dynamic-autoscheduler.md Show resolved Hide resolved
@areusch
Copy link
Contributor

areusch commented May 25, 2022

We discussed this at the TVM Community Meeting this morning. Here are notes (thanks to mbs-octoml for taking these):

  • Most discussion was around whether the approach could help the related
    problem of long training time and a large number of distinct kernels
    for fully statically-shaped models. Eg resnet50 with its dozens of
    static shape instances for conv2d.

    It is useful to consider kernel compilation in two steps:

    • Start with the N instances of the same operator, with different
      shapes.
    • After tuning those independently, may end up with M << N schedules.
    • However, each schedule is instantiated for the original static shape
      so that no dimension variables are left behind at run time,
      thus we are back at N implementations.

    There's a significant perf impact to having only M kernel implementation
    which retain their parameterization on dimension variables. However, TVM
    could support not doing that inlining today.

    DietCode could be used to reduce M. The learned decision tree would dispatch
    from a fully shape polymorphic implementation to the specific schedule
    implementation. But at this stage the focus is on dynamic shape workloads.

  • No changes to Relay are required. Though Relay's dynamic shape functions
    support data-dependent output shapes, currently DietCode does not search
    over output shape and assumes only input shapes need to be inspected. But
    sounds like this could be addressed in future work.

@ArmageddonKnight
Copy link
Contributor Author

@areusch @cgerum Thank you for your feedback. I have addressed your feedback. Please review it again.

Copy link
Contributor

@areusch areusch left a comment

Choose a reason for hiding this comment

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

thanks for addressing my comments @ArmageddonKnight ! @cgerum could you take another look here? I think otherwise we should be good to merge

@cgerum
Copy link
Contributor

cgerum commented May 31, 2022

@areusch It's good to merge from my side

@comaniac comaniac merged commit a518000 into apache:main May 31, 2022
@comaniac
Copy link
Contributor

Thanks all for your valuable comments and insightful discussions. This RFC is now merged.
@ArmageddonKnight please open a tracking issue in the main TVM repo to start tracking the progress. Thanks.

@renfeier
Copy link

renfeier commented Aug 5, 2022

@ArmageddonKnight
hello, i have a question looking forward to you reply.
Is it workable to use DietCode + vm compiler + vm runtime to implement graphlevel dynamic shape inference ?
do you have any suggestions?

@ArmageddonKnight
Copy link
Contributor Author

It is workable. The VM can gather the workloads and pack them as a single dynamic-shape workload and forward it to DietCode. DietCode does the auto-scheduling and send the generated code back to the VM.

@renfeier
Copy link

renfeier commented Aug 5, 2022

It is workable. The VM can gather the workloads and pack them as a single dynamic-shape workload and forward it to DietCode. DietCode does the auto-scheduling and send the generated code back to the VM.
Thank you very much for your prompt reply. :-D, b( ̄▽ ̄)d

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.

7 participants