Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > How to disregard the first match of a loop?

Reply
Thread Tools

How to disregard the first match of a loop?

 
 
Uri Guttman
Guest
Posts: n/a
 
      08-10-2011
>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

RW> "Uri Guttman" <(E-Mail Removed)> 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 -------
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      08-10-2011
"Uri Guttman" <(E-Mail Removed)> writes:
>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

>
> RW> "Uri Guttman" <(E-Mail Removed)> 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.

 
Reply With Quote
 
 
 
 
Charlton Wilbur
Guest
Posts: n/a
 
      08-10-2011
>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> 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
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      08-10-2011
>>>>> "CW" == Charlton Wilbur <(E-Mail Removed)> writes:

>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> 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 -------
 
Reply With Quote
 
Ted Zlatanov
Guest
Posts: n/a
 
      08-11-2011
On Wed, 10 Aug 2011 14:04:11 +0100 Rainer Weikusat <(E-Mail Removed)> wrote:

RW> Ilya Zakharevich <(E-Mail Removed)> writes:
>> 09-08-2011, Nene <(E-Mail Removed)> пишет:
>>> 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
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      08-11-2011
"Uri Guttman" <(E-Mail Removed)> writes:
>>>>>> "CW" == Charlton Wilbur <(E-Mail Removed)> writes:

>
>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> 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" ...
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      08-11-2011
Charlton Wilbur <(E-Mail Removed)> writes:
>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> 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.
 
Reply With Quote
 
Uri Guttman
Guest
Posts: n/a
 
      08-11-2011
>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

RW> "Uri Guttman" <(E-Mail Removed)> writes:
>>>>>>> "CW" == Charlton Wilbur <(E-Mail Removed)> writes:

>>
>>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> 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 -------
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      08-11-2011
"Uri Guttman" <(E-Mail Removed)> writes:
>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> writes:

>
> RW> "Uri Guttman" <(E-Mail Removed)> writes:
> >>>>>>> "CW" == Charlton Wilbur <(E-Mail Removed)> writes:
> >>
> >>>>>>> "RW" == Rainer Weikusat <(E-Mail Removed)> 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.
 
Reply With Quote
 
Ted Zlatanov
Guest
Posts: n/a
 
      08-12-2011
On Fri, 12 Aug 2011 00:05:44 +0100 Rainer Weikusat <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
Why printing disregard <table width="100%">? Steve Richter ASP .Net 1 05-05-2005 03:48 PM
test please disregard (explanation below if you wish) D R E Java 0 07-13-2004 04:07 AM
Meaning Of Life Replacement - Universal Says Disregard MetzLan DVD Video 2 11-29-2003 11:27 PM
ubr924 - disregard cable enlaces VOIP 1 07-12-2003 06:04 PM



Advertisments