Articles & Books

Accelerating your C++ on GPU with SYCL -- Simon Brand

A post on writing GPGPU code in C++ using the SYCL standard from the Khronos group.

Accelerating your C++ on GPU with SYCL

By Simon Brand

From the article:

Leveraging the power of graphics cards for compute applications is all the rage right now in fields such as machine learning, computer vision and high-performance computing. Technologies like OpenCL expose this power through a hardware-independent programming model, allowing you to write code which abstracts over different architecture capabilities. The dream of this is “write once, run anywhere”, be it an Intel CPU, AMD discrete GPU, DSP, etc. Unfortunately, for everyday programmers, OpenCL has something of a steep learning curve; a simple Hello World program can be a hundred or so lines of pretty ugly-looking code. However, to ease this pain, the Khronos group have developed a new standard called SYCL, which is a C++ abstraction layer on top of OpenCL. Using SYCL, you can develop these general-purpose GPU (GPGPU) applications in clean, modern C++ without most of the faff associated with OpenCL.

C++Now 2017--Michael Park

Trip report!

C++Now 2017

by Michael Park

From the article:

I just returned from C++Now 2017 in Aspen, CO. This was my second time attending the conference and it was just as amazing as last year. My girlfriend decided to come along this time, since Aspen is such a beautiful place. We flew into Denver, rented a car and took the beautiful 4-hour drive into Aspen. She was very happy ��. Strongly recommended...

Quick Q: Is list::size() really O(n)?

Quick A: In C++11 it's required to be constant time.

Recently on SO:

Is list::size() really O(n)?

In C++11 it is required that for any standard container the .size() operation must be complete in "constant" complexity (O(1)). (Table 96 — Container requirements). Previously in C++03 .size() should have constant complexity, but is not required (see Is std::string size() a O(1) operation?).

The change in standard is introduced by n2923: Specifying the complexity of size() (Revision 1).

Packing Bools, Performance tests

Can you pack 8 bools into one BYTE efficiently?

Packing Bools, Performance tests

by Bartlomiej Filipek

From the article:

The simple problem of packing seems to show a lot of performance issues. If the packing is really needed? Can we make the code parallel? What are the branching effects here?

Fun with Reflection in C++ -- Jakie Kay

Jakie Kay explores in her recent blog post the borders of nearly unknown C++ features:

Fun with Reflection in C++

by Jakie Kay

From the article:

In my previous post, we learned about the current and future state of reflection in C++. But I left a few questions unanswered. Indeed, you may still be wondering why I care so much about reflection and if it has any useful applications for the average programmer. In this post, I’ll try to answer that question with real code examples using the two reference implementations of C++ reflection. I’ll explore the strengths of the two implementations, as well as the major limitations. These examples make heavy use of metaprogramming and C++17 features, so if you find yourself in unfamiliar territory while reading the code, I suggest supplementing this article with other resources.

When I refer to the reflexpr implementation, I’m talking about Matúš Chochlík’s fork of Clang which implements P1094, by Chochlík, Axel Naumann, and David Sankel.

When I refer to cpp3k, I’m talking about Andrew Sutton’s fork of Clang which implements P0590R0, by Sutton and Herb Sutter.

Quick Q: When should you ever use functions over functors in C++?

Quick A: They behave differently, it depends on what you need.

Recently on SO:

When should you ever use functions over functors in C++?

Functions support distributed overriding. Functors do not. You must define all of the overloads of a Functor within itself; you can add new overloads of a function anywhere.

Functions support ADL (argument dependent lookup), permitting overloading in the argument-type associated namespace. Functors do not.

Function pointers are a kind of type-erased stateless functor that is a POD, as evidenced by how stateless lambdas convert into it. Such features (POD, stateless, type erasure) are useful.