修訂 | 9ddb3500882739ab7f015df02a372e3151d6bd1e (tree) |
---|---|
時間 | 2022-07-05 16:52:02 |
作者 | Albert Mietus < albert AT mietus DOT nl > |
Commiter | Albert Mietus < albert AT mietus DOT nl > |
asis
@@ -11,8 +11,8 @@ | ||
11 | 11 | :tags: Castle, Concurrency |
12 | 12 | |
13 | 13 | I always claim that most computers will have 1024 or more cores before my retirement. And that most embedded systems |
14 | - will have even more, a decade later. However, it’s not easy to write technical software for those massive-parallel | |
15 | - embedded computers; not with most, current languages -- simple because a developer has to put in too many details. | |
14 | + will have even more, a decade later. However, it’s not easy to write technical software for those “massive-parallel | |
15 | + embedded computers”; not with most, current languages -- simple because a developer has to put in too many details. | |
16 | 16 | Accordingly, the “best, ever” programming language should facilitate and support “natural concurrency”. |
17 | 17 | |
18 | 18 | In Castle, you can easily write code that can run efficiently on thousands of cores. |
@@ -48,7 +48,7 @@ | ||
48 | 48 | Although the promise of Multi-Core_ is an unlimited expansion of speed, it requires us to adapt our programming |
49 | 49 | abilities. Transitional “sequential” programs take for granted that the CPU can do only one thing at a time; at many |
50 | 50 | levels. With Multi-Core_ this fundamentally changed. There is no speed-up when we don’t use all cores. This is not much |
51 | -of an issue for a low number of cores; there are plenty of other/background tasks. Even ‘single threaded’ code will | |
51 | +of an issue for a low number of cores; there are plenty of other/background tasks. Even ‘single threaded’ code will | |
52 | 52 | run faster when “your core” isn’t interrupted; when those auxiliary processes can run in parallel on another core. |
53 | 53 | |
54 | 54 | When the number of cores rises this does not scale; more and more cores become idle. Now, your code has to use both |
@@ -58,22 +58,39 @@ | ||
58 | 58 | Threading |
59 | 59 | --------- |
60 | 60 | |
61 | -Threads have become popular to implement parallelism; but have there drawbacks They originated (long, long back) in | |
62 | -“realtime & embedded” programming; when those systems didn’t have a OS. Other computers (mostly unix/posix) used | |
63 | -processes (and Windows/Dos was not existing, or single threaded). Mid 199x, threads become available as “real-time | |
64 | -extensions” on processed; initially within a single process — and so running on a single core. This was long before | |
65 | -Multi-Core_ hardware become available; and many studies exist on how to combine threads & process — should the kernel | |
66 | -handle that or not, and how to avoid overhead. Nowadays this discussion is void, as we expect that threads can run | |
67 | -really in parallel, on multiple cores | |
61 | +Threads_ have become popular to accomplish parallelism but have drawbacks too. They originated (long, long back) in | |
62 | +“real-time & embedded” programming; -- those systems didn't have an OS nor processes and used a concept that resembles | |
63 | +threads. Other computers (mostly Unix/Posix) used “processes” to run many tasks --Windows/Dos wasn't relevant; it was | |
64 | +(mostly) single-user. Mid 199x threads_ become available as “real-time extensions”; initially within a single process — | |
65 | +and so running on a single core. Al this was long before Multi-Core_ hardware was accessible, and studies started on how | |
66 | +to combine threads & processes — should the kernel handle that or not, and how to avoid overhead. Nowadays, this | |
67 | +discussion is void, as we need threads_ that can run in parallel on multiple cores. | |
68 | + | |
69 | +Bugs | |
70 | +~~~~ | |
71 | +A lot of new bugs popped up when developers started to use threads_. One had to learn about concurrency_, parallelism_, | |
72 | +and their difference. And that two threads can be intertwined in not foreseen ways; multiple threads_ can access | |
73 | +the same variable. A single line became suddenly not atomic anymore -- even a single assignment is not. | |
74 | + | |
75 | +|BR| We | |
76 | +mastered that today, at least mostly. There are still many quizzes about that, and many do not pass the tricky | |
77 | +ones. More bothersome is that no one knows how to compose tests to verify the absents of this kind of Heisenbugs_ | |
78 | + | |
79 | +Overhead | |
80 | +~~~~~~~~ | |
81 | +Threads have more handicaps: it is hard to gain the speed-up aiming for. Partly because threads_ themself have a lot of | |
82 | +overhead (especially to start/stop them). But it is also hard to “get” the right number of threads_. Many opinions on | |
83 | +this exist -- like one thread per core [#wrong]_ -- but hardly (or non) theory on this. | |
84 | + | |
85 | +A bigger factor is indirect overhead; especially in CPU-bound (see below) systems. Then, the outcome of a calculation in | |
86 | +one thread is routinely needed for an algorithm in another thread -- if not, why use threads? That involves sharing data [#share]_ | |
68 | 87 | |
69 | 88 | |
89 | +IO vs CPU Bound | |
90 | +--------------- | |
70 | 91 | |
71 | -Flaws due concurrency | |
72 | -===================== | |
73 | - | |
74 | -* Overhead: slower ipv faster | |
75 | -* Heisenbugs_ | |
76 | - | |
92 | +Alternatives | |
93 | +============ | |
77 | 94 | |
78 | 95 | |
79 | 96 | Castle activates all cores |
@@ -123,7 +140,19 @@ | ||
123 | 140 | the application- a web-, and database-server. And “the web itself” has many active components, like routers, ect. And |
124 | 141 | all are programmed in a style that the developer doesn't need to know all those details(!). |
125 | 142 | |
126 | - | |
143 | +.. [#wrong] | |
144 | + Having a 1:1 relation is very populair point of view, at some places. But most probably wrong -- although that is an | |
145 | + assumption too. In addition, it does not scale (what when the number of core double?), and hard to manage. | |
146 | + |BR| | |
147 | + Also see: the section about IO- vs CPU bound. | |
148 | + | |
149 | +.. [#share] | |
150 | + Sharing can be done by a shared-data or by sending messages. For the developer the latter has the advantage that no | |
151 | + (synchronised) shared, variables are needed. But that us just an abstraction; at a lower level there is some memory | |
152 | + that is written by one an read by another thread -- and so need synchronisation and exclusiveness. | |
153 | + | |
154 | + | |
155 | + | |
127 | 156 | .. _Multi-Core: https://en.wikipedia.org/wiki/Multi-core_processor |
128 | 157 | .. _Concurrency: https://en.wikipedia.org/wiki/Concurrency_(computer_science) |
129 | 158 | .. _parallelism: https://en.wikipedia.org/wiki/Parallel_computing |