[REPORT] Code Generator; also Versioned Performance Metrics #1611

p5pRT · 2000-03-29T18:33:51Z

Migrated from rt.perl.org#2848 (status was 'resolved')

Searchable as RT2848$

p5pRT · 2000-03-29T18:33:51Z

From [email protected]

SUMMARY: Why can't you take perlcc and a dynamically linked libperl.so
to generate very small a.outs from little perl scripts anymore?

Once upon a time, one could build a /usr/bin/perl that linked against
a libperl.so to make a dramatically tinier executable: in fact, it
was only 11k. Today, this is up to 34k, which is no big deal,
unless you count it as a 200% increase. :-)

In the table below, I show the results of running

perl -e 'system "ps l$$"'

through various versions of Perl, and recording the reported virtual
(VSZ) and resident (RSS) sizes. Following that is the size of the
executable file itself (FILE), as well as the text, data, and bss
results from the size(1) command. All figures are in rounded
kilobytes:

PERL VSZ RSS FILE TEXT DATA BSS
-------------------------------------------------
1 168 408 152 92 36 12
4.036 332 504 310 244 36 8
5.003 492 652 471 384 36 0
5.00502 552 692 532 452 32 1
5.00503 584 692 516 484 32 1
5.00554 616 700 599 516 32 1

5.6.0 736 776 727 628 32 2
5.6.0s 1244 912 989 856 44 105
5.6.0d 88 868 34 12 4 0
5.6.0t 792 956 773 676 32 1

The last set are all the current release. The one marked "t" was
built with pthreads, the one marked "d" is one dynamically linked
against the libperl.so instead of against libperl.a, and the one
marked "s" was statically linked against both libc.a and libperl.a.
One is curious about where the sudden jump in size occurred. Right
now, it's getting so Perl can barely sneeze without having to cough
up going on a megabyte.

Here are the results of my codegen adventures. All are running a
script that does nothing more than what you saw above, save placed
in a file. "ps.plx" is the perl source code. "pbc" is perl bytecode
version, "pc1" is the -MO=C version, and "pc2" the -MO=CC version.

SCRIPT VSZ RSS FILE TEXT DATA BSS
-------------------------------------------------
ps.plx 748 784 0 --- --- ---

ps.pbc 992 1220 158 --- --- ---
ps.pc1 1076 1084 972 756 148 0
ps.pc2 1156 1040 1045 880 96 2

psd.pbc 344 1340 158 --- --- ---
psd.pc1 428 1188 275 140 116 0
psd.pc2 504 1132 349 264 64 2

"psd" is used when built with a specially constructed perlcc that
knows about libperl.so. The disk space taken up by those linked
dynamically did drop-- by about 700k--but I'd really like to konw
what the other 275-350k of it is doing there. I used to get this
down to 20-30k, and now it's huge. I further note that those
versions are much worse in their memory consumption than the original,
to the tune of 140%-170%.

Trying to compile these things is an incredible strain
on your C compiler.

C CODE LINES WORDS BYTES
--------------------------------------
ps.pc1 src 12371 66686 633828
ps.pc2 src 14093 51746 493606
ps.pc2 src+cpp 35213 125892 912568

Yes, that's right: the one liner turns into 35,000 lines of code
and 900k to shove through your C compiler.

OOFDAH!

For those interested in timings, I ran some with two programs.

1. MEGALOOP
for ($i = 1; $i < 1000000; $i++) { }
2. TERMCAP
open(TC, "< /etc/termcap");
while (<TC>) {
split(/:/, $_);
for ($i = 0; $i <= $#_; $i++) { $seen{ $_[$i] }++; }
}

And produced these timings. Our loop got better, but our simple
parsing seems to have gotten worse. The "i" version means it was
with "use integer" on the MEGALOOP test. The others are as before.

PERL MEGALOOP TERMCAP
----------------------------------
perl1 3.018 0.690
perl4.036 2.737 0.681
perl5.003 1.046 0.882
perl5.00502 1.240 0.800
perl5.00503 1.306 0.863
perl5.00554 1.281 0.772

perl5.6.0 1.280 0.840
perl5.6.0i 1.437 0.871
perl5.6.0t 1.483 1.532
perl5.6.0d 1.864 1.159
perl5.6i+MO=C 1.467 0.849
perl5.6i+MO=CC 0.785 0.803
perl5.6i+MO=B 1.474 *COREDUMP*

The first MO=B produced one "Attempt to free unreferenced scalar",
and the coredump backtrace from the second one looks like this:

Attempt to free unreferenced scalar, <TC> line 14703.
Attempt to free unreferenced scalar, <TC> line 14703.
Segmentation fault
[BACK TRACE FOLLOWS]
#0 0x50482 in Perl_sv_free ()
#1 0x238a1 in S_cop_free ()
#2 0x236d9 in Perl_op_free ()
#3 0x236a8 in Perl_op_free ()
#4 0x236a8 in Perl_op_free ()
#5 0x236a8 in Perl_op_free ()
#6 0x236a8 in Perl_op_free ()
#7 0x236a8 in Perl_op_free ()
#8 0x236a8 in Perl_op_free ()
#9 0x236a8 in Perl_op_free ()
#10 0x236a8 in Perl_op_free ()
#11 0x236a8 in Perl_op_free ()
#12 0x236a8 in Perl_op_free ()
#13 0x29c3 in perl_destruct ()
#14 0x1823 in main ()

Conclusions about all this I leave to the readership.

--tom

p5pRT · 2006-09-11T20:57:58Z

@smpeters - Status changed from 'open' to 'stalled'

p5pRT · 2012-10-07T15:26:37Z

From @jkeenan

On Wed Mar 29 10:33:51 2000, tchrist@chthon.perl.com wrote:

SUMMARY: Why can't you take perlcc and a dynamically linked libperl.so
to generate very small a.outs from little perl scripts anymore?

Once upon a time, one could build a /usr/bin/perl that linked against
a libperl.so to make a dramatically tinier executable: in fact, it
was only 11k. Today, this is up to 34k, which is no big deal,
unless you count it as a 200% increase. :-)

In the table below, I show the results of running
perl \-e 'system "ps l$$"'
through various versions of Perl, and recording the reported virtual
(VSZ) and resident (RSS) sizes. Following that is the size of the
executable file itself (FILE), as well as the text, data, and bss
results from the size(1) command. All figures are in rounded
kilobytes:
PERL        VSZ   RSS   FILE  TEXT    DATA   BSS
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
1           168   408   152     92     36     12
4\.036       332   504   310    244     36      8
5\.003       492   652   471    384     36      0
5\.00502     552   692   532    452     32      1
5\.00503     584   692   516    484     32      1
5\.00554     616   700   599    516     32      1

5\.6\.0       736   776   727    628     32      2
5\.6\.0s     1244   912   989    856     44    105
5\.6\.0d       88   868    34     12      4      0
5\.6\.0t      792   956   773    676     32      1
The last set are all the current release. The one marked "t" was
built with pthreads, the one marked "d" is one dynamically linked
against the libperl.so instead of against libperl.a, and the one
marked "s" was statically linked against both libc.a and libperl.a.
One is curious about where the sudden jump in size occurred. Right
now, it's getting so Perl can barely sneeze without having to cough
up going on a megabyte.

Here are the results of my codegen adventures. All are running a
script that does nothing more than what you saw above, save placed
in a file. "ps.plx" is the perl source code. "pbc" is perl bytecode
version, "pc1" is the -MO=C version, and "pc2" the -MO=CC version.
SCRIPT      VSZ   RSS   FILE  TEXT    DATA   BSS
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
ps\.plx      748   784     0    \-\-\-    \-\-\-    \-\-\-

ps\.pbc      992  1220   158    \-\-\-    \-\-\-    \-\-\-
ps\.pc1     1076  1084   972    756    148      0
ps\.pc2     1156  1040  1045    880     96      2

psd\.pbc     344  1340   158    \-\-\-    \-\-\-    \-\-\-
psd\.pc1     428  1188   275    140    116      0
psd\.pc2     504  1132   349    264     64      2
"psd" is used when built with a specially constructed perlcc that
knows about libperl.so. The disk space taken up by those linked
dynamically did drop-- by about 700k--but I'd really like to konw
what the other 275-350k of it is doing there. I used to get this
down to 20-30k, and now it's huge. I further note that those
versions are much worse in their memory consumption than the original,
to the tune of 140%-170%.

Trying to compile these things is an incredible strain
on your C compiler.
C CODE          LINES   WORDS   BYTES
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
ps\.pc1 src      12371   66686  633828 
ps\.pc2 src      14093   51746  493606 
ps\.pc2 src\+cpp  35213  125892  912568 
Yes, that's right: the one liner turns into 35,000 lines of code
and 900k to shove through your C compiler.

OOFDAH!

For those interested in timings, I ran some with two programs.
1\.  MEGALOOP
    for $$i = 1; $i \< 1000000; $i\+\+$ \{ \}
2\.  TERMCAP
    open$TC\, "\< /etc/termcap"$;
    while $\<TC>$ \{
    split$/&#8203;:/\, $\_$;
    for $$i = 0; $i \<= $\#\_; $i\+\+$ \{ $seen\{ $\_\[$i\] \}\+\+; \}
    \} 
And produced these timings. Our loop got better, but our simple
parsing seems to have gotten worse. The "i" version means it was
with "use integer" on the MEGALOOP test. The others are as before.
PERL           MEGALOOP    TERMCAP 
\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-\-
perl1           3\.018       0\.690
perl4\.036       2\.737       0\.681
perl5\.003       1\.046       0\.882
perl5\.00502     1\.240       0\.800
perl5\.00503     1\.306       0\.863
perl5\.00554     1\.281       0\.772

perl5\.6\.0       1\.280       0\.840
perl5\.6\.0i      1\.437       0\.871
perl5\.6\.0t      1\.483       1\.532
perl5\.6\.0d      1\.864       1\.159
perl5\.6i\+MO=C   1\.467       0\.849 
perl5\.6i\+MO=CC  0\.785       0\.803
perl5\.6i\+MO=B   1\.474     \*COREDUMP\*
The first MO=B produced one "Attempt to free unreferenced scalar",
and the coredump backtrace from the second one looks like this:
Attempt to free unreferenced scalar\, \<TC> line 14703\.
Attempt to free unreferenced scalar\, \<TC> line 14703\.
Segmentation fault
[BACK TRACE FOLLOWS]
#0 0x50482 in Perl_sv_free ()
#1 0x238a1 in S_cop_free ()
#2 0x236d9 in Perl_op_free ()
#3 0x236a8 in Perl_op_free ()
#4 0x236a8 in Perl_op_free ()
#5 0x236a8 in Perl_op_free ()
#6 0x236a8 in Perl_op_free ()
#7 0x236a8 in Perl_op_free ()
#8 0x236a8 in Perl_op_free ()
#9 0x236a8 in Perl_op_free ()
#10 0x236a8 in Perl_op_free ()
#11 0x236a8 in Perl_op_free ()
#12 0x236a8 in Perl_op_free ()
#13 0x29c3 in perl_destruct ()
#14 0x1823 in main ()

Conclusions about all this I leave to the readership.

--tom

This ticket was filed twelve years ago and has been in the Stalled queue
for six years.

Is there any problem that needs fixing here? If not, I recommend we
close the ticket. I will do so within seven days unless there is
serious objection.

Thank you very much.
Jim Keenan

p5pRT · 2012-10-07T15:26:38Z

The RT System itself - Status changed from 'stalled' to 'open'

p5pRT · 2012-10-07T20:29:38Z

From [email protected]

"James E Keenan via RT" <perlbug-followup@perl.org> wrote
on Sun, 07 Oct 2012 08:26:38 PDT:

This ticket was filed twelve years ago and has been in the Stalled queue
for six years.

Is there any problem that needs fixing here? If not, I recommend we
close the ticket. I will do so within seven days unless there is
serious objection.

That's fine. I no longer possess any of the brain cells I had
twelve years ago.

--tom

p5pRT · 2012-10-07T21:34:22Z

From @jkeenan

On Sun Oct 07 13:29:38 2012, tom christiansen wrote:

"James E Keenan via RT" <perlbug-followup@perl.org> wrote
on Sun, 07 Oct 2012 08:26:38 PDT:

This ticket was filed twelve years ago and has been in the Stalled queue
for six years.

Is there any problem that needs fixing here? If not, I recommend we
close the ticket. I will do so within seven days unless there is
serious objection.

That's fine. I no longer possess any of the brain cells I had
twelve years ago.

--tom

Thanks for the response; closing ticket.

p5pRT · 2012-10-07T21:34:23Z

@jkeenan - Status changed from 'open' to 'resolved'

p5pRT · 2012-10-10T00:34:10Z

From @rurban

On Sun, Oct 7, 2012 at 4:34 PM, James E Keenan via RT
<perlbug-followup@perl.org> wrote:

On Sun Oct 07 13:29:38 2012, tom christiansen wrote:

"James E Keenan via RT" <perlbug-followup@perl.org> wrote
on Sun, 07 Oct 2012 08:26:38 PDT:

This ticket was filed twelve years ago and has been in the Stalled queue
for six years.

Is there any problem that needs fixing here? If not, I recommend we
close the ticket. I will do so within seven days unless there is
serious objection.

That's fine. I no longer possess any of the brain cells I had
twelve years ago.

--tom

Thanks for the response; closing ticket.

Tom's issue was fixed in the CPAN release of B::C some years ago.

BTW: The size increase Tom saw several years ago went on and on.
But the compiler options got better, so you can tune it now.
--
Reini Urban
http://cpanel.net/ http://www.perl-compiler.org/

p5pRT · 2012-10-23T17:18:12Z

From @rurban

perlcc went to CPAN as B::C.

Regarding tchrist's bloat concerns:

He is right, but p5p basically does not care about increased non-libperl bloat.
It increased much more in the following decades. Compile-time and even more run-time.
perl non-libperl RSS is problematic when writing forking daemons in perl. In libperl.so
the RSS would be shared and no problem.

And p5p does not care about increased perlcc bloat. E.g. caused by a B change,
which imports now B.xs at begin-time, causing all B constants to be included
in all compilables. RT #81332
and also does not care about using Carp in failed Dynaloader calls,
bad utf8_heavy implementations, and warnings bloat used in basic core
modules.

I suggest to close this ticket.
New B::C and B::CC have options to skip most of the bloat:
-fno-fold and -fno-warnings and individually defer it to run-time.
E.g. -UCarp,-Uwarnings

On Oct 7, 2012, at 10:26 AM, "James E Keenan via RT" <perlbug-followup@perl.org> wrote:

On Wed Mar 29 10:33:51 2000, tchrist@chthon.perl.com wrote:

SUMMARY: Why can't you take perlcc and a dynamically linked libperl.so
to generate very small a.outs from little perl scripts anymore?

Once upon a time, one could build a /usr/bin/perl that linked against
a libperl.so to make a dramatically tinier executable: in fact, it
was only 11k. Today, this is up to 34k, which is no big deal,
unless you count it as a 200% increase. :-)

In the table below, I show the results of running

perl -e 'system "ps l$$"'

through various versions of Perl, and recording the reported virtual
(VSZ) and resident (RSS) sizes. Following that is the size of the
executable file itself (FILE), as well as the text, data, and bss
results from the size(1) command. All figures are in rounded
kilobytes:

PERL VSZ RSS FILE TEXT DATA BSS
-------------------------------------------------
1 168 408 152 92 36 12
4.036 332 504 310 244 36 8
5.003 492 652 471 384 36 0
5.00502 552 692 532 452 32 1
5.00503 584 692 516 484 32 1
5.00554 616 700 599 516 32 1

5.6.0 736 776 727 628 32 2
5.6.0s 1244 912 989 856 44 105
5.6.0d 88 868 34 12 4 0
5.6.0t 792 956 773 676 32 1

The last set are all the current release. The one marked "t" was
built with pthreads, the one marked "d" is one dynamically linked
against the libperl.so instead of against libperl.a, and the one
marked "s" was statically linked against both libc.a and libperl.a.
One is curious about where the sudden jump in size occurred. Right
now, it's getting so Perl can barely sneeze without having to cough
up going on a megabyte.

Here are the results of my codegen adventures. All are running a
script that does nothing more than what you saw above, save placed
in a file. "ps.plx" is the perl source code. "pbc" is perl bytecode
version, "pc1" is the -MO=C version, and "pc2" the -MO=CC version.

SCRIPT VSZ RSS FILE TEXT DATA BSS
-------------------------------------------------
ps.plx 748 784 0 --- --- ---

ps.pbc 992 1220 158 --- --- ---
ps.pc1 1076 1084 972 756 148 0
ps.pc2 1156 1040 1045 880 96 2

psd.pbc 344 1340 158 --- --- ---
psd.pc1 428 1188 275 140 116 0
psd.pc2 504 1132 349 264 64 2

"psd" is used when built with a specially constructed perlcc that
knows about libperl.so. The disk space taken up by those linked
dynamically did drop-- by about 700k--but I'd really like to konw
what the other 275-350k of it is doing there. I used to get this
down to 20-30k, and now it's huge. I further note that those
versions are much worse in their memory consumption than the original,
to the tune of 140%-170%.

Trying to compile these things is an incredible strain
on your C compiler.

C CODE LINES WORDS BYTES
--------------------------------------
ps.pc1 src 12371 66686 633828
ps.pc2 src 14093 51746 493606
ps.pc2 src+cpp 35213 125892 912568

Yes, that's right: the one liner turns into 35,000 lines of code
and 900k to shove through your C compiler.

OOFDAH!

For those interested in timings, I ran some with two programs.

1. MEGALOOP
for ($i = 1; $i < 1000000; $i++) { }
2. TERMCAP
open(TC, "< /etc/termcap");
while (<TC>) {
split(/:/, $_);
for ($i = 0; $i <= $#_; $i++) { $seen{ $_[$i] }++; }
}

And produced these timings. Our loop got better, but our simple
parsing seems to have gotten worse. The "i" version means it was
with "use integer" on the MEGALOOP test. The others are as before.

PERL MEGALOOP TERMCAP
----------------------------------
perl1 3.018 0.690
perl4.036 2.737 0.681
perl5.003 1.046 0.882
perl5.00502 1.240 0.800
perl5.00503 1.306 0.863
perl5.00554 1.281 0.772

perl5.6.0 1.280 0.840
perl5.6.0i 1.437 0.871
perl5.6.0t 1.483 1.532
perl5.6.0d 1.864 1.159
perl5.6i+MO=C 1.467 0.849
perl5.6i+MO=CC 0.785 0.803
perl5.6i+MO=B 1.474 *COREDUMP*

The first MO=B produced one "Attempt to free unreferenced scalar",
and the coredump backtrace from the second one looks like this:

Attempt to free unreferenced scalar, <TC> line 14703.
Attempt to free unreferenced scalar, <TC> line 14703.
Segmentation fault
[BACK TRACE FOLLOWS]
#0 0x50482 in Perl_sv_free ()
#1 0x238a1 in S_cop_free ()
#2 0x236d9 in Perl_op_free ()
#3 0x236a8 in Perl_op_free ()
#4 0x236a8 in Perl_op_free ()
#5 0x236a8 in Perl_op_free ()
#6 0x236a8 in Perl_op_free ()
#7 0x236a8 in Perl_op_free ()
#8 0x236a8 in Perl_op_free ()
#9 0x236a8 in Perl_op_free ()
#10 0x236a8 in Perl_op_free ()
#11 0x236a8 in Perl_op_free ()
#12 0x236a8 in Perl_op_free ()
#13 0x29c3 in perl_destruct ()
#14 0x1823 in main ()

Conclusions about all this I leave to the readership.

--tom

This ticket was filed twelve years ago and has been in the Stalled queue
for six years.

Is there any problem that needs fixing here? If not, I recommend we
close the ticket. I will do so within seven days unless there is
serious objection.

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: stalled
https://rt-archive.perl.org/perl5/Ticket/Display.html?id=2848

p5pRT closed this as completed Oct 7, 2012

p5pRT added Not a Bug Severity Low labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[REPORT] Code Generator; also Versioned Performance Metrics #1611

[REPORT] Code Generator; also Versioned Performance Metrics #1611

p5pRT commented Mar 29, 2000

p5pRT commented Mar 29, 2000

p5pRT commented Sep 11, 2006

p5pRT commented Oct 7, 2012

p5pRT commented Oct 7, 2012

p5pRT commented Oct 7, 2012

p5pRT commented Oct 7, 2012

p5pRT commented Oct 7, 2012

p5pRT commented Oct 10, 2012

p5pRT commented Oct 23, 2012

[REPORT] Code Generator; also Versioned Performance Metrics #1611

[REPORT] Code Generator; also Versioned Performance Metrics #1611

Comments

p5pRT commented Mar 29, 2000

p5pRT commented Mar 29, 2000

From [email protected]

p5pRT commented Sep 11, 2006

p5pRT commented Oct 7, 2012

From @jkeenan

p5pRT commented Oct 7, 2012

p5pRT commented Oct 7, 2012

From [email protected]

p5pRT commented Oct 7, 2012

From @jkeenan

p5pRT commented Oct 7, 2012

p5pRT commented Oct 10, 2012

From @rurban

p5pRT commented Oct 23, 2012

From @rurban