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

Modify team gemm interface #350

Closed

Conversation

huttered40
Copy link

I moved TeamGemm's MemberType template parameter from the class-template level the function-template level. This template parameter can always be deduced and thus should not need to be explicitely specified by the user. This change also allows SerialGemm and TeamGemm to have the same interface. I suspect other class templates like TeamGemv can also be changed.

The use case for this is I want to be able to pass SerialGemm and TeamGemm as policy classes for a Gemm policy. In order for this to be possible, the interfaces must match. With these changes, each class template shares the same three class-level template parameters.

I did the following steps, with no errors:

make install-lib -j16
cd unit_test
make -j

…e level the function-template level. This template parameter can always be deduced and thus should not need to be explicitely specified by the user. This change also allows SerialGemm and TeamGemm to have the same interface.
@ndellingwood
Copy link
Contributor

@kyungjoo-kim can you review this PR?

Copy link
Contributor

@kyungjoo-kim kyungjoo-kim left a comment

Choose a reason for hiding this comment

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

I do not approve this design modification. The reason for putting the member type outside is for a potential case that we need to "partially" specialize an algorithm for different types of members. For example, a member from a cuda team may need a different algorithm specialization (loop ordering or blocking size) comparing with host team. If we put the member type as a function template parameter, we cannot provide a partial specialization.

@huttered40
Copy link
Author

Ok. That concern makes sense. If the potential case you mention is needed, another option would be overloading the invoke function template on the TeamMemberType so that the user wouldn't be forced to explicitly specify MemberType.

This difference in interface between SerialGemm and TeamGemm requires an extra level of specialization on my end, but its not that big of a deal.

@crtrott
Copy link
Member

crtrott commented Nov 28, 2018

Kyungjoo is right. The member type tells us the execution space so we need that partial specialization capability here. Sorry Edward :-(

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.

4 participants