[cfe-dev] Fw: [RFC] Add SYCL programming model support.

[Anastasia Stulova via cfe-dev]

> Yes, this is the kind of things which are discussed inside the standard committee.


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.


> 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.


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. :)


> 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()...


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.


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.


> 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
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 .


Right. I hope we can find such language constructs for all/most of SYCL features that will help to simplify the frontend architecture.


Kind Regards,

Anastasia


________________________________
From: Ronan KERYELL <ronan-list at keryell.fr>
Sent: 08 February 2019 18:55
To: Anastasia Stulova via cfe-dev
Cc: alexey.bader at intel.com; Anastasia Stulova
Subject: Re: [cfe-dev] Fw: [RFC] Add SYCL programming model support.

>>>>> On Fri, 8 Feb 2019 12:52:07 +0000, Anastasia Stulova via cfe-dev <cfe-dev at lists.llvm.org> said:

    Alexey> One of the goals of SYCL design is to allow developers to
    Alexey> compile and run SYCL code even if the compiler toolchain
    Alexey> doesn’t support acceleration through OpenCL.

    Anastasia> This is somehow very unfortunate because the
    Anastasia> specification for SYCL is titled "SYCL integrates OpenCL
    Anastasia> devices with modern C++". That implies that it targets
    Anastasia> OpenCL explicitly. If there is shift of focus potentially
    Anastasia> some update is needed to avoid confusions.

Yes, this is the kind of things which are discussed inside the standard
committee.

    Anastasia> However, I believe this is still a side goal of SYCL?

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.

    Anastasia> There are plenty of other parallel languages that don't
    Anastasia> target OpenCL. What is the benefit of using SYCL if there
    Anastasia> is no OpenCL available? Anyway, this is probably not the
    Anastasia> discussion that belongs here, but since we are touching
    Anastasia> this topic I feel somehow unfortunate that we have to pay
    Anastasia> the price in the compiler implementation to working
    Anastasia> around something that doesn't seem to be a primary use
    Anastasia> case. :(

Perhaps there is some misunderstanding here on the goals and vision.
Please participate to the SYCL committee and ISO C++ committee if you
can.

Even in plain C++ std::thread works on a monocore non-SMT processor.
std::simd works on processor without SIMD instructions.
But if you have some fancy processor then you can use take advantage
from this.

    Alexey> Unfortunately "OpenCL address spaces" is not C++ standard
    Alexey> feature (yet :)), so if we expose them to the user, the
    Alexey> program written with these extensions will not be supported
    Alexey> by other C++ compiler like GCC or MSVC. Using standard API
    Alexey> allows us to utilize all sorts of extensions for API
    Alexey> implementation and emulate them with standard C++ if
    Alexey> extensions are not available.

    Anastasia> So how do you plan to emulate this it in GCC or MSVC and
    Anastasia> why can't we use the same pure C++ library based approach
    Anastasia> in Clang?

If the compiler does not support outlining of the SYCL kernels to the
accelerators, the sycl.hpp library is just plain C++ and will just run
your code on your CPU because it is just plain C++. This is important
for source code portability.

    Alexey>  It is plausible to assume that it should be easier for
    Alexey> C++ developers to adopt new functionality through
    Alexey> standard C++ concepts like class/function rather than
    Alexey> through language extensions.

Yes, the ISO C++ committee is very reluctant to add new keywords...

    Anastasia> My personal opinion is that learning library APIs or a
    Anastasia> set of new keywords is approximately the same especially
    Anastasia> for those that already mastered the complexity of
    Anastasia> C++. However, I have to say understanding the extra
    Anastasia> "magic" behind what appears to be regular C++ classes
    Anastasia> some developers might find somewhat counter-intuitive.

A fundamental problem with an OpenCL, CUDA, Cilk, C++AMP... program is
that if you insert it in a plain C++ program it just does not compile
because it is not... C++ since the compiler will choke on some strange
keywords. And that is a pain if you have to port a big application from
one standard to the other.

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()...

But then, how we implement this by splitting the implementation between
some C++ library, Clang and LLVM is what we have to discuss here.

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
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 .

As I have already told you, triSYCL made a lot of progress just by your
up-streamed Clang OpenCL work. Go on. :-)

Thank you for this again,
--
  Ronan KERYELL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190211/19eb5c8b/attachment.html>