Threading in Parrot vs Perl
On Thu, 2005-04-28 at 10:00, Luke Palmer wrote: Aaron Sherman writes: Well, more to the point, autothreading of junctions will hit the wall of Parrot duping the interpreter. That's probably not something you want to suffer just to resolve a junction, is it? What? Why will it do that? Why? Well, you can read what Dan wrote, 'cause I'm sure not going to pretend I'm enough of a threads programmer to have an educated opinion: http://groups-beta.google.com/group/perl.perl6.internals/msg/18b86bff49cac5a0?dmode=source We'd decided that each thread has its own interpreter. Parrot doesn't get any lighter-weight than an interpreter, since trying to have multiple threads of control share an interpreter seems to be a good way to die a horrible death. -Dan Sugalski / 14 Apr 2005 I'm not saying it's a good or bad thing, but people on THIS list seem to keep pretending that threading will be light-weight, and unless I'm misunderstanding what each thread has its own interpreter means (and Dan confirmed it in pretty clear terms when I asked), that's simply not the case. Dan's terse followup is at: http://groups-beta.google.com/group/perl.perl6.internals/msg/e1885fc6da8aa068?dmode=sourcehl=en -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Threading in Parrot vs Perl
On Thu, Apr 28, 2005 at 12:46:53PM -0400, Aaron Sherman wrote: On Thu, 2005-04-28 at 10:00, Luke Palmer wrote: Aaron Sherman writes: Well, more to the point, autothreading of junctions will hit the wall of Parrot duping the interpreter. That's probably not something you want to suffer just to resolve a junction, is it? What? Why will it do that? Why? Well, you can read what Dan wrote, 'cause I'm sure not going to pretend I'm enough of a threads programmer to have an educated opinion: http://groups-beta.google.com/group/perl.perl6.internals/msg/18b86bff49cac5a0?dmode=source We'd decided that each thread has its own interpreter. Parrot doesn't get any lighter-weight than an interpreter, since trying to have multiple threads of control share an interpreter seems to be a good way to die a horrible death. -Dan Sugalski / 14 Apr 2005 I believe these are two distinct uses of the term threading. Autothreading of junctions is orthogonal to parrot interpreter threads. Junction autothreading does *NOT* require interpreter threads. Junction autothreading just means that routines will be executed for each element of the junction (not necessarily in parallel). Someone correct me if I'm wrong. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Threading in Parrot vs Perl
Aaron Sherman wrote: On Thu, 2005-04-28 at 10:00, Luke Palmer wrote: Aaron Sherman writes: Well, more to the point, autothreading of junctions will hit the wall of Parrot duping the interpreter. That's probably not something you want to suffer just to resolve a junction, is it? What? Why will it do that? Why? Well, you can read what Dan wrote, 'cause I'm sure not going to pretend I'm enough of a threads programmer to have an educated opinion: I would be dismayed if autothreading used threads to accomplish it's goals. Simple iteration in a single interpreter should be more than sufficient. -- Rod Adams
Re: Threading in Parrot vs Perl
On Thu, 2005-04-28 at 13:55, Rod Adams wrote: I would be dismayed if autothreading used threads to accomplish it's goals. Simple iteration in a single interpreter should be more than sufficient. Sorry, I misunderstood. Thanks for the clarification. -- Aaron Sherman [EMAIL PROTECTED] Senior Systems Engineer and Toolsmith It's the sound of a satellite saying, 'get me down!' -Shriekback
Re: Threading in Parrot vs Perl
RA == Rod Adams [EMAIL PROTECTED] writes: RA I would be dismayed if autothreading used threads to accomplish it's RA goals. Simple iteration in a single interpreter should be more than RA sufficient. how autothreading is implemented is distinct from the language feature. a simple version is the iteration mentioned above. but on a multiprocessor with (poosibly prespawned) threads on a large junction, it could be much faster to use parrot threads. but that is just an optimization which uses parallel processing and is not needed for working junction semantics. larry has hinted that autothreading could be parallel underneath if that is supported. maybe choosing the desired implementation would be a pragma. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Threading in Parrot vs Perl
Rod Adams wrote:
I would be dismayed if autothreading used threads to accomplish it's
goals. Simple iteration in a single interpreter should be more than
sufficient.
For sure. No point in doing 10_000 cycles to set up a scratch area
for a single boolean test that might take 10 cycles.
A software transaction (atomic { } block) behaves in many ways like
setting up a new interpreter thread and exiting at the end. I expect
these will be more lightweight than a real thread... in some cases
able to be reduced to no-ops.
So, implementing autothreading using STM as the 'localizing' engine
is another possibility within a single process/thread.
Sam.
