Deutsch English Français Italiano |
<RsudnRRDUtiEcbL7nZ2dnZfqnPednZ2d@giganews.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: Xl.tags.giganews.com!local-2.nntp.ord.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 29 Apr 2024 18:51:05 +0000 Subject: Re: Threads across programming languages Newsgroups: comp.lang.c++,comp.lang.c References: <GIL-20240429161553@ram.dialup.fu-berlin.de> <RPidnQT6TOLEU7L7nZ2dnZfqnPWdnZ2d@giganews.com> From: Ross Finlayson <ross.a.finlayson@gmail.com> Date: Mon, 29 Apr 2024 11:51:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <RPidnQT6TOLEU7L7nZ2dnZfqnPWdnZ2d@giganews.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <RsudnRRDUtiEcbL7nZ2dnZfqnPednZ2d@giganews.com> Lines: 299 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-My4jWvHXiyoB6OfhyRsJpQZxVbxUdKnoOyj/isk6sU1ISkmQ84iqc9l4gKlVlSSHgrQBuvmWW8cZrrC!3QsTsoRFLVPR5337ksC5Gv9y9lgO76+Usfl138NYBgXyW8OJHeCmmfGU+17C3kwia+TV6dBLrM25!mg== X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 Bytes: 12591 On 04/29/2024 09:44 AM, Ross Finlayson wrote: > On 04/29/2024 08:19 AM, Stefan Ram wrote: >> paavo512 <paavo@osa.pri.ee> wrote or quoted: >> |Anyway, multithreading performance is a non-issue for Python so far as >> |the Python interpreter runs in a single-threaded regime anyway, under a >> |global GIL lock. They are planning to get rid of GIL, but this work is >> |still in development AFAIK. I'm sure it will take years to stabilize the >> |whole Python zoo without GIL. >> >> The GIL only prevents multiple Python statements from being >> interpreted simultaneously, but if you're waiting on inputs (like >> sockets), it's not active, so that could be distributed across >> multiple cores. >> >> With asyncio, however, you can easily handle the application >> for threads to "wait in parallel" for thousands of sockets in a >> single thread, and there are fewer opportunities for errors than >> with multithreading. >> >> Additionally, there are libraries like numpy that use true >> multithreading internally to distribute computational tasks >> across multiple cores. By using such libraries, you can take >> advantage of that. (Not to mention the AI libraries that have their >> work done in highly parallel fashion by graphics cards.) >> >> If you want real threads, you could probably work with Cython >> sometimes. >> >> Other languages like JavaScript seem to have an advantage there >> because they don't know a GIL, but with JavaScript, for example, >> it's because it always runs in a single thread overall. And in >> the languages where there are threads without a GIL, you quickly >> realize that programming correct non-trivial programs with >> parallel processing is error-prone. >> >> Often in Python you can use "ThreadPoolExecutor" to start >> multiple threads. If the GIL then becomes a problem (which is >> not the case if you're waiting on I/O), you can easily swap it >> out for "ProcessPoolExecutor": Then processes are used instead >> of threads, and there is no GIL for those. >> >> If four cores are available, by dividing up compute-intensive tasks >> using "ProcessPoolExecutor", you can expect a speedup factor of two >> to eight. >> >> With the Celery library, tasks can be distributed across multiple >> processes that can also run on different computers. See, for >> example, "Parallel Programming with Python" by Jan Palach. >> > > > > It sort of seems there are two approaches to > the parallel, and the asynchronous. > > There's, "divide-and-conquer", and "information-cooperation". > > The linear-speedup of the embarrassingly parallel > in the divide-and-conquer, or single-instruction-multiple-data, > is a pretty great thing. > > Notions like map-reduce when the count of values > per key is about same and thusly the computing > the aggregates (summaries, digests, aggregate > and analytic functions) can be accomplished by > horizontal scaling (more boxes with same resources), > is another usual divide-and-conquer approach > (horizontal scaling). > > Once upon a time there was this great idea called > "Aglets" or "mobile agents" or "mobile code". This > is basically that a functional program is distributed > to nodes, to run on the facilities of the nodes with > some resources, then to return to the "aglet-hive" > what results can be composed. This is also usually > called anything the "agent" or "instrumentation" > on the box. (The box, a process model, its processes, > their threads, their "inter-thread calls", their "inter-process > calls", their network, a node, a box. Aglets are the > little caps or tape at the end of shoe-laces, here > with regards to notions like "aggregate functions" > and "analytic functions".) > > > The cooperation is basically any notion of a callback. > The callback is one of the fundamental notions of > flow-of-control, and about the most elementary > notion of the functional paradigm in otherwise > the procedural or the imperative paradigm. > > Otherwise for threads to fork, to divide, then > whether they join, is a callback. > > So, first learning the idea of a callback is like, > "you mean I need to provide a different entry > point for this code to return and then where > I'm at is exiting forever as if in a shell process > model exec'ing another process and resulting > that this process becomes that one", and it's > like "yeah, you just give it a callback address > and what results is that's where it goes". > It's functional. > > (Functional/event-driven, procedural/imperative.) > > > Some people learn functional first, and others > procedural first. It's hard to say how people > think, in their mental models of the things, > which is pretty much always flow-machines. > The chip, or the old planar integrated-circuit > the usually standard logic the chip, is systolic, > the systolic flow driven by the systolic clock, > that most people have a flow-model of code. > > > So, there's callbacks, and then there's funnels > and distributors, say, then as with regards to > something like a "Clos network", any kind of > usual model of data-flow, it's a flow-machine. > > Funnels/sprinklers: Venturi effect. > > In flow machines, there's basically something > like "Ford-Fulkerson flow algorithm", which is > a hypothetical sort of algorithm that formalizes > and optimizes flow. > > > Threads fork, and they also join. > > The only hardware threads are independent cores, > and, their semantics of memory barriers, > according to their clocks. The rest is organization > of context and routine and state and stack, > and for the general purpose usually pre-emptive, > or, "time-sharing". > > Or, you know, "nodes". > > > It's a time-sharing system. > > > So, there's processes and a process model, > there's the inter-process, then there's threading > models, and the re-entrant and shared and > the mutex, according to ordering and serial > guarantees or "delivery", it's message-passing > of course, vis-a-vis "the core" or memory, > a monad or a purely functional state, > it's a distributed system of nodes. > > > Once there was an initiative called "Parallel C", > language and compiler extensions to support > language constructs embodying the notions of > the parallel. > > Somebody came up with pi calculus, process > calculus, communicating sequential processes > and the like. I've heard of Djikstra's law yet I > forget it, and any entry point is a "goto". > > In clusters, there's a usual notion of message-passing, > often organized about the process model among nodes > of the cluster. There's MPI and old Silicon Grid Engine. > Once there was Wolfpack cluster. The clusters are > often mounted in a rack together and about things > like Infiniband networking and NUMA memory. > > "HPC" they call it, though that includes both > clusters the horizontally scale-able, and also > computers of the super-scalar word variety. > ========== REMAINDER OF ARTICLE TRUNCATED ==========