- File:
-
- 1 edited
-
doc/proposals/concurrency/text/parallelism.tex (modified) (1 diff)
Legend:
- Unmodified
- Added
- Removed
-
doc/proposals/concurrency/text/parallelism.tex
r64b272a r3364962 28 28 While the choice between the three paradigms listed above may have significant performance implication, it is difficult to pindown the performance implications of chosing a model at the language level. Indeed, in many situations one of these paradigms may show better performance but it all strongly depends on the workload. Having a large amount of mostly independent units of work to execute almost guarantess that the \gls{pool} based system has the best performance thanks to the lower memory overhead (i.e., not thread stack per job). However, interactions among jobs can easily exacerbate contention. User-level threads allow fine-grain context switching, which results in better resource utilisation, but a context switch is more expensive and the extra control means users need to tweak more variables to get the desired performance. Finally, if the units of uninterrupted work are large enough the paradigm choice is largely amortised by the actual work done. 29 29 30 \TODO 31 30 32 \section{The \protect\CFA\ Kernel : Processors, Clusters and Threads}\label{kernel} 33 31 34 32 35 \subsection{Future Work: Machine setup}\label{machine}
Note:
See TracChangeset
for help on using the changeset viewer.