Front page | perl.perl5.porters |
Postings from July 2021
* Yuki Kimoto <kimoto.yuki@gmail.com> [2021-07-29 12:59:36 +0900]: > 2021-7-26 0:26 Oodler 577 via perl5-porters <perl5-porters@perl.org> wrote: > > > > > The ideas of "practical" concurrency is way more important to > > perl/Perl's future than virtually any other issue. This includes > > Perl OOP. p5p, I agree, is not the place for most of what'd be > > captured on any list. > > > > > The word "concurrency" is always ambiguous when people talk about > "concurrency". > > I hear the this conversation "Perl doesn't have concurrency, so Perl can't > use CPUs in parallel" The perl run time is sequential. A better way to say it, is that the per run time's memory model is sequential, meaning there is zero shared memory. > > But, I know the pre-fork model Perl web applications are using CPUs in > parallel. > > I think we need to properly classify concurrency(fork, thread, I/O, > CPU(OpenMP), GPU, coroutine, async/await syntax) before we say we want to > add concurrency. I agree 100%. Typically, OpenMP is accomplished at low level with pthreads. Note, PDL also has a way to invoke pthreads: https://metacpan.org/dist/PDL/view/Basic/Pod/ParallelCPU.pod But, in general your list seems sufficient to start a conversation somewhere. Each type of "concurrency" can be solved by a variety of different interface approached (read: CPAN module). My personal interest is shared memory, even if it's among fork'd child processes. By my current investigations are looking at using OpenMP inside of C functions defined using Inline::C. Brett -- -- oodler@cpan.org oodler577@sdf-eu.org SDF-EU Public Access UNIX System - http://sdfeu.org irc.perl.org #openmp #pdl #nativeThread Previous | Thread Next