The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

143822 (1) [Avatar] Offline
Let me — as an example — refer to Listing 2.8 (Spawn some threads and wait for them to finish).

I replaced the line







for (auto &t : threads)
        t.join ();

Used to C++11 … C++17, the alternatives are much more readable for me. Even more, they perform better. And isn’t performance an essential goal of multithreading?

Added an empty do_work(), compiled with c++7.3 (-Wnoexcept -fnothrow-opt -flto -O3 -march=native -std=c++17) and run with

for ((i=0;i<1000;++i)) ; do
    perf stat -e cycles,instructions ./foo

the mean results are (1st column: cycles original, 2nd: instructions original, 3rd: cycles alternative, 4th: instructions alternative)

Proliant DL180 G6: 6071036±1390  5628750±309 5849318±1283  5197033±412
i5-3470T Desktop:  6784412±20508 5647574±682 6566296±55516 5205668±2808

The same observation applies to other examples too. Question: Why not use the more readable and more efficient C++ dialect?
anthony.williams (216) [Avatar] Offline
Yes, you're right. In some places I could use the C++17 alternatives. However, I'm trying to focus on the concurrency aspect, without introducing too much of the new C++ features. I'll see if there are any places I think would benefit from updating.