Видео

OpenSyCL was also known as hipSyCL (for AMDs hip GPU framework) if it helps anyone trying to lookup information. And the switch of SyCL from version numbers like v2.3 to revision years (2020 ie) also marked a complete change in the entire standard, which was based largely on OpenCL and is now fully independent; the year revisions are also intended as a way to stay somewhat aligned with iso C++ revisions.

That is most curious to me that using the same standard library implementation the two compilers produce such wildly different results. I would assume it has something to do with how the code is optimized, as in clang expects a particular organizational structure based on how they think optimization should work and gcc uses something totally different that doesn't mesh when clang is set to accommodate gcc's library. Although, I'd bet that when I see your video it'll be something completely different.

New to the channel. This is an instant subcribe. Thanks!

Imagine the lack of skill that you must have to use some garbage like this. 68 times compared to what a CPU does is pocket change for a GPU if you are not a Java prpgrammer

Just FYI, I have Asus Rog Flow X13 AMD CPU + Nvidia GPU and it is much easier to build Intel’s oneAPI llvm toolchain both for Windows and WSL2 just having CUDA toolkit installed. From my POV it is easiest way to start playing with DPC++

Is there a way to sort that array at compile time to be able to use lower_bound for lookup?

Can you mix RVO and NRVO?

I wonder how the performance of this compares to just writing a fragment shader to do the computation. Honestly I'm pretty surprised by how slow it is compared to what I would normally expect on a GPU, I was expecting well under 10ms per iteration at 10,000x10,000, then again maybe it is limited by memory bandwidth especially on an integrated GPU. Also I tend to have pretty high end GPUs so my expectations are probably a little high for an integrated GPU.

FYI: Distrowatch is frequently botted and distros can pay to have their rankings artificially inflated. Don't trust it for rankings.

the compiler should just do it!!!!!!!!!!!

Id love to hear your thoughts as a fresh user compaing this with kokkos

It would have been good to see the graph continue for a few more size iterations 'bigger' on the right. It hasn't clearly shown the intersection between GPU and CPU where it appears the GPU 'bowl' is on the way back up. Perhaps it was just going to level out around the Clang CPU curve (suggesting there is some high intensity CPU load associated with the larger grids.. perhaps virtual mem paging, which i suspect is not CPU parallelizable)

Will definitely be checking this out. In solving some parallelisable problems at my job, I went ahead and used Vulkan by essentially modifying the compute shader example on the Vulkan website, and saw something like a 100x speedup. However, it's pretty complicated to use. You have to write the shader code, compile it at runtime, manage dispatch, memory and synchronization. It's a pretty long way from standard c++. There's also a lot to go wrong. If Adaptive C++ can even come close to the performance I am getting with Vulkan it's worth a shot, because it will simplify the codebase significantly. I would like to see how well it handles complex tasks, say for example if it can chunk through a lot of trig operations on data quickly, and also how efficiently it handles the dispatch or successive "draw calls".

Lemme guess, Clang vectorizes the code, which is useless in this case

Aren't there race conditions when parallel processing a cell's neighborhood?

AFAIK, acpp uses OpenMP or OpenCL as CPU backends, not TBB

8:47 Just a minor nitpick: twice as fast isn’t the same as twice faster. With that out of the way, that’s curious. It would make for a good follow up.

Not bad, although seems usable only in very specific scenarios? In the case you want to juice out maximum performance, you would just use something like CUDA to get better performance as it gives you more control. If your task is a bit more complex, such that using simple standard algorithms would be hacky, it would also not be great solution - what about concurrency/synchronization? So basically you would probably use it only if you have a simple problem and you want to quickly speed it up a little bit, but don't want to put the work in to speed it up more?

I remember reading on a vulkan (blog? might not have been a blog, idk, was a while ago) thing that the sweet spot was around 2 million concurrent floating point operations so glad to see a proven sweet spot with a similar number.

I'm curious what the performance is when running a natively-written CUDA version of this code, and how it stacks up against the AdaptiveCPP versions. In general, I find that these "write once, compile for anywhere" systems tend to only be useful if it's actually your use case to not target a specific architecture, but once you're already in a situation where you know you're going to be running on a particular architecture it's almost always better to write something natively for it. I know that AdaptiveCPP's claim is that it can even beat the native code but that's something I'd like to see benchmarks on.

Wow I wasnt aware of that hetergeneous compiler! I'll note to play with it someday, maybe mixnig with the new std::execution library }:D

GPU's are cool though be aware of applicability and the memory transfer overhead. Microsoft used to offer C++ AMP which was a nice library to offload calculations to an accelerator. Unfortunately they withdraw that library.

There is a reason system programmers don't like c++ for low-level stuff

The fact that this is pure c++ code is actually quite impressive. Reminds me of c++ AMP back in 2011. Still, this kind of solutions leave a ton of performance on the table compared to hand writing it using vulcan or dx12 compute shaders, so I'm not really sure it's the right way to go forward towards heterogenous computing. I'd rather have the GPU vendors conform to a common ISA, so that we can directly program the GPUs instead of going through multiple layers of (black box)abstractions.

Hey, Jason, what do you think of the Intel's DPC++?

I haven't yet seen this video, but that would be great if this kind of video were done more in C++ Weekly. It is the kind of video, where even if done badly it would be great because the subject is not well covered. How to use C++ to use X and Y would really be great for viewers.

With regards Linux distros I'd recommend EndeavorOS which is based on Arch and comes in multiple flavours (each with a different desktop & software) but by default I think it's very up to date KDE Plasma. The ISO comes with a graphical installer and the distro itself seems very stable despite being quite bleeding edge. Pacman is a good wrapper around the native arch package manager and if you really want to have some GUI software installer you can use 'Discover' - though it is recommended to use the terminal.

Wait until he learns about Celerity 😉

Just get a compass card, it's actually cheaper than just using your CC. And you get a nice souvenir to take home with you.

AdaptiveCpp is indeed an open implementation of Sycl. Unfortunately Sycl is not an easy system to program in. There is also Kokkos (from Sandia Labs) that also targets multiple backends, and is (imnsho) easier to program. And then there is OpenMP with offloading. With the exception of OpenMP, they are all "data parallel" systems, much like CUDA. In fact, if you squint a little, they all look so similar to CUDA that you can probably automatically convert them. In fact, Intel has such a tool for their version of Sycl. But that's the story for the standard Sycl. The fact that you didn't have to change your code means that (and this I didn't know and is very cool!) apparently AdaptiveCPP translates CPP range algorithms to the (ugly ugly) underlying Sycl code. I think this is specific to the ACPP compiler, and it's not behavior mandated by the Sycl standard. Cool.

Have you tried to constrexpr it?

@cppweekly you are required by RUclips to select the box "My video contains paid promotion" when it's the case, such as here with the CLion promotion.

I'm way more sold on the benefit of constexpr/consteval after seeing this.

It's out of scope of the video but I don't where to ask anymore. CLion reports a few unreachable code when using constexpr in my math library. I copy paste it part of it into Compiler Explorer, make sure I use the same toolchain, enable all warnings and it doesn't report anything. So, am I doing something wrong? I cannot find any CLion forum that solve this problem

Why would you use polymorphism?

It is kind of annoying if the compiler can't correctly optimize away "temporaries" though. In my compiler I didn't even leave that kind of logic until the optimization stage and instead added it in as a basic part of compilation.

Awesome episode. I don't regret watching it. Now I can better remember about this specific pitfall. The worst emotion now is a frustration caused by so called "standard" which was supposed to make everyone's life easier instead of making really bad things harder to spot.

maybe C++ is getting simpler after all!

6:44 Why would you ever need to rely on NRVO, other than for efficiency? The only situation I can think of is if you’re trying to return a non-copyable, non-movable object from a function. But in that case, the compiler could not return the object and you’d get an error diagnostic, with or without a -Wnrvo compiler option.

This is super neat Great video Jason!

Feels like C++ getting worse and worse. Now it's not ok to move objects out of a functions Yay :(

If you actually don't want elision, you can disable the warning by wrapping the return value in std::move (when the returned type has a suitable constructor). The intent may not be obvious to the reader, though...

Woudn't be cool to have [[rvo]] attribute for functions? It could report error if compiler is not able to do it.

Great addition, tho I feel like as attribute it wouldn't get in the way as much as when it is global warning.

"MSVC compilers down" ... who cares?

I still prefer MinGW and Clang over MSVC for a reason...

Thank you 👍👍

this would've been useful to me like a week before. Had to pull one of your older videos about std::optional\std::variant and RVO to get it 'right'

Awesome!

is this included in -Wall or -Wpedantic ?