Re: threads and stuff (was Re: Perl’s leaky bucket)

Thank you, appreciate the reply. To avoid collision with the other 
thread, I update the subject.

So I suppose this cuts to the heart of the matter. It's fair, I believe, 
that "top level 'threading'" is not something that can be reasonable 
supported in the perl runtime (and to be fair, other scripting languages 
also struggle greatly with this).

The question, then goes to: how do we facilitate access to the native 
platform's SMP? Perhaps the answer is, as always, "it depends."

I will continue to pound my head on this, something will shake loose. In 
the meantime, as proof that I am vested in seeing some interesting 
options shake loose, I have offered a module on CPAN called 
OpenMP::Environment.

It only provides programmatic manipulation of the environmental 
variables that OpenMP programs care about; but it is a necessary step 
for me to investigate and gain some intuition about what is possible and 
what looks "right".

Currently I am thinking a SIMD (single instruction, multiple data) 
approach is the most accessible. This doesn't really get at what is 
ideal (in my mind), but at least provides a path forward by creating 
threaded libraries made available via Inline::C/XS/FFIs - and even 
leveraging these via a tie interface. And if the direction of providing 
SIMD "data types" is truly the best direction, PDL seems like a really 
good target for that.

Thanks for all the feedback, will monitor the list/thread. I do ask that 
we keep the whole idea of threading "where and when feasible" (even in 
language design considerations) is extremely important to Perl's long 
term viability and as a driver of important capabilities. The idea of 
using Perl to efficiently max out a large SMP machine for useful work is 
very exciting to me, and I think I am not the only one.

Cheers,
Brett


On 4/8/21 3:42 AM, Konovalov, Vadim wrote:
>> Nicholas Clark <nick@ccl4.org> wrote:
>>> On Wed, Apr 07, 2021 at 10:49:05AM -0500, B. Estrade wrote:
>>>
>>>> Here's some food for thought. When was was the last time anyone had a
>>>> serious discussion of introducing smp thread safety into the language? Or
>>>> easy access to atomics? These are, IMO, 2 very important and serious things
>>>
>>> Retrofitting proper multicore concurrency to perl would imply that it's
>>> possible at all.
>>>
>>> None of the comparable C-based dynamic languages have done it (eg Python,
>>> Ruby)
> 
> Both Python and Ruby are not a good place to learn on how multiprocessing happens.
> There is much better place to learn from - Julia.
> 
> Julia made interesting approach: syntax highly inspired by Python, but correctly
> deals with multithreading. In a sense - this is much developed Python with all missing
> features added into completely different language.
> 
> Very interesting approach, and I suppose this is about what perl community intended
> to implement when perl6 discussion have begun in 2000.
> 
> 
> 
>>> Ruby's new experimental new threading is an actor model (I believe) CPython
>>> is dogged by the GIL (all the threads you like, but if you're CPU bound then
>>> you're making one core very toasty) The seem to be thinking about going
>>> multicore by doing something like ithreads (using pickle to pass data
>>> structures between MULITPLICITY-like interpreters) but that's likely going
>>> to be as good as ithreads.
> 
> It appears that reference counting + threading results in considerable slow down
> and the solution to the problem is good GC.
> This was "proved" by GILectomy project, see any google video on this or this
> nice summary https://news.ycombinator.com/item?id=11842779
> 
> Perl history on threading (PERL5005THREADS and then ITHREADS where 1st was
> deprecated and removed while 2nd was recently deprecated) gives me think
> that no real multithreading/multicoring is actually possible on language level.
> Developing into that direction now is just wasting of time.
> 
> "async" is another story, which is Javascript way, where basic JS engine V8 is single-threaded.
> 
> 

• Re: threads and stuff (was Re: Perl’s leaky bucket) by B. Estrade
• Re: threads and stuff (was Re: Perl’s leaky bucket) by Yuki Kimoto