Using unreferenced labels

[pgodfrin]

Greetings,
I've been told in the past to not use labels (MAIN like this:

#!/usr/bin/perl
use strict;
use warnings;
use lib '/home/modules';
use Pgt;

MAIN:
# $ENV{TESTCD}=1;
run_code();
exit;

and I foolishly ignored that advice. Mainly 'cause the advice was not
explained and I never had any problems with using a label like this.
Now I've come across a goofy little error. When run_code() croaks, it
returns the line of the MAIN label:

Test Code not set
Use %ENV in your code at rjt line 7

The module Pgt is:

package Pgt;
use strict;
use warnings;
use Carp;
our ($VERSION, @ISA, @EXPORT, @EXPORT_OK);
require Exporter;
@ISA = qw(Exporter);
@EXPORT = qw(run_code);

$VERSION="1.0" ;

sub run_code()
{
unless(exists $ENV{'TESTCD'})
{croak "Test Code not set\nUse %ENV in your code"}
print $ENV{'TESTCD'};
} # end run_code

If I comment out the MAIN lable, then croak correctly returns the line
number of failed run_code() call. Can anyone explain why?
pg

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
pgodfrin

MAIN:
# $ENV{TESTCD}=1;
run_code();

If I comment out the MAIN lable, then croak correctly returns the line
number of failed run_code() call. Can anyone explain why?

#!/usr/bin/perl -w
What # or which?
line
number
should
in
your
opinion
be
returned
for
this
Perl
statement
at
run
time ? :;
__END__

You have a multi-line statement. Enough said...

Hope this helps,
Ilya

 

[pgodfrin]

[A complimentary Cc of this posting was sent to
pgodfrin

MAIN:
#   $ENV{TESTCD}=1;
    run_code();
If I comment out the MAIN lable, then croak correctly returns the line
number of failed run_code() call. Can anyone explain why?

#!/usr/bin/perl -w
What # or which?
  line
    number
      should
        in
          your
            opinion
              be
                returned
                  for
                    this
                      Perl
                        statement
                          at
                            run
                              time ? :;
__END__

You have a multi-line statement.  Enough said...

Hope this helps,
Ilya

duh...

 

[Tad J McClellan]

#!/usr/bin/perl -w
What # or which?
line
number
should
in
your
opinion
be
returned
for
this
Perl
statement
at
run
time ? :;
__END__

9.5

(ie. the median line number of the statement)

 

[Jürgen Exner]

9.5

(ie. the median line number of the statement)

I don't see a line 9.5 or did you mean average?

Which reminds me of yea ol' city sign:

Red Neck Hollows
Founded 1896
Elevation 2400
Population 530
Average 1607

jue

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Ilya Zakharevich

#!/usr/bin/perl -w
What # or which?
line
number
should
in
your
opinion
be
returned
for
this
Perl
statement
at
run
time ? 0 : 0; # Slightly edited
__END__

You have a multi-line statement. Enough said...

Thinking of it more: the current implementation:

Perl interpreter time to time talks to itself like:
"Now I'm executing line 17".
It memorizes the number, and uses it in reports and backtracking.

For multi-line statements, having finer granularity than
one-speach-per-statement is going to be a slowdown.

On the other hand, if you tried to compile the (slightly edited) code
above, you would see that at compile time, Perl gives much higher
granularity: it pinpoints the contributing line almost exactly. Which
leads to the following, alternative, algorithm:

Store the line number of "the function call" (line with the name of
the function, or with "->" of an indirect call?) in the compile
tree's node for the function call. Use THIS line number when
backtracking at runtime (as opposed to the line number of the last
talking-to-itself).

Hint hint,
Ilya

 

[Peter J. Holzer]

Thinking of it more: the current implementation:

Perl interpreter time to time talks to itself like:
"Now I'm executing line 17".
It memorizes the number, and uses it in reports and backtracking.

For multi-line statements, having finer granularity than
one-speach-per-statement is going to be a slowdown.

On the other hand, if you tried to compile the (slightly edited) code
above, you would see that at compile time, Perl gives much higher
granularity: it pinpoints the contributing line almost exactly. Which
leads to the following, alternative, algorithm:

Store the line number of "the function call" (line with the name of
the function, or with "->" of an indirect call?) in the compile
tree's node for the function call. Use THIS line number when
backtracking at runtime (as opposed to the line number of the last
talking-to-itself).

Hint hint,

Reini Urban talked about some work he's doing on the B modules at the
Twin-City Perl workshop last weekend. If I understood him correctly he's
thinking about changing this: Instead of having special "I'm here"
opcodes he would add a location field to each opcode.

hp

 

[Peter J. Holzer]

I don't see a line 9.5 or did you mean average?

The median is defined as a number for which the number of larger and
smaller elements are equal. For an odd number of elements, this is the
middle element. For an even number, it can be any number between the two
middle elements, but by convention, the average of the two middle
elements is used. So for the sequence 2 .. 17, the median is 9.5. (In
this case it is also the average, but in general the average and median
are not the same, for example, the average of (1, 2, 4, 8, 16, 32) is
10.5 but the median is 6 (or any real number > 4 and < 8))

hp

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Peter J. Holzer

Reini Urban talked about some work he's doing on the B modules at the
Twin-City Perl workshop last weekend. If I understood him correctly he's
thinking about changing this: Instead of having special "I'm here"
opcodes he would add a location field to each opcode.

IMO, this is very horrible. One should DECREASE size of compile tree,
not increase it... (The change I advise above is ONLY for a
particular node in the tree, which is not going to blow the memory
footprint much, thus won't change memory locality properties much...)

Hope this helps,
Ilya

 

[Peter J. Holzer]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Peter J. Holzer

Reini Urban talked about some work he's doing on the B modules at the
Twin-City Perl workshop last weekend. If I understood him correctly he's
thinking about changing this: Instead of having special "I'm here"
opcodes he would add a location field to each opcode.

IMO, this is very horrible. One should DECREASE size of compile tree,
not increase it...

I guess he figures that he wins more performance by reducing the number
of nodes (less memory accesses, less work in the interpreter) than he
loses by increasing the size of a single node (more cache misses).

Only benchmarks (with real workloads, on all relevant architectures)
will show if he's right.

His real focus is on compiling to native code, though, and if he
succeeds, the optree is only an intermediate step which is
irrelevant for performance (except for very short-lived scripts).

(The change I advise above is ONLY for a
particular node in the tree, which is not going to blow the memory
footprint much, thus won't change memory locality properties much...)

I haven't looked at the real in-memory format of the optree, but my gut
feeling is that working through a tree (instead of a stream) is pretty
horrible for locality. Maybe a significant performance boost could be
achieved by flattening the tree?

hp

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Peter J. Holzer

I haven't looked at the real in-memory format of the optree, but my gut
feeling is that working through a tree (instead of a stream) is pretty
horrible for locality. Maybe a significant performance boost could be
achieved by flattening the tree?

It is flattened as the last step of compilation-per-se. (Then it is
optimized - although with *very* primitive steps only.)

I think I wrote something about this... perlguts/"Compliled code"

Yours,
Ilya

 

[David Combs]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Peter J. Holzer

I haven't looked at the real in-memory format of the optree, but my gut
feeling is that working through a tree (instead of a stream) is pretty
horrible for locality. Maybe a significant performance boost could be
achieved by flattening the tree?

It is flattened as the last step of compilation-per-se. (Then it is
optimized - although with *very* primitive steps only.)

I think I wrote something about this... perlguts/"Compliled code"

Yours,
Ilya

Ilya,

Could you flesh out a bit what we might google(groups) for
to find that discussion?

THANKS MUCH!

David

 

[Ilya Zakharevich]

[A complimentary Cc of this posting was sent to
David Combs

Could you flesh out a bit what we might google(groups) for
to find that discussion?

Sorry, David, it looks like you trimmed too much, so I do not know
which "discussion" you mean...

What I meant was (after fixing misprints) that you can do

perldoc perlguts

and look for the section on "Compiled code".

Yours,
Ilya

 

[David Combs]

[A complimentary Cc of this posting was sent to
David Combs

Could you flesh out a bit what we might google(groups) for
to find that discussion?

Sorry, David, it looks like you trimmed too much, so I do not know
which "discussion" you mean...

What I meant was (after fixing misprints) that you can do

perldoc perlguts

and look for the section on "Compiled code".

Yours,
Ilya

Belatedly, Thanks!

David