7 ms·
OpenMP's [0] #pragma parallel directives function very much in the same way. The following code: #pragma omp parallel for for (size_t i = 0; i < limit; i+
by eqvinox 6y ago
OpenMP's [0] #pragma parallel directives function very much in the same way. The following code:
#pragma omp parallel for
for (size_t i = 0; i < limit; i++)
whatever();
fully encapsulates the workload distribution and rejoining. By the time the code after the loop executes, all parallel execution of the loop is done.
[0] https://en.wikipedia.org/wiki/OpenMP https://en.wikipedia.org/wiki/OpenMP, earliest versions dating to 1997
- Laremere 6y agoThere are important distinctions between this code and what it proposed by the OP. See the sections https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#nurseries-support-dynamic-task-spawning https://vorpus.org/blog/notes-on-structured-concurrency-or-g... and https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/#there-is-an-escape https://vorpus.org/blog/notes-on-structured-concurrency-or-g... These differences elevate this proposal from handling parallel computation (something that is fairly easy to reason about with normal go routines anyways), to something that actually handles concurrency use cases in general.
- eqvinox 6y agoI was simply making an observation on what the control flow looks like on a source code level, nothing more and nothing less. OpenMP is, as you say, designed for computation, hence the directives it provides. The control flow is still majorly different from go routines, and the argument for this source code expression is IMHO the quintessence of the article. There simply is less to reason about if you have these constructs. With a go routine you still need a join somewhere, which makes it "unstructured" like gotos.