«

>>>>> "RW" == Rainer Weikusat <> writes:

RW> "Uri Guttman" <> writes:

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

>> again you are very wrong. any variable could be tied and therefore
>> have dynamic behavior that no compiler could predict.

RW> You are completely ignoring both the purpose of the example 'code
RW> idiom' ("disregard the first match of a loop") and the 'idiom' code
RW> which was actually posted (that declared $first_seen via my
RW> immediately in front of the code block). After having thus changed the
RW> topic of the thread completely, you 'conclude' that my statement
RW> would be 'again very wrong'.

you said an optimizing compiler would remove this. perl can't have
one. so what is your point of even bringing it up? that is your flaw
here.

again, you are not making any friends here. do you like doing this? why
are you even here if you don't care to be part of a community? do you
even get what community is?

uri

--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------

"Uri Guttman" <> writes:
>>>>>> "RW" == Rainer Weikusat <> writes:
>
> RW> "Uri Guttman" <> writes:
>
> RW> An optimizing compiler would/ should kill this in the course of
> RW> 'invariant code motion'.
>
> >> again you are very wrong. any variable could be tied and therefore
> >> have dynamic behavior that no compiler could predict.
>
> RW> You are completely ignoring both the purpose of the example 'code
> RW> idiom' ("disregard the first match of a loop") and the 'idiom' code
> RW> which was actually posted (that declared $first_seen via my
> RW> immediately in front of the code block). After having thus changed the
> RW> topic of the thread completely, you 'conclude' that my statement
> RW> would be 'again very wrong'.
>
> you said an optimizing compiler would remove this.

Killing the context you have chosen to disregard in order to change
the meaning of my statement such that it doesn't make sense anymore
doesn't improve anything here: I wrote that a compiler which could do
invariant code motion would/ should move a part of the specific
statement in question, next unless $first_seen++, out of the loop
because, taking the purpose ('disregard the first match of a loop')
and context ('my $first_seen; while (... ) { next unless ...; }') of
it into account, doing so wouldn't change 'the meaning of the code',
only improve its execution speed. I also wrote that the lexical
variable and the per-iteration increment could very likely also be
killed because - again recurring to the purpose of the construction -
neither the variable nor its final value would likely be used by other
code executing after the loop.

> perl can't have one.

I didn't claim that it could.

[...]

> again, you are not making any friends here. do you like doing this?
> why are you even here if you don't care to be part of a community?
> do you even get what community is?

I get that - to you - 'community' is what I shouldn't be allowed to
be part of.

>>>>> "RW" == Rainer Weikusat <> writes:

RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,

No, actually, you wrote this:

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

Perhaps in your idiolect "move" and "kill" are synonymous.

Charlton




--
Charlton Wilbur

>>>>> "CW" == Charlton Wilbur <> writes:

>>>>> "RW" == Rainer Weikusat <> writes:
RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,

CW> No, actually, you wrote this:

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.

CW> Perhaps in your idiolect "move" and "kill" are synonymous.

and regardless of move or kill, you can never do that with perl due to
possible dynamic behavior due to tie and overload and overriding of
builtins. no compiler can detect those before they happen.

but our dear rainer will win out in his mind as he always does. must be
nice to live in a castle in the clouds.

uri

--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------

On Wed, 10 Aug 2011 14:04:11 +0100 Rainer Weikusat <> wrote:

RW> Ilya Zakharevich <nospam-> writes:
>> 09-08-2011, Nene <> ÐÉÛÅÔ:
>>> Hi,
>>> I want to disregard the first match of the 'm/State : (\S+)/'
>>
>> I use the following "idiom":
>>
>> my $first_seen;
>> LOOP: (...) {
>> next unless $first_seen++;
>> DO_SOMETHING:
>> }

RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'. This is (AFAIK) something the Perl compiler
RW> cannot do and therefore, the programmer should try to keep 'one-off'
RW> statements of this type out of loops manually.

$var++ is effectively a free operation in Perl, unless you're in a tight
loop, and even then it's very unlikely to matter.

The DO_SOMETHING and loop condition are likely to be much, much heavier
in terms of workload. For instance the m/State.../ call that's done on
every loop cycle will tie up the processor much more. So I would
optimize that piece first if optimization was warranted at all.

Ted

"Uri Guttman" <> writes:
>>>>>> "CW" == Charlton Wilbur <> writes:
>
>>>>>> "RW" == Rainer Weikusat <> writes:
> RW> I wrote that a compiler which could do invariant code motion
> RW> would/ should move a part of the specific statement in question,
>
> CW> No, actually, you wrote this:
>
> RW> An optimizing compiler would/ should kill this in the course of
> RW> 'invariant code motion'.
>
> CW> Perhaps in your idiolect "move" and "kill" are synonymous.
>
> and regardless of move or kill, you can never do that with perl due to
> possible dynamic behavior due to tie and overload and overriding of
> builtins.

Neither 'tie' nor 'overload' nor 'overriding of builtins' were
applicable to this specific example.

> but our dear rainer will win out in his mind as he always does.

To quote Snoopy: "Poor, sweet baby" ...

Charlton Wilbur <> writes:
>>>>>> "RW" == Rainer Weikusat <> writes:
>
> RW> I wrote that a compiler which could do invariant code motion
> RW> would/ should move a part of the specific statement in question,
>
> No, actually, you wrote this:
>
> RW> An optimizing compiler would/ should kill this in the course of
> RW> 'invariant code motion'.
>
> Perhaps in your idiolect "move" and "kill" are synonymous.

No, actually, I didn't put RW> in front of it.

>>>>> "RW" == Rainer Weikusat <> writes:

RW> "Uri Guttman" <> writes:
>>>>>>> "CW" == Charlton Wilbur <> writes:
>>
>>>>>>> "RW" == Rainer Weikusat <> writes:
RW> I wrote that a compiler which could do invariant code motion
RW> would/ should move a part of the specific statement in question,
>>
CW> No, actually, you wrote this:
>>
RW> An optimizing compiler would/ should kill this in the course of
RW> 'invariant code motion'.
>>
CW> Perhaps in your idiolect "move" and "kill" are synonymous.
>>
>> and regardless of move or kill, you can never do that with perl due to
>> possible dynamic behavior due to tie and overload and overriding of
>> builtins.

RW> Neither 'tie' nor 'overload' nor 'overriding of builtins' were
RW> applicable to this specific example.

and how do you know that? or how would an optimizing compiler know
that? your predictions of what code will do is amazing.

>> but our dear rainer will win out in his mind as he always does.

RW> To quote Snoopy: "Poor, sweet baby" ...

just as i PREDICTED. never listen, never will. are you ever wrong on
anything? a rhetorical question, that.

uri

--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------

"Uri Guttman" <> writes:
>>>>>> "RW" == Rainer Weikusat <> writes:
>
> RW> "Uri Guttman" <> writes:
> >>>>>>> "CW" == Charlton Wilbur <> writes:
> >>
> >>>>>>> "RW" == Rainer Weikusat <> writes:
> RW> I wrote that a compiler which could do invariant code motion
> RW> would/ should move a part of the specific statement in question,
> >>
> CW> No, actually, you wrote this:
> >>
> RW> An optimizing compiler would/ should kill this in the course of
> RW> 'invariant code motion'.
> >>
> CW> Perhaps in your idiolect "move" and "kill" are synonymous.
> >>
> >> and regardless of move or kill, you can never do that with perl due to
> >> possible dynamic behavior due to tie and overload and overriding of
> >> builtins.
>
> RW> Neither 'tie' nor 'overload' nor 'overriding of builtins' were
> RW> applicable to this specific example.
>
> and how do you know that?

"Re: How to disregard the first match of a loop?"?

> or how would an optimizing compiler know
> that? your predictions of what code will do is amazing.
>
> >> but our dear rainer will win out in his mind as he always does.
>
> RW> To quote Snoopy: "Poor, sweet baby" ...
>
> just as i PREDICTED. never listen, never will. are you ever wrong on
> anything? a rhetorical question, that.

As I already wrote in the indirect reply to 'Ted 0.5" (safely resting
in my killfile until he either posts something sensible or kingdom
come, me expecting rather the latter than the former), I'm am not a bad
caricature of you. Consequently, I admit when I'm wrong.

On Fri, 12 Aug 2011 00:05:44 +0100 Rainer Weikusat <> wrote:

RW> As I already wrote in the indirect reply to 'Ted 0.5" (safely resting
RW> in my killfile until he either posts something sensible or kingdom
RW> come, me expecting rather the latter than the former), I'm am not a bad
RW> caricature of you. Consequently, I admit when I'm wrong.

Heh heh, I'm honored to be killfiled parenthetically.

Ted