3 ms·

Both C and C++ have zero built in knowledge about parallelism, so in a modern world where most things are parallel and asynchronous I don’t agree at all with th

Both C and C++ have zero built in knowledge about parallelism, so in a modern world where most things are parallel and asynchronous I don’t agree at all with that statement.

sigotirandolas 6y ago
Both C and C++ have had a concurrent memory model and threads in the standard library for a decade now. And POSIX threads which are pretty much the same thing have been there for a quarter century on *NIX.
- fetbaffe 6y ago
  Sure, there are libraries for concurrency, but there are no language constructs like in other languages.
  - cogman10 6y ago
    What do you mean by language constructs? As in, a `synchronized` keyword? Or are you thinking along the lines of `async` `await`? If you mean the `synchronized` keyword, then correct, they don't have that. Most languages do not have that concept. C++ does have mutexes and has had them since C++11 (nearly a decade). C++ also has as part of the language spec the concept of threads, again, there since C++11. If you meant co-routines, then C++ just added them with C++20. Or do you mean something different like green threads (ala go)? C++ certainly has concurrency constructs and has been expanding them since C++11.
    - fetbaffe 6y ago
      Like Gos goroutines or Erlangs processes. And more of message passing. C++ has added many of these things later on in the standard library, bolted on afterwards.
      - erichocean 6y ago
        If you think that using libraries to do things in C++ means they are "bolted on", then you don't understand C++. The entire design of C++ is to enable efficient libraries for these kinds of things to be built. And it does, and has, and will continue to for decades more.
adev_ 6y ago
> Both C and C++ have zero built in knowledge about parallelism, so in a modern world where most things are parallel and asynchronous I don’t agree at all with that statement. And ? C (even Fortran) had threads and was used to create high performance program with high degree of parallelism before any "concurrent" modern language was even born. You can not agree if you want. But fact are there, 98% of programs running on the biggest "parallel" machines nowadays (supercomputers) are C, C++ or Fortran. You don't need to be "designed" concurrent to be efficient at it. The same way you do not need to be designed "Cloud-native (bullshit)" to run on a virtual machine.
- fetbaffe 6y ago
  I think that it sets a different mentality if it is part of tools you use, you solve problems differently. It is of course possible to write highly concurrent code in traditional sequential languages and your examples proves that, but supercomputers are a special case with budgets for that. I'm talking about the general case, and I think the post I replied to also assumed that. We have to give programmers, with different backgrounds & training, tools to write high performant code in their everyday job. Many of the tools we use today are not designed for that. We are stuck in a mental model 50 years old that is no longer true. Here are some interesting stackoverflow answers. You are of course free to dismiss these answers as anecdotal. https://stackoverflow.com/a/14637833 https://stackoverflow.com/a/14637833 https://stackoverflow.com/a/2799779 https://stackoverflow.com/a/2799779
SomeoneFromCA 6y ago
You forgot about OpenMP.

Both C and C++ have zero built in knowledge about parallelism, so in a modern world where most things are parallel and asynchronous I don’t agree at all with that statement.

sigotirandolas 6y ago

Both C and C++ have had a concurrent memory model and threads in the standard library for a decade now. And POSIX threads which are pretty much the same thing have been there for a quarter century on *NIX.

fetbaffe 6y ago
Sure, there are libraries for concurrency, but there are no language constructs like in other languages.
- cogman10 6y ago
  What do you mean by language constructs? As in, a `synchronized` keyword? Or are you thinking along the lines of `async` `await`? If you mean the `synchronized` keyword, then correct, they don't have that. Most languages do not have that concept. C++ does have mutexes and has had them since C++11 (nearly a decade). C++ also has as part of the language spec the concept of threads, again, there since C++11. If you meant co-routines, then C++ just added them with C++20. Or do you mean something different like green threads (ala go)? C++ certainly has concurrency constructs and has been expanding them since C++11.
  - fetbaffe 6y ago
    Like Gos goroutines or Erlangs processes. And more of message passing. C++ has added many of these things later on in the standard library, bolted on afterwards.
    - erichocean 6y ago
      If you think that using libraries to do things in C++ means they are "bolted on", then you don't understand C++. The entire design of C++ is to enable efficient libraries for these kinds of things to be built. And it does, and has, and will continue to for decades more.

adev_ 6y ago

> Both C and C++ have zero built in knowledge about parallelism, so in a modern world where most things are parallel and asynchronous I don’t agree at all with that statement. And ? C (even Fortran) had threads and was used to create high performance program with high degree of parallelism before any "concurrent" modern language was even born. You can not agree if you want. But fact are there, 98% of programs running on the biggest "parallel" machines nowadays (supercomputers) are C, C++ or Fortran. You don't need to be "designed" concurrent to be efficient at it. The same way you do not need to be designed "Cloud-native (bullshit)" to run on a virtual machine.

fetbaffe 6y ago
I think that it sets a different mentality if it is part of tools you use, you solve problems differently. It is of course possible to write highly concurrent code in traditional sequential languages and your examples proves that, but supercomputers are a special case with budgets for that. I'm talking about the general case, and I think the post I replied to also assumed that. We have to give programmers, with different backgrounds & training, tools to write high performant code in their everyday job. Many of the tools we use today are not designed for that. We are stuck in a mental model 50 years old that is no longer true. Here are some interesting stackoverflow answers. You are of course free to dismiss these answers as anecdotal. https://stackoverflow.com/a/14637833 https://stackoverflow.com/a/14637833 https://stackoverflow.com/a/2799779 https://stackoverflow.com/a/2799779

SomeoneFromCA 6y ago

You forgot about OpenMP.