Mailing List Archive

> [Cool stuff about new alias module deleted]

Thanks Gurusamy!

It may or may not work for me though, since my Objects are also tied,
since the 'real' instance variables live in the Objective-C runtime.

I had a (perl based) solution almost working using tie, but I am
having trouble with caller:

Is it possible, that DB::args does not work, if perl was not compiled
with debugging on? My code works fine with libperld, but not with
libperl (DB::args undefined!).

Could someone verify that?

---
Gerd Knops ------------------------------------------ gerti@BITart.com

Gerd Knops wrote:
>
> Is it possible, that DB::args does not work, if perl was not compiled with
> debugging on? My code works fine with libperld, but not with libperl
> (DB::args undefined!).
>

Oh well. Further investigation showed that the problem is a little
uglier than that. I restart perl multiple times within the same
program. During the first run, DB::args work fine, at all following
runs DB::args is undefined.

I tried experimenting with destruct_level, only to get a bunch of
'Attempt to free unreferenced scalar during global destruction.'
messgaes, followed by a
'Memory access exception on address 0x23232323'.

Hmmm...

I need some sleep now.

---
Gerd Knops ------------------------------------------ gerti@BITart.com

Gerd Knops wrote:
>
> Is it possible, that DB::args does not work, if perl was not compiled with
> debugging on? My code works fine with libperld, but not with libperl
> (DB::args undefined!).
>

Oh well. Further investigation showed that the problem is a little
uglier than that. I restart perl multiple times within the same
program. During the first run, DB::args work fine, at all following
runs DB::args is undefined.

I tried experimenting with destruct_level, only to get a bunch of
'Attempt to free unreferenced scalar during global destruction.'
messgaes, followed by a
'Memory access exception on address 0x23232323'.

Hmmm...

I need some sleep now.

---
Gerd Knops ------------------------------------------ gerti@BITart.com

: Gerd Knops wrote:
: >
: > Is it possible, that DB::args does not work, if perl was not compiled with
: > debugging on? My code works fine with libperld, but not with libperl
: > (DB::args undefined!).
: >
:
: Oh well. Further investigation showed that the problem is a little
: uglier than that. I restart perl multiple times within the same
: program. During the first run, DB::args work fine, at all following
: runs DB::args is undefined.
:
: I tried experimenting with destruct_level, only to get a bunch of
: 'Attempt to free unreferenced scalar during global destruction.'
: messgaes, followed by a
: 'Memory access exception on address 0x23232323'.

perl_destruct() assumes you are destructing the whole PerlInterpreter.
You can't reuse the code or the symbol tables after that.

Larry

Larry Wall wrote:
> : Gerd Knops wrote:
> : >
> : > Is it possible, that DB::args does not work, if perl was not compiled
> : > with debugging on? My code works fine with libperld, but not with libperl
> : > (DB::args undefined!).
> : >
> :
> : Oh well. Further investigation showed that the problem is a little uglier
> : than that. I restart perl multiple times within the same program. During
> : the first run, DB::args work fine, at all following runs DB::args is
> : undefined.
> :
> : I tried experimenting with destruct_level, only to get a bunch of 'Attempt
> : to free unreferenced scalar during global destruction.' messgaes, followed
> : by a 'Memory access exception on address 0x23232323'.
>
> perl_destruct() assumes you are destructing the whole PerlInterpreter. You
> can't reuse the code or the symbol tables after that.
>
> Larry

I understand that. I repeat the full sequence of perl_alloc/perl_construct/
perl_parse/perl_run/perl_destruct/perl_free.

What may not be ok in the way I use per is, that I use perl_run to connect
to the Objective-C run time system, but 'the real execution' is done after
this step. It seems to work, though.

I'd much rather would like to use embed and multiplicity, BUT:

- multiplicity (at least with 5.001m) does not work, the
encapsulation does not seem to be perfect (or the memory
managment?)

- All the dynamically loaded modules have to be on the
system twice: once for the 'regular' perl, and once
with embed and multiplicity turned on for 'my perl'.

This is rather anoying. Why is embed/multiplicity not used by
default? It does not seem to require more resources, so why?

---
Gerd Knops ------------------------------------------ gerti@BITart.com

Gerd Knops writes:
>
> This is rather anoying. Why is embed/multiplicity not used by
> default? It does not seem to require more resources, so why?
>

Did you try to debug with EMBED? I did, so I know why it is not on by
default. Multiplicity will be buggy until _you_ (who needs it ;-) will
correct it. When it is bug-free, it may be enabled by default, if this
does not add additional overhead (and it does, obviously the overhead
should be the same as with dynamic linking: extra redirection).

Let the people who know hardware correct me on the last point.

Ilya

: I understand that. I repeat the full sequence of perl_alloc/perl_construct/
: perl_parse/perl_run/perl_destruct/perl_free.

But notice that perl_construct doesn't re-initialize unless you define
MULTIPLICITY. I suppose it's a goof that MULTIPLICITY doesn't distinguish
multiple serial interpreters from multiple parallel interpreters.

: What may not be ok in the way I use per is, that I use perl_run to connect
: to the Objective-C run time system, but 'the real execution' is done after
: this step. It seems to work, though.
:
: I'd much rather would like to use embed and multiplicity, BUT:
:
: - multiplicity (at least with 5.001m) does not work, the
: encapsulation does not seem to be perfect (or the memory
: managment?)
:
: - All the dynamically loaded modules have to be on the
: system twice: once for the 'regular' perl, and once
: with embed and multiplicity turned on for 'my perl'.
:
: This is rather anoying. Why is embed/multiplicity not used by
: default? It does not seem to require more resources, so why?

MULTIPLICITY runs 5-10% slower because it makes many globals have an
extra level of indirection, since there is now a pointer to the current
interpreter structure that has to be dereferenced constantly. There
isn't any overhead for EMBED, except for typing overhead when you're
trying to debug.

Larry

> From: Ilya Zakharevich <ilya@math.ohio-state.edu>
>
> Gerd Knops writes:
> >
> > This is rather anoying. Why is embed/multiplicity not used by
> > default? It does not seem to require more resources, so why?
>
> Did you try to debug with EMBED? I did, so I know why it is not on by
> default. Multiplicity will be buggy until _you_ (who needs it ;-) will
> correct it. When it is bug-free, it may be enabled by default, if this
> does not add additional overhead (and it does, obviously the overhead
> should be the same as with dynamic linking: extra redirection).

Yes, every per-interpreter symbol (155) is no longer a 'global' at a fixed
address which can be directly fetched by the processor but now requires
a run-time structure member deref.

Since per-interpreter symbols are at the very heart of perl execution
it's bound to be a cost. With dynamic linking you pay the price per
call to a dynamically loaded function, with multiplicity you pay the
price for access to key internal data within perl internal functions
and, in many cases, within tight loops.

I've no idea really but as a wild guess I'd say 5 to 10%, maybe more.
The significance of that 5 to 10% is a matter of judgement.

I'd be *very* interested if someone has time to run some benchmarks
(without -DDEBUGGING).

Tim.

p.s. Anyone fancy starting an informal to-do list focused on additions
for 5.003?

: On most modern RISC processors it is entirely possible that referencing
: a struct field will be faster than referencing a global variable (assuming
: the struct pointer manages to get in a register - if it is a global variable
: then it probably won't be faster :-).

Um, do you consider a Sparc 2 to be a "modern RISC processor"? That's where
my 5-10% slower figure comes from.

Larry

Larry Wall wrote:
> : I understand that. I repeat the full sequence of perl_alloc/perl_construct/
> : perl_parse/perl_run/perl_destruct/perl_free.
>
> But notice that perl_construct doesn't re-initialize unless you define
> MULTIPLICITY.

Thanks for the tip.

Just tried that by using a modified perl_construct with the MULTIPLICITY
lines enabled, but that did not fix the problem (which was that @DB:args
does work in the first 'run' of perl, but is undefined in every following
loop).

The code in PP(pp_caller) gets executed, dbargs is defined etc. There
seems to be a problem with cx->blk_sub.argarray, which is 'empty'.

---
Gerd Knops ------------------------------------------ gerti@BITart.com

Tim Bunce wrote:
> > From: Ilya Zakharevich <ilya@math.ohio-state.edu>
> >
> > Gerd Knops writes:
> > >
> > > This is rather anoying. Why is embed/multiplicity not used by default? It
> > > does not seem to require more resources, so why?
> >
> > Did you try to debug with EMBED? I did, so I know why it is not on by
> > default. Multiplicity will be buggy until _you_ (who needs it ;-) will
> > correct it. When it is bug-free, it may be enabled by default, if this does
> > not add additional overhead (and it does, obviously the overhead should be
> > the same as with dynamic linking: extra redirection).
>
> Yes, every per-interpreter symbol (155) is no longer a 'global' at a fixed
> address which can be directly fetched by the processor but now requires a
> run-time structure member deref.
>
> Since per-interpreter symbols are at the very heart of perl execution it's
> bound to be a cost. With dynamic linking you pay the price per call to a
> dynamically loaded function, with multiplicity you pay the price for access
> to key internal data within perl internal functions and, in many cases,
> within tight loops.
>

lock_focus(sv_interp)?

---
Gerd Knops ------------------------------------------ gerti@BITart.com

>: On most modern RISC processors it is entirely possible that referencing
>: a struct field will be faster than referencing a global variable (assuming
>: the struct pointer manages to get in a register - if it is a global variable
>: then it probably won't be faster :-).
>
>Um, do you consider a Sparc 2 to be a "modern RISC processor"? That's where
>my 5-10% slower figure comes from.

I don't know much about the Sparc architecture. The Power PC and 88110 are
the ones I'm most familiar with. On both of those, it takes 2 instructions
to reference a global variable at an arbitrary 32 bit address and only one
instruction to reference a structure field (assuming the field offset fits
in 16 bits) if you already have a register pointing to the structure.

Of course, once optimizers get into the act, you wind up with global
references being squeezed down into single instruction references and
possibly even being turned into common sub-expressions, while referencing a
fields of a structure indirect through a pointer probably never gets turned
into a CSE because most C compilers aren't up to the heavy duty alias
analysis required to prove some other pointer indirection didn't clobber the
value. Its always hard to look at a single factor and make a guess about
what might happen to overall performance when all the other factors
get mixed in... (and I didn't even mention instruction scheduling :-).

--
Tom.Horsley@mail.hcsc.com
Home: 511 Kingbird Circle Delray Beach FL 33444
Work: Harris Computers, 2101 W. Cypress Creek Rd. Ft. Lauderdale FL 33309
Support Project Vote Smart! They need your support in non-election years too!
(email pvs@neu.edu, 1-800-622-SMART, http://www.vote-smart.org)

: Just tried that by using a modified perl_construct with the MULTIPLICITY
: lines enabled, but that did not fix the problem (which was that @DB:args
: does work in the first 'run' of perl, but is undefined in every following
: loop).
:
: The code in PP(pp_caller) gets executed, dbargs is defined etc. There
: seems to be a problem with cx->blk_sub.argarray, which is 'empty'.

There's probably something else that needs to get re-inited that isn't.
I don't have time to chase it down myself at the moment, alas. Would
you like an honorary doctorate from Perl University for figuring it out? :-)

Larry

Larry Wall wrote:
> : Just tried that by using a modified perl_construct with the MULTIPLICITY
> : lines enabled, but that did not fix the problem (which was that @DB:args
> : does work in the first 'run' of perl, but is undefined in every following
> : loop).
> :
> : The code in PP(pp_caller) gets executed, dbargs is defined etc. There
> : seems to be a problem with cx->blk_sub.argarray, which is 'empty'.
>
> There's probably something else that needs to get re-inited that isn't.
> I don't have time to chase it down myself at the moment, alas. Would
> you like an honorary doctorate from Perl University for figuring it out?
> :-)

I was just about to answer

"I'd love to, and also to make MULTIPLICITY working (probably with my
lock_focus(sv_interp) idea to not have the 5-10% decrease in
performance), but I havn't the time"

when I realized that the solution was staring me in the face all the
time: dbargs does not get initialized...

I promise I'll learn how to use diff soon, but for now:

in void perl_construct(PerlInterpreter * sv_interp)

curcop = &compiling;
+ dbargs = 0;
dlmax = 128;

So, what about the honorary doctorate from Perl University? ;-)

---
Gerd Knops ------------------------------------------ gerti@BITart.com

In <9512191857.AA08706@scalpel>
On Tue, 19 Dec 95 10:57:29 -0800
Larry Wall <lwall@scalpel.netlabs.com> writes:
>: On most modern RISC processors it is entirely possible that referencing
>: a struct field will be faster than referencing a global variable (assuming
>: the struct pointer manages to get in a register - if it is a global variable
>: then it probably won't be faster :-).
>
>Um, do you consider a Sparc 2 to be a "modern RISC processor"? That's where
>my 5-10% slower figure comes from.
>
A Sparc2 is a little archaic. What is very important is which compiler,
and which optimizations are enabled. 5-10% with /bin/cc is one thing,
5-10% with gcc-2.5+ or recent Sun ANSI compiler at -O2 or above
another. Global variables (particularly if -pic is needed) should be
quite expensive even on a SPARC2.

(Whether variables hit cache(s) can completely swamp all above...)