Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.perl.misc > #8660
| Newsgroups | comp.lang.perl.misc |
|---|---|
| Subject | Re: this should work |
| References | <krkm21$19jd$1@news.ntua.gr> <87a9ltqw5i.fsf@sapphire.mobileactivedefense.com> <5ri2ba-85p1.ln1@anubis.morrow.me.uk> <87li5dclp5.fsf@sapphire.mobileactivedefense.com> |
| From | Ben Morrow <ben@morrow.me.uk> |
| Organization | morrow.me.uk |
| Date | 2013-07-11 16:23 +0100 |
| Message-ID | <58v2ba-u112.ln1@anubis.morrow.me.uk> (permalink) |
Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> Ben Morrow <ben@morrow.me.uk> writes:
> > Quoth Rainer Weikusat <rweikusat@mssgmbh.com>:
> >> Jim Gibson <jimsgibson@gmail.com> writes:
> >>
> >> [...]
> >>
> >> > foreach my $dir (qw/commands_pre commands_post/) {
> >> > my $tmpdir = "/tmp/$dir";
> >> > print "$tmpdir\n"
> >> > }
> >>
> >> The perl compiler doesn't do invariant code motion because whether or
> >> not some code is 'invariant' cannot generally be decided at compile
> >> time.
> >
> > I don't know what you mean by that, but...
>
> In this case, this would be transforming the
>
> for (...) {
> my $tmp = 'ar!';
> }
>
> to
>
> my $tmp;
> for (...) {
> $tmp = 'ar!';
> }
>
> because the 'my $tmp' is invariant code: It's effective result never
> changes throughout the loop.
But it does: logically, you get a different variable each time. That
transformation changes the result, since the value of $tmp will persist
from one iteration to the next (as well as being visible below the
loop). Perl's runtime optimisation, which only kicks in if Perl can
prove it won't affect anything, is the only one possible.
> >> Because of this, the loop body above behave exactly as written
> >> down: For each iteration, it creates a new my variable and assigns a
> >> value to it.
> >
> > ...this is nonsense. Perl quite deliberately reuses the same variable
> > every time, to avoid the allocation overhead, unless you pass a (strong)
> > reference to it outside the loop. Try it and see:
> >
> > use Scalar::Util qw/refaddr/;
> >
> > for (1, 2, 3) {
> > my $tmp = "foo/$_";
> > say refaddr \$tmp;
> > }
>
> Maybe some versions of Perl do that (which would be an
> improvement). But the one I tested certainly doesn't.
Did you actually run that bit of code? With 'say' replaced with 'print',
it produces the same refaddr three times on every version perl I have
available (back to 5.6.0).
> Assuming the
> following code
>
> -------------
> use Benchmark;
>
> sub in_loop
> {
> for (0 .. 100) {
> my $a = $_ + 1;
> }
> }
>
> sub out_of_loop
> {
> my $a;
> for (0 .. 100) {
> $a = $_ + 1
> }
> }
>
> timethese(-2,
> {
> in_loop => \&in_loop,
> out_of_loop => \&out_of_loop
> });
> -------------
>
> the loop in in_loop is translated to (perl -MO=Concise,in_loop, perl
> 5.10.1)
>
> e <0> iter s ->f
> - <@> lineseq sK ->-
> 7 <;> nextstate(main 596 a.pl:6) v ->8
> c <2> sassign vKS/2 ->d
> a <2> add[t5] sK/2 ->b
> - <1> ex-rv2sv sK/1 ->9
> 8 <#> gvsv[*_] s ->9
> 9 <$> const[IV 1] s ->a
> b <0> padsv[$a:596,597] sRM*/LVINTRO ->c
> d <0> unstack s ->e
>
> [b] is what creates the variable.
>
> For out_of_loop, this looks like this:
>
> e <0> iter s ->f
> - <@> lineseq sK ->-
> 9 <;> nextstate(main 601 a.pl:14) v ->a
> c <2> add[$a:600,603] sK/TARGMY,2 ->d
> - <1> ex-rv2sv sK/1 ->b
> a <#> gvsv[*_] s ->b
> b <$> const[IV 1] s ->c
> d <0> unstack s ->e
>
> and the padsv ... LVINTRO happens in the subroutine preamble.
Ah yes, that's a *different* bit of cheating (on perl's part). The
'normal' way to compile C< $x = $_ + 1 > with a lexical $x would be
sassign
add[t2]
gvsv(*_)
const(IV 1)
padsv[$x]
(I've omitted the ex-rv2sv), and for the case with 'my' that is what
perl produces. It does much the same if $x is global:
sassign
add[t1]
gvsv(*_)
const(IV 1)
gvsv(*x)
regardless of whether this statement introduces $x or not, and if the
RHS is something other than a binary operator (say, a sub call):
sassign
entersub[t2]
pushmark
gv(*foo)
padsv[$x]
However, in the specific case of a builtin operator whose result is
assigned directly to an already-declared lexical, perl will optimise by
having the operator store its result directly in the lexical, rather
than using a temporary.
> Running the program here yields the expected result that out_of_loop
> executes at about 1.43 times the speed of in_loop.
Yeah, that's not surprising, given it's executing two fewer ops per
iteration; but this is because out_of_loop is exceptionally optimised,
rather than because in_loop is inherently inefficient. Run your
benchmark again with a sub call or something instead of the addition,
and I doubt you'll see any difference between the two.
The amount of extra work LVINTRO causes padsv to do is tiny. All it does
is flip a bit in the pad SV itself to mark it as being in scope, and
push a pad offset onto the save stack to cause it to be cleaned out
ready for the next iteration at the end of the scope.
Ben
Back to comp.lang.perl.misc | Previous | Next — Previous in thread | Next in thread | Find similar
this should work "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-11 01:08 +0300
Re: this should work Jim Gibson <jimsgibson@gmail.com> - 2013-07-10 15:49 -0700
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 09:42 +0300
Re: this should work tmcd@panix.com (Tim McDaniel) - 2013-07-11 08:02 +0000
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 12:45 +0100
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 15:03 +0300
Re: this should work "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2013-07-11 14:52 +0200
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 16:01 +0300
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 14:29 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 14:27 +0100
Re: this should work Peter Makholm <peter@makholm.net> - 2013-07-11 15:50 +0200
Re: this should work Jürgen Exner <jurgenex@hotmail.com> - 2013-07-11 03:34 -0700
Re: this should work George Mpouras <nospam.gravitalsun.noadsplease@hotmail.noads.com> - 2013-07-11 13:55 +0300
Re: this should work Peter Makholm <peter@makholm.net> - 2013-07-11 13:57 +0200
Re: this should work Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-11 09:10 -0400
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 21:35 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 10:32 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 12:51 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 13:42 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 16:23 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 17:17 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 18:08 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 21:48 +0100
Re: this should work Keith Keller <kkeller-usenet@wombat.san-francisco.ca.us> - 2013-07-11 10:32 -0700
Re: this should work Jürgen Exner <jurgenex@hotmail.com> - 2013-07-11 10:48 -0700
Re: this should work "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-11 21:38 +0300
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 23:08 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 18:48 +0100
Re: this should work Charles DeRykus <derykus@gmail.com> - 2013-07-11 12:03 -0700
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 22:02 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 23:06 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-12 01:04 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-15 13:41 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-15 14:07 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-15 15:05 +0100
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-15 21:02 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-15 23:58 +0100
Re: this should work tmcd@panix.com (Tim McDaniel) - 2013-07-15 17:23 +0000
Re: this should work Charlton Wilbur <cwilbur@chromatico.net> - 2013-07-15 15:40 -0400
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 21:58 +0100
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-11 23:17 +0100
[OT] scoping Ivan Shmakov <oneingray@gmail.com> - 2013-07-12 07:50 +0000
Re: [OT] scoping aka 'new holes in old shoes' Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-12 11:53 +0100
[OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-15 11:37 +0000
Re: [OT] engineering Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-16 21:49 +0100
Re: [OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-17 09:27 +0000
Re: [OT] engineering Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-17 15:53 +0100
Re: [OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-22 10:36 +0000
Re: [OT] engineering Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-23 06:43 -0400
Re: [OT] engineering Ivan Shmakov <oneingray@gmail.com> - 2013-07-22 10:38 +0000
Re: [OT] engineering Rui Maciel <rui.maciel@gmail.com> - 2013-07-26 10:09 +0100
Re: [OT] scoping "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2013-07-12 14:58 +0200
Re: [OT] scoping Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-12 15:50 +0100
Re: [OT] scoping Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-12 13:34 -0400
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-12 22:04 +0100
Re: [OT] scoping Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-13 13:13 +0100
Re: [OT] scoping John Black <jblack@nospam.com> - 2013-07-13 20:01 -0500
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-14 03:24 +0100
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-14 10:49 +0200
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-14 13:13 +0100
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-14 17:02 +0200
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-14 22:21 +0100
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-15 02:21 +0200
Re: [OT] scoping Xho Jingleheimerschmidt <xhoster@gmail.com> - 2013-07-14 17:04 -0700
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-15 14:12 +0100
Re: [OT] scoping tmcd@panix.com (Tim McDaniel) - 2013-07-14 15:11 +0000
Re: [OT] scoping "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-14 17:34 +0200
Re: [OT] scoping Xho Jingleheimerschmidt <xhoster@gmail.com> - 2013-07-14 15:34 -0700
Re: [OT] scoping Ben Morrow <ben@morrow.me.uk> - 2013-07-15 14:27 +0100
Re: [OT] scoping John Black <jblack@nospam.com> - 2013-07-14 23:48 -0500
Re: [OT] scoping Martijn Lievaart <m@rtij.nl.invlalid> - 2013-07-13 12:14 +0200
Re: this should work David Harmon <source@netcom.com> - 2013-07-11 10:02 -0700
Re: this should work Ben Morrow <ben@morrow.me.uk> - 2013-07-11 22:04 +0100
Re: this should work David Harmon <source@netcom.com> - 2013-07-12 09:34 -0700
Re: this should work Rainer Weikusat <rweikusat@mssgmbh.com> - 2013-07-12 18:16 +0100
Re: this should work "Dr.Ruud" <rvtol+usenet@xs4all.nl> - 2013-07-12 15:44 +0200
Re: this should work David Harmon <source@netcom.com> - 2013-07-12 15:53 -0700
Re: this should work Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> - 2013-07-11 09:14 -0400
Re: this should work "George Mpouras" <nospam.gravitalsun.antispam@spamno.hotmail.anispam.com.nospam> - 2013-07-11 19:45 +0300
csiph-web