<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size: 12pt; color: rgb(0, 0, 0); font-family: Calibri, Helvetica, sans-serif, "EmojiFont", "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols;" dir="ltr">
<p style="margin-top:0;margin-bottom:0"><font size="2"><span style="font-size:11pt;">> Yes, this is the kind of things which are discussed inside the standard committee.</span></font></p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Ok, while this might be in discussion I am referring to an existing published spec that clearly indicates that SYCL is to run on OpenCL accelerated devices.
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><font size="2"><span style="font-size:11pt;">> No, the *fundamental goal* since the beginning in SYCL is to have a CPU mode, for example if you do not have an accelerator available or take advantage of your multicore
SIMD CPU while some other SYCL kernels are using the accelerators at the same time for example.</span></font></p>
<p style="margin-top:0;margin-bottom:0"><font size="2"><span style="font-size:11pt;"><br>
</span></font></p>
<p style="margin-top:0;margin-bottom:0"><font size="2"><span style="font-size:11pt;"></span></font>There is OpenCL implementation for CPUs too. I might be wrong but I am not sure how something that's written to run using such massively parallel model like OpenCL
can be executed and run in a performant way as a C++ library. I like the idea of one language that can be good at everything, however, such things usually come with a "special" price. :)<br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><font size="2"><span style="font-size:11pt;">> Most of the modern C++ features are provided through classes rather than keywords. Just think about threads, futures and on-coming executors, SIMD types, fixed point... A
lot of the modern STL has some extra magic. Or just in plain old C there are some magical functions: exit(), setjmp()/longjmp()...</span></font><br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">As for the compiler design, it's preferable that everything not requiring special compiler support to be represented in the libraries. However, if there are features that need compiler change they are likely to end up
as language constructs explicitly. This way they can be parsed and mapped to AST conventionally.<br>
</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">As for C++, many Clang developers are active contributors to ISO C++ spec and many proposals are prototypes or even implemented upstream before they are propagated into spec to ensure compiler design is aligned with the
language concepts.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<font size="2"><span style="font-size:11pt;">> For example, I cannot see why most of your great work on OpenCL address spaces in C++ cannot be used as is by a SYCL implementation targeting<br>
OpenCL, since the memory model is the same and in that case some SYCL classes will be just some proxy/wrapper objects hiding some OpenCL address space attributes .</span></font><br>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Right. I hope we can find such language constructs for all/most of SYCL features that will help to simplify the frontend architecture.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">Kind Regards,<br>
</p>
<p style="margin-top:0;margin-bottom:0">Anastasia<br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Ronan KERYELL <ronan-list@keryell.fr><br>
<b>Sent:</b> 08 February 2019 18:55<br>
<b>To:</b> Anastasia Stulova via cfe-dev<br>
<b>Cc:</b> alexey.bader@intel.com; Anastasia Stulova<br>
<b>Subject:</b> Re: [cfe-dev] Fw: [RFC] Add SYCL programming model support.</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">>>>>> On Fri, 8 Feb 2019 12:52:07 +0000, Anastasia Stulova via cfe-dev <cfe-dev@lists.llvm.org> said:<br>
<br>
Alexey> One of the goals of SYCL design is to allow developers to<br>
Alexey> compile and run SYCL code even if the compiler toolchain<br>
Alexey> doesn’t support acceleration through OpenCL.<br>
<br>
Anastasia> This is somehow very unfortunate because the<br>
Anastasia> specification for SYCL is titled "SYCL integrates OpenCL<br>
Anastasia> devices with modern C++". That implies that it targets<br>
Anastasia> OpenCL explicitly. If there is shift of focus potentially<br>
Anastasia> some update is needed to avoid confusions.<br>
<br>
Yes, this is the kind of things which are discussed inside the standard<br>
committee.<br>
<br>
Anastasia> However, I believe this is still a side goal of SYCL?<br>
<br>
No, the *fundamental goal* since the beginning in SYCL is to have a CPU<br>
mode, for example if you do not have an accelerator available or take<br>
advantage of your multicore SIMD CPU while some other SYCL kernels are<br>
using the accelerators at the same time for example.<br>
<br>
Anastasia> There are plenty of other parallel languages that don't<br>
Anastasia> target OpenCL. What is the benefit of using SYCL if there<br>
Anastasia> is no OpenCL available? Anyway, this is probably not the<br>
Anastasia> discussion that belongs here, but since we are touching<br>
Anastasia> this topic I feel somehow unfortunate that we have to pay<br>
Anastasia> the price in the compiler implementation to working<br>
Anastasia> around something that doesn't seem to be a primary use<br>
Anastasia> case. :(<br>
<br>
Perhaps there is some misunderstanding here on the goals and vision.<br>
Please participate to the SYCL committee and ISO C++ committee if you<br>
can.<br>
<br>
Even in plain C++ std::thread works on a monocore non-SMT processor.<br>
std::simd works on processor without SIMD instructions.<br>
But if you have some fancy processor then you can use take advantage<br>
from this.<br>
<br>
Alexey> Unfortunately "OpenCL address spaces" is not C++ standard<br>
Alexey> feature (yet :)), so if we expose them to the user, the<br>
Alexey> program written with these extensions will not be supported<br>
Alexey> by other C++ compiler like GCC or MSVC. Using standard API<br>
Alexey> allows us to utilize all sorts of extensions for API<br>
Alexey> implementation and emulate them with standard C++ if<br>
Alexey> extensions are not available.<br>
<br>
Anastasia> So how do you plan to emulate this it in GCC or MSVC and<br>
Anastasia> why can't we use the same pure C++ library based approach<br>
Anastasia> in Clang?<br>
<br>
If the compiler does not support outlining of the SYCL kernels to the<br>
accelerators, the sycl.hpp library is just plain C++ and will just run<br>
your code on your CPU because it is just plain C++. This is important<br>
for source code portability.<br>
<br>
Alexey> It is plausible to assume that it should be easier for<br>
Alexey> C++ developers to adopt new functionality through<br>
Alexey> standard C++ concepts like class/function rather than<br>
Alexey> through language extensions.<br>
<br>
Yes, the ISO C++ committee is very reluctant to add new keywords...<br>
<br>
Anastasia> My personal opinion is that learning library APIs or a<br>
Anastasia> set of new keywords is approximately the same especially<br>
Anastasia> for those that already mastered the complexity of<br>
Anastasia> C++. However, I have to say understanding the extra<br>
Anastasia> "magic" behind what appears to be regular C++ classes<br>
Anastasia> some developers might find somewhat counter-intuitive.<br>
<br>
A fundamental problem with an OpenCL, CUDA, Cilk, C++AMP... program is<br>
that if you insert it in a plain C++ program it just does not compile<br>
because it is not... C++ since the compiler will choke on some strange<br>
keywords. And that is a pain if you have to port a big application from<br>
one standard to the other.<br>
<br>
Most of the modern C++ features are provided through classes rather than<br>
keywords. Just think about threads, futures and on-coming executors,<br>
SIMD types, fixed point... A lot of the modern STL has some extra magic.<br>
Or just in plain old C there are some magical functions: exit(),<br>
setjmp()/longjmp()...<br>
<br>
But then, how we implement this by splitting the implementation between<br>
some C++ library, Clang and LLVM is what we have to discuss here.<br>
<br>
For example, I cannot see why most of your great work on OpenCL address<br>
spaces in C++ cannot be used as is by a SYCL implementation targeting<br>
OpenCL, since the memory model is the same and in that case some SYCL<br>
classes will be just some proxy/wrapper objects hiding some OpenCL<br>
address space attributes .<br>
<br>
As I have already told you, triSYCL made a lot of progress just by your<br>
up-streamed Clang OpenCL work. Go on. :-)<br>
<br>
Thank you for this again,<br>
-- <br>
Ronan KERYELL<br>
</div>
</span></font></div>
</div>
</div>
</body>
</html>