<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 25, 2016 at 11:41 AM Sergey Ostanevich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Chandler,<div><br></div><div>Thank you for getting it up to ML top. </div><div><br></div><div>I believe we have to move broader than that you just mentioned. The natural separation of the infrastructure into different parts can be across the following lines:</div><div><br></div><div>- the parallel model of programming - these can be OpenMP, OpenACC, CilkPlus, OpenCL, StreamExecutor, CUDA, C++ parallel extensions, etc.</div><div>- the offloading machinery to be used by any of those above and providing unified interfaces across all targets to be supported</div><div>- the performance libraries collection that can be re-used in different programming models and be targeting different host/targets planforms</div><div><br></div><div>I would like to touch the 2nd bullet, since I had most exerience with it.There should be a single interface for all offloading players that are willing to take part. Those are not limited to StreamExecutor and the OpenMP already published in LLVM. There are number of solutions from Intel, not saying of others, - it would be reasonable to become a platform for all of them, and I got positive feedback on the idea within.</div><div>To name a few (don't take it as an ad): <br></div><div><br> - Hetero Streams Library, <a href="https://01.org/hetero-streams-library" target="_blank">https://01.org/hetero-streams-library</a><br> - <span style="font-size:13px;color:rgb(0,0,0);font-family:IntelClear-Bold,tahoma,Helvetica,helvetica,Arial,sans-serif;line-height:20px">Beignet Project, </span><font color="#000000" face="IntelClear-Bold, tahoma, Helvetica, helvetica, Arial, sans-serif"><span style="line-height:20px"><a href="https://01.org/beignet" target="_blank">https://01.org/beignet</a></span></font><br> - Math Kernel Libraries, <a href="https://software.intel.com/en-us/intel-mkl" target="_blank">https://software.intel.com/en-us/intel-mkl</a><br><div> - Intel Compiler, <a href="https://software.intel.com/en-us/intel-compilers" target="_blank">https://software.intel.com/en-us/intel-compilers</a></div></div><div><br></div><div>I believe we shouldn't make any difference between StreamExecutor and other projects and to try to plug one into the other or vice versa. The better would be to reuse the same ground level I/O machinery that will provide efficiency to all of these and the newcomers. The machinery should have some specific attributes, such as support of multitude of languages currently employed by LLVM project and beyond. Also we have to take into account different application of the compiler and infrastructure: there can be server solutions where we are free to use full-featured C++ and there can be embedded solutions, such as automotive, where customers are tend to have as few runtime support as possible and like C the most.</div></div></blockquote><div><br></div><div>I don't think anything I'm suggesting precludes these directions in the future?</div><div><br></div><div>I just don't think it is reasonable to hold up starting to work on the pieces that are ready now. OpenMP was ready some time ago and is making fine progress. StreamExecutor is ready now, and I'd like to let it make progress indepnedently. If and when unifying infrastructure and sharing it across a diverse set of technologies like this is desirable, we can figure out the design with concrete patches and steps to get there? It seems *way* too early to try to design for all of the things you list considering that many aren't even in LLVM currently.</div><div><br></div><div>-Chandler</div></div></div>