| Revision | 3346b1562c80c9809b118b6296e3732b8db12f16 (tree) |
|---|---|
| Time | 2022-07-06 23:33:51 |
| Author | Albert Mietus < albert AT mietus DOT nl > |
| Commiter | Albert Mietus < albert AT mietus DOT nl > |
Started with (8) BusyCores-concepts (analyse)
CCastle/2.Analyse/8.BusyCores-concepts.rst (diff)| @@ -10,13 +10,17 @@ | ||
| 10 | 10 | :category: Castle DesignStudy |
| 11 | 11 | :tags: Castle, Concurrency |
| 12 | 12 | |
| 13 | - Effectively making benefit thousands of cores, as I announced in :ref:`BusyCores` is not easy. Many languages put it | |
| 14 | - on the shoulders of the developer: usually by referring to pthreads_. | |
| 13 | + In the near future, more and more cores will become available as described in :ref:`BusyCores` And Castle should | |
| 14 | + make it easy to write code for all of them; not to keep them busy, but maximize speed up [useCase: | |
| 15 | + :need:`U_ManyCore`]. | |
| 15 | 16 | |BR| |
| 16 | - But there is more below the horizon then just “Threads_”! | |
| 17 | + We also discused threads_, they do not scale well for CPU-bound (embedded) systems, and that er are contemporary, | |
| 18 | + abstractions on top of them --although the not always fit nicely in existing languages. | |
| 17 | 19 | |
| 18 | - Let discover some concepts that can help to design prober support, and unburden the typical (moderen, embedded) | |
| 19 | - developer. | |
| 20 | + As Castle is a new language we have the opportunity to select such a concept, and incorporate it in the language ... | |
| 21 | + | |
| 22 | + In this blog we analyse the options; not focusing in the syntax, but on semantics and implementation details: Does | |
| 23 | + it scale and will it be effectively on many, many cores | |
| 20 | 24 | |
| 21 | 25 | ---------- |
| 22 | 26 |
Fork