4 ms·

Intel’s excellent TBB library is the answer to all your worries about threads in C++. (IMHO it should be made part of the standard library.)

ncmncm 7y ago
All your worries, if throughput is all you worry about, and not latency. Or, if you have interaction between threads. Or, if you might need to run on other archs. An equivalent to TBB or GCD will be in C++23 std libraries, but you can often do better with coroutines, in 20. TBB and GCD still need to sychronize sometimes, and they randomize workload assignment, which is bad for cache locality (i.e. bad). If you can arrange static assignment and avoid need to synchronize, you can do better, sometimes much better.
- Koshkin 7y ago
  > other archs See, for instance, https://www.theimpossiblecode.com/blog/intel-tbb-on-raspberry-pi/ https://www.theimpossiblecode.com/blog/intel-tbb-on-raspberr....
  - ncmncm 7y ago
    Interesting, thank you.
- pjmlp 7y ago
  The problem with C++23, is that it will be mostly usable around 2025, and C++20 co-routines still don't have a co-routine aware standard library, right?
  - ncmncm 7y ago
    Executors, which abstract threads, coroutines, fibers, vector units, GPUs, and very possibly even spin-polling isolated cores, will be integrated in 23. In the meantime you have the core language features, if you don't need or want abstraction, and Boost asio, which will get everything ahead of time. But std algorithms integrated to use the abstract executors optimally may not surface until 23, IIUC. I don't know why you would need to wait for 2025.
    - pjmlp 7y ago
      I guess because many shops don't want to have Boost as dependency. Other than filesystem, back in a 2010 project, I have never used Boost. I have enough concurrency in C++, thanks Concurrency Runtime. Somehow it is ironic to see C++ catching up with java.util.concurrency and TPL.
      - ncmncm 7y ago
        You may reasonably expect C++23 library features to show up in (or by) 2023, just as C++20 features will be out in this calendar year. You might have private reasons to delay adopting C++23 until 2025, but there is nothing the rest of us can do about that. Java TPL is very, very limited when compared to C++23 executors. "Concurrency", by the way, has come to refer to the synchronizing interactions that cause slower-than-xN parallelism.
        pjmlp 7y ago
        Java executors exist and are useful to me today in all platforms where a Java compiler is available, C++ executors are yet to be delivered, it remains to be seen what C++23 will actually look like and what will be dropped at very last minute like contracts were. Also other programming languages also don't stand still.
        ncmncm 7y ago
        Are you suggesting that C++ is developing too slowly? Others complain that it is changing too quickly. Maintaining the right balance is hard, but choosing a balance point everyone can agree on is impossible. The mode chosen by the C++ committee is to favor development of library features outside the Standard, and then adopt the successes. That entails waiting to see what is a success, and relying on non-Standard library implementations in the meantime. The '23 executors design has been a long time coming, but is overwhelmingly better -- meaning, applicable to a much broader space of execution models -- than early designs, without compromise on performance. Other languages routinely compromise on performance, which is often the right choice for them.

ncmncm 7y ago

All your worries, if throughput is all you worry about, and not latency. Or, if you have interaction between threads. Or, if you might need to run on other archs. An equivalent to TBB or GCD will be in C++23 std libraries, but you can often do better with coroutines, in 20. TBB and GCD still need to sychronize sometimes, and they randomize workload assignment, which is bad for cache locality (i.e. bad). If you can arrange static assignment and avoid need to synchronize, you can do better, sometimes much better.

Koshkin 7y ago
> other archs See, for instance, https://www.theimpossiblecode.com/blog/intel-tbb-on-raspberry-pi/ https://www.theimpossiblecode.com/blog/intel-tbb-on-raspberr....
- ncmncm 7y ago
  Interesting, thank you.
pjmlp 7y ago
The problem with C++23, is that it will be mostly usable around 2025, and C++20 co-routines still don't have a co-routine aware standard library, right?
- ncmncm 7y ago
  Executors, which abstract threads, coroutines, fibers, vector units, GPUs, and very possibly even spin-polling isolated cores, will be integrated in 23. In the meantime you have the core language features, if you don't need or want abstraction, and Boost asio, which will get everything ahead of time. But std algorithms integrated to use the abstract executors optimally may not surface until 23, IIUC. I don't know why you would need to wait for 2025.
  - pjmlp 7y ago
    I guess because many shops don't want to have Boost as dependency. Other than filesystem, back in a 2010 project, I have never used Boost. I have enough concurrency in C++, thanks Concurrency Runtime. Somehow it is ironic to see C++ catching up with java.util.concurrency and TPL.
    - ncmncm 7y ago
      You may reasonably expect C++23 library features to show up in (or by) 2023, just as C++20 features will be out in this calendar year. You might have private reasons to delay adopting C++23 until 2025, but there is nothing the rest of us can do about that. Java TPL is very, very limited when compared to C++23 executors. "Concurrency", by the way, has come to refer to the synchronizing interactions that cause slower-than-xN parallelism.
      - pjmlp 7y ago
        Java executors exist and are useful to me today in all platforms where a Java compiler is available, C++ executors are yet to be delivered, it remains to be seen what C++23 will actually look like and what will be dropped at very last minute like contracts were. Also other programming languages also don't stand still.
        ncmncm 7y ago
        Are you suggesting that C++ is developing too slowly? Others complain that it is changing too quickly. Maintaining the right balance is hard, but choosing a balance point everyone can agree on is impossible. The mode chosen by the C++ committee is to favor development of library features outside the Standard, and then adopt the successes. That entails waiting to see what is a success, and relying on non-Standard library implementations in the meantime. The '23 executors design has been a long time coming, but is overwhelmingly better -- meaning, applicable to a much broader space of execution models -- than early designs, without compromise on performance. Other languages routinely compromise on performance, which is often the right choice for them.