#CPPCON2017. Day 3. The Future of C++

At #CPPCON2017 Day 3, I spent most of the time on the meetings of SG14 (on games and low-latency stuff); while it was certainly useful for me – the most interesting things on Day 3 happened outside of SG14.

Generative C++ == The Future

IMNSHO, the most important talk of Day 3 (and probably of the whole CPPCON2017) was the talk by Herb Sutter titled “Meta: Thoughts on generative C++”. I have a reputation of not being blindly sympathetic to the WG21 <wink />, but here I am saying: You guys are doing a Very Good Thing(tm) (and IMNSHO it is going to be the biggest C++ improvement since the advent of STL).

Watching this talk is The Absolute Must(tm) when it becomes available on Youtube; it is The Direction where C++ goes (at least, I really hope so <wink />).

On the other hand – the length of the road we’re speaking about, is enormous (with full-scale generative C++ not coming IMO at least until 2030 or so):

• [画像:Hare with smiley sign:]“in C++20, if we're lucky, we could get static reflectionin C++20, if we’re lucky, we could get static reflection (let’s root for it <smile />). This already will be a HUUUUGE improvement over what-we-have now, with stuff such as serialization, IDL generation,¹ logging, and a dozen of the other similar scenarios becoming easily doable without any external stuff <phew />.
  • “spaceship operator”, which might make it there too, while improving things with the amount of boilerplate significantly (and I like it too), is not that fundamental change (and actually aims to fix one single problem).
• The next planned step, if I understood Herb correctly, is “injection”. It is like compile-time C++ codegeneration within C++ itself. While being enormously powerful, it is not that straightforward to use. My guess is that while it will allow to do lots of things which are impossible now, to achieve those things we’ll have to abuse it a lot (well, hopefully not to the point of Turing-complete template metaprogramming – but still significantly). NB: while it will allow LOTS of things – it seems that we’ll still have to have cross-platform IDL outside of C++ (unless codegeneration will be generalized to externalizable arbitrary text – which doesn’t look to be among the goals)

• And last but certainly not least – at some point we can hope to get an ability to classify our classes. One of the examples is specifying that certain thing is not a “class”, but is an “interface” – a specialized kind of class which disallows everything but pure virtual functions; or “value” (prohibiting member functions and enforcing everything public), and so on (make sure to watch the talk for further examples). Moreover, certain things (such as enums) can be expressed as specialized classes too (reducing the number of entities which have to be supported by the compiler, enums and enum classes becoming merely definitions within some include file in a standard library). Most importantly, however – we’ll be able to define things such as QtClass (with all the magic-currently-done-by-weird-templates, going into the perfectly legal C++-without-preprocessor).
• Or, and last but not least – all these things are not changing the nature and the runtime behaviour of our C++ programs: they’re just a way to write things which we’re already able to write manually – just saving us time to write mundane things.

Overall, I am very excited about this kind of the roadmap; the only concern of mine is a question when these beauties have a chance to happen. Even objectively, it is a Damn Lot(tm) of work, and that’s even without the need to jump through the hoops of the committee formalisms – and without the need to overcome resistance of conservatives-within-WG21, which, as we know from previous experience, have a potential slow things down by many years.

Good luck folks, you’ll certainly need it (but we’re keeping our fingers crossed for you).

Hardware Designed for C++

Another IMO very important talk of Day 3 was that by Olivier Giroux from Nvidia, inconspicuously titled “Designing C++ Hardware”. While this talk may be seen as of only very niche importance, in fact – it does open a new era. The main message we got was that

In addition to making us (as in “C++ developers”) feeling that we’re becoming even more important without lifting a finger <wink /> – it has profound implications on the C++ ecosystem:

• [画像:Surprised hare:]“we cannot really think the world is limited to traditional few-cores-with-lots-of-RAM CPUs such as x64, ARM, SPARC, Power, etc.we cannot really think the world is limited to traditional few-cores-with-lots-of-RAM CPUs such as x64, ARM, SPARC, Power, etc. ²
  • In particular: with CPUs, a more-or-less-typical amount of RAM per core is in tens of gigabytes. With GPUs, we’re more in the range of hundred kilobytes (that’s 5 orders of magnitude difference!)
• it provides an undisputable niche for C++ for many years to come (OTOH, we should be beware of the situation when HW manufacturers will get enough transistors to start supporting Ruby on their chips)

On more practical matters:

• new nVidia Volta chip (and surrounding software) already almost allows writing C++ programs where a chunk of RAM is shared between CPU and GPU.
  • there are still quite a few quirks (=”DON’T expect to run your existing 100K-LoC library there – yet”), but we can hope for them to be sorted out in a not-so-distant future.
• Unlike the rest of GPUs, on the outside Volta looks as a scalar processor. Not sure to which extent it really is (and whether we’ll still have to think about creating as-many-similarly-looking-threads-as-possible to make it efficient) – but in any case, it is a step into the direction of the making GPU programming more like usual C++ programming <phew />

Not sure about you – but I am certainly excited with this direction <smile />.

SG14

Out of less fundamental (but hopefully coming much quicker) things I learned on Day 3, there are quite a few interesting things in progress by SG14 (games and low-latency programming):

• support for non-blocking stuff
  • IMO, the most interesting one discussed was support for Read-Copy-Update a.k.a. RCU (for a generic description of RCU outside of the SG14, see, for example, [https://en.wikipedia.org/wiki/Read-copy-update] and [https://www.kernel.org/doc/Documentation/RCU/whatisRCU.txt]). It is pretty difficult to explain in a few sentences – but it does allow to avoid locking in a case of complex-modifiable-structures-with-multiple-readers scenarios (and without direct-and-frequent use of per-element CAS etc.).
• [画像:Hare thumb up:]“support for fixed-point is coming (including so-called 'elastic' fixed-point)support for fixed-point is coming (including so-called “elastic” fixed-point). From my perspective, the most interesting aspect of it is that it is going to be perfectly-deterministic <wow! />. With lots of things in MOG world hinging on next-to-impossible-to-achieve floating-point determinism – this is certainly a very interesting development.
• support for interesting (and fast) data structures such as slot map [http://seanmiddleditch.com/data-structures-for-game-developers-the-slot-map/]. BTW, an interesting observation – in a sense, slot map can be seen as a close cousin of the id-checking technique for allocators in [http://ithare.com/allocator-for-reactors-with-optional-kinda-safety-and-relocation/].

[画像:Tired hare:]It was another long day – and IMO the most exciting one so far. I hope to continue my coverage of CPPCON2017 tomorrow.