Good demo for showing benefits of parallelism
Mikola Lysenko
mclysenk at mtu.edu
Sat Jan 27 14:29:45 PST 2007
There seems to be a great deal of confusion between concurrency and
parallelism. Parallelism is a natural part of many problems, and it is
relatively easy to exploit in order to enhance performance. Parallel
algorithms naturally scale to arbitrary numbers of processors, and are
not particularly difficult to develop.
Concurrency on the other hand is very difficult. When multiple
processes must communicate, the programming complexity quickly spirals
out of control resulting in unmanageable chaotic programs. Locks,
channels and STM are all useful concurrency primitives, but no single
one can be considered a complete solution. The difficulty of concurrent
programming was recognized early on by programmers like Dijkstra who
worked on the first operating systems. To this day, it is still an
unsolved problem and must be approached very carefully on a per-case basis.
In this light, GPU programming should not be considered concurrent
programming, since it is impossible for threads on the GPU to
communicate since all shader memory is read-only. GPU programs are
parallel however, and they are typically not very difficult to write
(beyond some annoyances in the API/shader language). Similarly futures
do not help with concurrent programs, since they only improve the
parallelism inherent within a program.
Shaders, futures and array operations are all helpful, since they
provide convenient mechanisms for utilizing parallelism. However they
utterly fail to address the most difficult aspects of multi-threading,
which means they are not a complete solution.
More information about the Digitalmars-d
mailing list