5 ms·

"Trivial" to write parallel programs in C? You should stop doing whatever it is that you're doing, because you are in the top 0.00000000001% of programmers, in

"Trivial" to write parallel programs in C? You should stop doing whatever it is that you're doing, because you are in the top 0.00000000001% of programmers, in the Universe, and I want to work on whatever multi-billion dollar startup you undoubtedly have going on.

chrisseaton 10y ago
I said it is trivial to parallelise a C program that implements an embarrassingly parallel algorithm. Embarrassingly parallel means no resources need to be shared, and there needs to be no communication, so no need for locks or messages, even in C. That's why I say it'd be trivial to parallelise it. Just add a pthread_start. Of course almost no applications are embarrassingly parallel.
- m00x 10y ago
  And then you also need to implement mailboxes to receive new data, supervisors to watch the threads and revive them when they fail, initialization methods to get back to the original state, etc. You can trivialize any issue if you ignore all the facts, but it doesn't make your argument have any correctness.
  - BeetleB 10y ago
    I'm really surprised at the arguing in this thread. Embarrassingly parallel algorithms are trivial in pretty much every language. That is why is embarrassing. >And then you also need to implement mailboxes to receive new data If you did, it is not embarrassingly parallel. You know, a huge amount of parallel work is done in C/C++. It was the language used for multiple parallel algorithms courses in my university. Being able to do basic MPI type stuff in C does not make you a top programmer. And not being able to do an embarrassingly parallel algorithm in C would ring alarm bells.
    - ww520 10y ago
      People's obsession with language choice often cloud their judgement.
ww520 10y ago
Parallel programs really are not that hard to write. The hard part is figuring out how to make a problem into embarrassing parallel. Once that's figured out, the coding is simple. In this case, the language choice won't help.
- MaulingMonkey 10y ago
  > Parallel programs really are not that hard to write. Yes... but! > The hard part is figuring out how to make a problem into embarrassing parallel The other hard part is the debugging - especially when you fall short in the "embarrassingly" department. It's not until C11 that the language itself had any notion of multithreading without reaching out to a separate standard - POSIX - and various nonstandard compiler extensions required to implement it all (e.g. for memory barriers to constrain the reordering of code) I've further found it distressingly frequent that in porting code from one platform to another that basic primitives are plainly broken to the point where I can write unit tests to catch the issue - usually leveraging e.g. ARM hardware and it's weaker memory ordering semantics, a topic which few fully understand. For example, a "lock free" circular queue one might use to implement a task system to roll your embarassingly parallel programs atop of. Which were indeed lock free - and volatile free - and atomic free - and memory barrier free - and used in parallel from multiple threads... Even the experts occasionally forget a mutex lock or something. I play catchup with additional static analysis annotations when new compilers expose new options to catch this kind of thing, but...
  - slrz 10y ago
    Static analysis is, of course, very restricted in what it can give you answers to, although I'd still love to have more advanced tools widely available. What I really consider a game-changer for concurrent programming are the dynamic checkers integrated into recent versions of GCC and Clang (and the Go compilers, too). Those make it super easy to flag data races and don't have any false positives. Caveats apply, naturally, as they can only flag those races that actually happen during a particular execution of your code. While Valgrind and similar tools could do that for years, the difference with TSan is speed. It's fast enough that you can use it all the time during development. Same for AddressSanitizer and the undefined behaviour checkers.

chrisseaton 10y ago

I said it is trivial to parallelise a C program that implements an embarrassingly parallel algorithm. Embarrassingly parallel means no resources need to be shared, and there needs to be no communication, so no need for locks or messages, even in C. That's why I say it'd be trivial to parallelise it. Just add a pthread_start. Of course almost no applications are embarrassingly parallel.

m00x 10y ago
And then you also need to implement mailboxes to receive new data, supervisors to watch the threads and revive them when they fail, initialization methods to get back to the original state, etc. You can trivialize any issue if you ignore all the facts, but it doesn't make your argument have any correctness.
- BeetleB 10y ago
  I'm really surprised at the arguing in this thread. Embarrassingly parallel algorithms are trivial in pretty much every language. That is why is embarrassing. >And then you also need to implement mailboxes to receive new data If you did, it is not embarrassingly parallel. You know, a huge amount of parallel work is done in C/C++. It was the language used for multiple parallel algorithms courses in my university. Being able to do basic MPI type stuff in C does not make you a top programmer. And not being able to do an embarrassingly parallel algorithm in C would ring alarm bells.
  - ww520 10y ago
    People's obsession with language choice often cloud their judgement.

ww520 10y ago

Parallel programs really are not that hard to write. The hard part is figuring out how to make a problem into embarrassing parallel. Once that's figured out, the coding is simple. In this case, the language choice won't help.

MaulingMonkey 10y ago
> Parallel programs really are not that hard to write. Yes... but! > The hard part is figuring out how to make a problem into embarrassing parallel The other hard part is the debugging - especially when you fall short in the "embarrassingly" department. It's not until C11 that the language itself had any notion of multithreading without reaching out to a separate standard - POSIX - and various nonstandard compiler extensions required to implement it all (e.g. for memory barriers to constrain the reordering of code) I've further found it distressingly frequent that in porting code from one platform to another that basic primitives are plainly broken to the point where I can write unit tests to catch the issue - usually leveraging e.g. ARM hardware and it's weaker memory ordering semantics, a topic which few fully understand. For example, a "lock free" circular queue one might use to implement a task system to roll your embarassingly parallel programs atop of. Which were indeed lock free - and volatile free - and atomic free - and memory barrier free - and used in parallel from multiple threads... Even the experts occasionally forget a mutex lock or something. I play catchup with additional static analysis annotations when new compilers expose new options to catch this kind of thing, but...
- slrz 10y ago
  Static analysis is, of course, very restricted in what it can give you answers to, although I'd still love to have more advanced tools widely available. What I really consider a game-changer for concurrent programming are the dynamic checkers integrated into recent versions of GCC and Clang (and the Go compilers, too). Those make it super easy to flag data races and don't have any false positives. Caveats apply, naturally, as they can only flag those races that actually happen during a particular execution of your code. While Valgrind and similar tools could do that for years, the difference with TSan is speed. It's fast enough that you can use it all the time during development. Same for AddressSanitizer and the undefined behaviour checkers.