tqchen commented on pull request #5779: URL: https://github.com/apache/incubator-tvm/pull/5779#issuecomment-643646043
I don't think we disagree in many cases. Let me try to rephrase @t-vi's the dtype part of the arguments: - F0: NLP and quantization worklaods needs mixed precisions(fp16, i8, i32). - F1: In order to support NLP workloads well, we will need to able to handle other data types well other than fp32. I think we all agrees to F0 and F1. Now one of @masahi 's argument is - K0: Most users tries to use fp32 by default, it would be nice to keep things to be compatible to that interface when adding dtype support. As we can see that K0 do not necessarily conflict with F0 and F1. As an outsider to the discussion, it is a bit harder for me to express my thought(without looking at the code). It would be easier if we can list interface candidates during the discussion, and discuss their pros and cons. There is certainly a tradeoff we need to make, in terms of ease of use, level of compatibility etc. I need a bit more time to dig in order to understand the name argument. But at a high level (this is my opinion) I think it makes sense to inheritate names from the source(if they are available) while allow users to override them. The main reason why certain name/shapes are requirement in frontend is that many cases these information are incomplete. Again having interface candidates will be helpful here. The main reason for a discussion is not necessarily argue for which side is right, but actually to clarify the intent, and reach concensus(sometimes both sides actually already agrees to). So that in the future others can look into it. Also in cases like this discussions are also important to find out the best ways for integeration (e.g. not about whether or not shall we do dtype handling, but how to best do them). Discussions also serves the good purpose on learning. It would be great for everything to share the understanding of the "status quo" and contentious points. Sometimes the problem of the disagreement is not what we need to do to support these, but how to best resolve the situation. We can certainly create followup discussions in the forum. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
