develooper Front page | perl.perl6.internals | Postings from January 2002

Re: interpreter passing (was Re: Large string patch)

Thread Previous | Thread Next
From:
Dan Sugalski
Date:
January 1, 2002 10:06
Subject:
Re: interpreter passing (was Re: Large string patch)
Message ID:
5.1.0.14.2.20020101130019.022ee788@pop.sidhe.org
At 09:30 AM 1/1/2002 -0800, Benjamin Stuhl wrote:
>--- Dan Sugalski <dan@sidhe.org> wrote:
> > At 07:30 AM 12/30/2001 -1000, David & Lisa Jacobs wrote:
> >
> > >From: "Dan Sugalski" <dan@sidhe.org>
> > > > At 08:33 PM 12/29/2001 -1000, David & Lisa Jacobs
> > wrote:
> > > > GC will manage all the memory. Everything managed
> > should either be hung
> > >off
> > > > a PMC or an internal structure. (There are GC hooks
> > in the vtable for
> > > > complex things)
> > >
> > >So does that mean I can get rid of passing around the
> > interpreter?
> >
> > Sort of. Memory and structure (pmc header & string
> > header) allocation must
> > be from interpreter-local pools. There's a patch to use
> > TLS for the
> > interpreter pointer rather than passing it as an
> > argument--I've pretty much
> > decided it's The Way To Go, so I'm going to dig it out
> > and apply it.
> >
> > So you still need the interpreter pointer, you just don't
> > have to pass it.
>
>Are you really sure about this?

Yes.

>The reason perl5 threads
>are MULTIPLICITY-based (pass around an interpreter pointer)
>is that Sarathy got a noticeable speedup from not having to
>call pthread_getspecific() every time he needed to allocate
>memory or look up a symbol.

Perl 5 is hampered by its past in a lot of places. This would be one of 
them. Sarathy's decision on how to go was constrained by perl's current 
design. And personal preference, but that goes without saying for any 
designer. Perl 5 called pthread_getspecific far too many times. I put in a 
patch to use the unchecked version on VMS & Tru64 Unix and got an insane 
speedup. (And we will use the same trick with parrot, 'cause I'm officially 
Evil :) It was caused in part by perl's macro-itis. It was getting called 
in a lot of places it didn't need to be.

Passing around extra parameters is costlier than you'd think. (Like ~5-10% 
of function call time) Anyway, we'll benchmark things and see what's best.

					Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                      teddy bears get drunk


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About