-
Notifications
You must be signed in to change notification settings - Fork 15
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
[Feature] Type Inference of primitives and module selection API change #91
Comments
My two cents. For the first point, it seems not related to the API. You still need to register each primitive anyways. The current registration may not be intuitive to new developers, but I believe a good tutorial could largely solve this issue. After all developers don't need to know how the registration works, but only need to where to find the primitive implementation and their doc strings. For the second point, I'm not sure I got it. To me,
On the other hand,
For fuzzy matching, there's nothing preventing us from implementing |
Sorry not intend to have a global variable. But to have all primitive in a functional mode. |
Basically, what I was recommending is to make the operation as explicit as possible. By the way, I think what slapo is try to do is more like a CSS to HTML, rather than a scheduling langauge as tvm for optimizing the performance using tiling loops etc. |
I'm still trying to learn how to use Slapo. For me, the primitives is a bit counter-intuitive and hard to maintain and debug (e.g., I can't use the step-in/out in the VScode to check/modify this API). I would expect a more state-less interface for applying the schedule primitives just like @zarzen has suggested.
|
I think the current API is fine for users who are familiar with the coding style of Halide/TVM. We do not need to change the interface. VSCode is able to capture the data type of |
This way couples the concept of schedule and module/graph. I don't think it's a good way to manage the schedules. |
I think the point is we need fine-grained control for different optimizations. That is why we need to design the schedule in a hierarchical way and apply the schedule to a specific submodule. For MLEs, I don't expect them to use these low-level primitives. The best way for them is to directly generate an optimized model, so we need to add more automation to it. Then they only need to call some APIs like |
Currently, we have the following schedule operations logic for gpt2.
Issues of this code snippet from my view:
replace
cannot provide type inference features: difficult to know the options for the primitive and not possible to get the doc string for the primitive.(module_part_id, "replace_with", new_module_obj)
. This can also facility debugging the schedule, e.g., removing entries of in the schedule to disable schedules.Recommend to changes the APIs to the following
And the select method can be further improved to consider fuzzy match
The text was updated successfully, but these errors were encountered: