[16201] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 3613 Volume: 9

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 10 20:24:32 2000

Date: Mon, 10 Jul 2000 17:24:20 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <963275059-v9-i3613@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Mon, 10 Jul 2000     Volume: 9 Number: 3613

Today's topics:
        Why $|++ instead of $|=1 ? <kj0@mailcity.com>
    Re: Why $|++ instead of $|=1 ? <bwalton@rochester.rr.com>
    Re: Why $|++ instead of $|=1 ? (Gwyn Judd)
    Re: Why $|++ instead of $|=1 ? (Abigail)
    Re: Why $|++ instead of $|=1 ? <wyzelli@yahoo.com>
    Re: Why $|++ instead of $|=1 ? (brian d foy)
    Re: Why $|++ instead of $|=1 ? (Abigail)
    Re: Why $|++ instead of $|=1 ? (Gwyn Judd)
    Re: Why $|++ instead of $|=1 ? (Gwyn Judd)
    Re: Why $|++ instead of $|=1 ? <flavell@mail.cern.ch>
    Re: Why $|++ instead of $|=1 ? <Luc-Etienne.Brachotte@wanadoo.fr>
    Re: Why $|++ instead of $|=1 ? <uri@sysarch.com>
    Re: Why $|++ instead of $|=1 ? <flavell@mail.cern.ch>
    Re: Why $|++ instead of $|=1 ? <Luc-Etienne.Brachotte@wanadoo.fr>
    Re: Why $|++ instead of $|=1 ? <uri@sysarch.com>
    Re: Why $|++ instead of $|=1 ? <Luc-Etienne.Brachotte@wanadoo.fr>
    Re: Why $|++ instead of $|=1 ? <uri@sysarch.com>
    Re: Why $|++ instead of $|=1 ? <Luc-Etienne.Brachotte@wanadoo.fr>
    Re: Why $|++ instead of $|=1 ? (Abigail)
    Re: Why $|++ instead of $|=1 ? (jason)
    Re: Why $|++ instead of $|=1 ? <iltzu@sci.invalid>
    Re: Why $|++ instead of $|=1 ? <andrew@erlenstar.demon.co.uk>
    Re: Why $|++ instead of $|=1 ? (Reini Urban)
    Re: Why $|++ instead of $|=1 ? (Marcel Grunauer)
    Re: Why $|++ instead of $|=1 ? (Abigail)
    Re: Why $|++ instead of $|=1 ? (Reini Urban)
        Digest Administrivia (Last modified: 16 Sep 99) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: 5 Jul 2000 21:07:25 -0400
From: kj0 <kj0@mailcity.com>
Subject: Why $|++ instead of $|=1 ?
Message-Id: <8k0m4d$13o$1@panix3.panix.com>







Is there any reason why $|++ would be preferable over $|=1?


------------------------------

Date: Thu, 06 Jul 2000 01:46:37 GMT
From: Bob Walton <bwalton@rochester.rr.com>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <3963E543.708E3C64@rochester.rr.com>

kj0 wrote:
> 
> Is there any reason why $|++ would be preferable over $|=1?
No.  Maybe easier to type?
-- 
Bob Walton


------------------------------

Date: Thu, 06 Jul 2000 02:08:09 GMT
From: tjla@guvfybir.qlaqaf.bet (Gwyn Judd)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8m7qfq.8d6.tjla@thislove.dyndns.org>

I was shocked! How could kj0 <kj0@mailcity.com>
say such a terrible thing:

>Is there any reason why $|++ would be preferable over $|=1?

I can think of only one. Imagine doing this:

sub some_sub {
$|++;
 ...
<code that assumes output is unbuffered>
 ...
$|--;
}

sub some_other_sub {
$|++;
 ...
<some more code assuming unbuffered output>
&some_sub;
 ...
$|--;
# call some_sub again
&some_sub;
}

Doing it this way allows them each to fiddle with $| without needing to
worry about whether the calling sub expects $| to have a certain value
or not. ie. they set $| to the value it was before it was called. If
they did "$| = 1;" and "$| = 0" they could not guarantee this.

-- 
Gwyn Judd (tjla@guvfybir.qlaqaf.bet)
My return address is rot13'ed
Success is a journey, not a destination.


------------------------------

Date: 05 Jul 2000 22:20:54 EDT
From: abigail@delanet.com (Abigail)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8m7s9q.ibb.abigail@alexandra.delanet.com>

kj0 (kj0@mailcity.com) wrote on MMDI September MCMXCIII in
<URL:news:8k0m4d$13o$1@panix3.panix.com>:
== 
== 
== Is there any reason why $|++ would be preferable over $|=1?


There isn't. In fact, $|++ is really, really bad. It's a classical
example of cargo cult programming. Someone once used it, and that got
copied all over.

The problem with $|++ is that it turns of buffering only if $| is 0.
If for some reason $| is -1 (that is, buffering is already off), you
turn buffering *ON*, getting opposite effects of what you want.

Now, you may say who would sets $| to -1? Well, if you use $|++ to disable
buffering, wouldn't it make sense to use $|-- to enable buffering again?
And if your program has $| ++, $| -- and $| ++ in that order, things go
quite out of hand if you remove the first $| ++.


If you just use $| = 1 and $| = 0, you never, ever have to chase your
program to see what $| was, nor do you have to chase your program for
subsequent modifications if you take out an assignment to $|.

Another big advantage of $| = 1; is that you can put 'local' in front
of it, where you can't with $| ++.

$| ++ is obscure and bad. $| = 1 makes it instantly clear what the
effects are.



Abigail
-- 
$_ = "\x3C\x3C\x45\x4F\x54\n" and s/<<EOT/<<EOT/ee and print;
"Just another Perl Hacker"
EOT


------------------------------

Date: Thu, 6 Jul 2000 12:01:36 +0930
From: "Wyzelli" <wyzelli@yahoo.com>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <fbS85.9$E27.2912@vic.nntp.telstra.net>

Gwyn Judd <tjla@guvfybir.qlaqaf.bet> wrote in message
news:slrn8m7qfq.8d6.tjla@thislove.dyndns.org...
> I was shocked! How could kj0 <kj0@mailcity.com>
> say such a terrible thing:
>
> >Is there any reason why $|++ would be preferable over $|=1?
>
> I can think of only one. Imagine doing this:
>

<snip>

> Doing it this way allows them each to fiddle with $| without needing
to
> worry about whether the calling sub expects $| to have a certain value
> or not. ie. they set $| to the value it was before it was called. If
> they did "$| = 1;" and "$| = 0" they could not guarantee this.
>

As I have demonstrated previously, whilst calling $|++ repeatedly leaves
the state of $| 'high' (or 'unbuffered' if you wish, since any non zero
value = unbuffered), calling $|-- repeatedly can in certain
circumstances cause $| to switch between a zero and non-zero value which
can lead to misleading results.

That is why I personally like to use $|=1 and $|=0.  No less characters
to type and the intent (particularly when setting to zero is not only
clear, but you are certain that it is zero.

Wyzelli




------------------------------

Date: Wed, 05 Jul 2000 22:36:28 -0400
From: brian@smithrenaud.com (brian d foy)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <brian-ya02408000R0507002236280001@news.panix.com>

In article <slrn8m7qfq.8d6.tjla@thislove.dyndns.org>, tjla@guvfybir.qlaqaf.bet (Gwyn Judd) posted:

> I was shocked! How could kj0 <kj0@mailcity.com>
> say such a terrible thing:
> 
> >Is there any reason why $|++ would be preferable over $|=1?
> 
> I can think of only one. Imagine doing this:
> 
> sub some_sub {
> $|++;
> ...
> <code that assumes output is unbuffered>
> ...
> $|--;
> }

you should probably use local() instead of this technique.

-- 
brian d foy                    
CGI Meta FAQ <URL:http://www.smithrenaud.com/public/CGI_MetaFAQ.html>
Perl Mongers <URL:http://www.perl.org/>


------------------------------

Date: 05 Jul 2000 22:55:24 EDT
From: abigail@delanet.com (Abigail)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8m7uag.ibb.abigail@alexandra.delanet.com>

Gwyn Judd (tjla@guvfybir.qlaqaf.bet) wrote on MMDI September MCMXCIII in
<URL:news:slrn8m7qfq.8d6.tjla@thislove.dyndns.org>:
'' I was shocked! How could kj0 <kj0@mailcity.com>
'' say such a terrible thing:
'' 
'' >Is there any reason why $|++ would be preferable over $|=1?
'' 
'' I can think of only one. Imagine doing this:
'' 
'' sub some_sub {
'' $|++;
'' ...
'' <code that assumes output is unbuffered>
'' ...
'' $|--;
'' }
'' 
'' sub some_other_sub {
'' $|++;
'' ...
'' <some more code assuming unbuffered output>
'' &some_sub;
'' ...
'' $|--;
'' # call some_sub again
'' &some_sub;
'' }
'' 
'' Doing it this way allows them each to fiddle with $| without needing to
'' worry about whether the calling sub expects $| to have a certain value
'' or not. ie. they set $| to the value it was before it was called. If
'' they did "$| = 1;" and "$| = 0" they could not guarantee this.

That's what local is for.  Your subs will fail to do the right thing
if $| happens to be -1. Or imagine that some_sub has a fatal error in
it, which is caught by an eval{}. Your entire $| ++ and $| -- will be
hosed.

And what is a sub that wants the output to *be* buffered going to do?

I'd say this is a good example showing how bad $| ++ actually is.


Abigail
-- 
BEGIN {$^H {join "" => ("a" .. "z") [8, 13, 19, 4, 6, 4, 17]} = sub
           {["", "Just ", "another ", "Perl ", "Hacker"] -> [shift]};
       $^H = hex join "" => reverse map {int ($_ / 2)} 0 .. 4}
print 1, 2, 3, 4, "\n";


------------------------------

Date: Thu, 06 Jul 2000 03:09:18 GMT
From: tjla@guvfybir.qlaqaf.bet (Gwyn Judd)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8m7u2s.9cn.tjla@thislove.dyndns.org>

I was shocked! How could Abigail <abigail@delanet.com>
say such a terrible thing:

>That's what local is for.  Your subs will fail to do the right thing
>if $| happens to be -1. Or imagine that some_sub has a fatal error in
>it, which is caught by an eval{}. Your entire $| ++ and $| -- will be
>hosed.
>
>And what is a sub that wants the output to *be* buffered going to do?
>
>I'd say this is a good example showing how bad $| ++ actually is.

Yes all very true. The user did ask for a situation in which $|++ might
be used. In fairness I should have thought of the "local" solution which
is much better.

-- 
Gwyn Judd (tjla@guvfybir.qlaqaf.bet)
My return address is rot13'ed
The San Diego Freeway.  Official Parking Lot of the 1984 Olympics!


------------------------------

Date: Thu, 06 Jul 2000 03:11:40 GMT
From: tjla@guvfybir.qlaqaf.bet (Gwyn Judd)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8m7u7a.9cn.tjla@thislove.dyndns.org>

I was shocked! How could Wyzelli <wyzelli@yahoo.com>
say such a terrible thing:
>As I have demonstrated previously, whilst calling $|++ repeatedly leaves
>the state of $| 'high' (or 'unbuffered' if you wish, since any non zero
>value = unbuffered), calling $|-- repeatedly can in certain
>circumstances cause $| to switch between a zero and non-zero value which
>can lead to misleading results.
>
>That is why I personally like to use $|=1 and $|=0.  No less characters
>to type and the intent (particularly when setting to zero is not only
>clear, but you are certain that it is zero.

Yeah fair enough criticism. As others have pointed out "local" is a
better solution to the problem which eliminates my bug and yours (yours
is that by doing "$| = 0" this always sets $| to zero which may not be
what the calling function expected).

-- 
Gwyn Judd (tjla@guvfybir.qlaqaf.bet)
My return address is rot13'ed
I am P-P-Porky P-P-Pig of B-B-Borg. You will be assim... assim... absorbed.


------------------------------

Date: Thu, 6 Jul 2000 12:20:53 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <Pine.GHP.4.21.0007061218521.27673-100000@hpplus03.cern.ch>

On Thu, 6 Jul 2000, Gwyn Judd wrote:

> Doing it this way allows them each to fiddle with $| without needing to
> worry about whether the calling sub expects $| to have a certain value
> or not. ie. they set $| to the value it was before it was called. If
> they did "$| = 1;" and "$| = 0" they could not guarantee this.

But it's the wrong solution to that problem.  What you _want_ is
localised non-buffering.  And the appropriate _solution_ is:
localising the buffering switch.  Q.E.D.



------------------------------

Date: Fri, 07 Jul 2000 23:34:28 +0200
From: Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <39664CE4.BEB612AD@wanadoo.fr>



kj0 a écrit :

> Is there any reason why $|++ would be preferable over $|=1?

Generally speaking, when you compile
$|=1
the compiler transfer the content of one memory location (which contains
1) to a second one (which is $|)

This is usally (much) slower than
$|++
that deals with only one memory location.

It depends on the CPU, but usually incrementing a memory location is
much faster than copying a location to another.

LEB




------------------------------

Date: Fri, 07 Jul 2000 22:20:07 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <x7k8expoq0.fsf@home.sysarch.com>

>>>>> "LB" == Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr> writes:

  LB> kj0 a écrit :

  >> Is there any reason why $|++ would be preferable over $|=1?

  LB> It depends on the CPU, but usually incrementing a memory location is
  LB> much faster than copying a location to another.

this is perl, not c. perl ops are not simple memory copies or increments
but dispatched sub calls in C. you can not predict the speed of perl
code just by looking at perl.

as for the actual choice above, it is more a matter of style than
anything else.

uri

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  -----------  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  ----------  http://www.northernlight.com


------------------------------

Date: Sat, 8 Jul 2000 00:17:32 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <Pine.GHP.4.21.0007080009310.11437-100000@hpplus03.cern.ch>

On Fri, 7 Jul 2000, Luc-Etienne Brachotte from the ominous wanadoo.fr
wrote:

> Generally speaking, when you compile
> $|=1
> the compiler transfer the content of one memory location (which contains
> 1) to a second one (which is $|)
> 
> This is usally (much) slower than
> $|++
> that deals with only one memory location.

Let's see your benchmarks with respect to a typical application.

> It depends on the CPU, but usually incrementing a memory location is
> much faster than copying a location to another.

I met my first computer in 1958.  How about you?

Anyway, what's the point of doing it faster _instead_ of doing it
correctly? 

-- 

        "Mir ist es ein Rätsel wie man mit minimalem Verstand so einen 
         Unfug fabrizieren kann."   - Adrian Knoth





------------------------------

Date: Sat, 08 Jul 2000 09:05:43 +0200
From: Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <3966D2C7.F5A40B6D@wanadoo.fr>



Uri Guttman a écrit :

> >>>>> "LB" == Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr> writes:
>
>   LB> kj0 a écrit :
>
>   >> Is there any reason why $|++ would be preferable over $|=1?
>
>   LB> It depends on the CPU, but usually incrementing a memory location is
>   LB> much faster than copying a location to another.
>
> this is perl, not c. perl ops are not simple memory copies or increments
> but dispatched sub calls in C. you can not predict the speed of perl
> code just by looking at perl.

I was not speaking about C but CPUs internals, on which everything is based.



------------------------------

Date: Sat, 08 Jul 2000 07:14:08 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <x7wvixnlfl.fsf@home.sysarch.com>

>>>>> "LB" == Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr> writes:

  LB> Uri Guttman a écrit :

  >> >> Is there any reason why $|++ would be preferable over $|=1?
  >> 
  LB> It depends on the CPU, but usually incrementing a memory location is
  LB> much faster than copying a location to another.
  >> 
  >> this is perl, not c. perl ops are not simple memory copies or increments
  >> but dispatched sub calls in C. you can not predict the speed of perl
  >> code just by looking at perl.

  LB> I was not speaking about C but CPUs internals, on which everything
  LB> is based.

duh! i do know a little about cpu's. but your comment is still way
off base as it doesn't matter how fast a cpu does increment
vs. assignment. the perl op code dispatch loop swamps out that minor
difference so you can't tell. many perl ops are the same speed since the
machine code to do the work is so much less than the overhead of the
dispatch loop.

please stop talking about speed in perl by commenting on machine
instructions. it is very foolish.

uri

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  -----------  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  ----------  http://www.northernlight.com


------------------------------

Date: Sat, 08 Jul 2000 09:29:31 +0200
From: Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <3966D85B.DF1404E7@wanadoo.fr>



Uri Guttman a écrit :

> >>>>> "LB" == Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr> writes:
>
>   LB> Uri Guttman a écrit :
>
>   >> >> Is there any reason why $|++ would be preferable over $|=1?
>   >>
>   LB> It depends on the CPU, but usually incrementing a memory location is
>   LB> much faster than copying a location to another.
>   >>
>   >> this is perl, not c. perl ops are not simple memory copies or increments
>   >> but dispatched sub calls in C. you can not predict the speed of perl
>   >> code just by looking at perl.
>
>   LB> I was not speaking about C but CPUs internals, on which everything
>   LB> is based.
>
> duh! i do know a little about cpu's. but your comment is still way
> off base as it doesn't matter how fast a cpu does increment
> vs. assignment. the perl op code dispatch loop swamps out that minor
> difference so you can't tell. many perl ops are the same speed since the
> machine code to do the work is so much less than the overhead of the
> dispatch loop.
>
> please stop talking about speed in perl by commenting on machine
> instructions. it is very foolish.

It is *not* foolish, it bother me (and all the clients I met) because this
intoduce the *big* question when choosing Perl from other languages on new
projects:

"Is Perl well-compiled ?"

According to CPU internals, $|++ should be faster than $|=1
If it is not in Perl, or worse the opposite, it means the answer is no.

I know a client in a big company that rejected Perl, beacause he thought it was
not well-compiled, whatever the benchmarks results were.

Moreover, if I have the choice in a program between several algorithms, and the
benchmarks show no or few differences, I prefer the one that will be potentially
faster in the future.




------------------------------

Date: Sat, 08 Jul 2000 07:52:05 GMT
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <x7sntlnjoc.fsf@home.sysarch.com>

>>>>> "LB" == Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr> writes:

  >> please stop talking about speed in perl by commenting on machine
  >> instructions. it is very foolish.

  LB> It is *not* foolish, it bother me (and all the clients I met) because this
  LB> intoduce the *big* question when choosing Perl from other languages on new
  LB> projects:

  LB> "Is Perl well-compiled ?"

it is very foolish as perl doesn't compile down to machine
instructions. perl compiles down to an internal parse tree which is then
interpreted. 

  LB> According to CPU internals, $|++ should be faster than $|=1 If it
  LB> is not in Perl, or worse the opposite, it means the answer is no.

you don't get it. perl is interpeted. do you know what that means? i
don't think so from your posts. please read up on compiled
vs. interpeted languages. and note that perl has both phases.

  LB> I know a client in a big company that rejected Perl, beacause he
  LB> thought it was not well-compiled, whatever the benchmarks results
  LB> were.

then he doesn't understand perl and that is his loss. 

  LB> Moreover, if I have the choice in a program between several
  LB> algorithms, and the benchmarks show no or few differences, I
  LB> prefer the one that will be potentially faster in the future.

you just don't get it.

i give up.

uri

-- 
Uri Guttman  ---------  uri@sysarch.com  ----------  http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page  -----------  http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net  ----------  http://www.northernlight.com


------------------------------

Date: Sat, 08 Jul 2000 10:01:29 +0200
From: Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <3966DFD9.FD8B795D@wanadoo.fr>



Uri Guttman a écrit :

> you don't get it. perl is interpeted. do you know what that means? i
> don't think so from your posts. please read up on compiled
> vs. interpeted languages. and note that perl has both phases.

I have yet *written* interpreters and compilers



------------------------------

Date: 08 Jul 2000 05:42:34 EDT
From: abigail@delanet.com (Abigail)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8mdutr.rbj.abigail@alexandra.delanet.com>

Luc-Etienne Brachotte (Luc-Etienne.Brachotte@wanadoo.fr) wrote on MMDIII
September MCMXCIII in <URL:news:3966D85B.DF1404E7@wanadoo.fr>:
:: 
:: Uri Guttman a écrit :
:: 
:: It is *not* foolish, it bother me (and all the clients I met) because this
:: intoduce the *big* question when choosing Perl from other languages on new
:: projects:
:: 
:: "Is Perl well-compiled ?"

Perl is compiled to an optimized op-tree. Does that answer the question?

:: According to CPU internals, $|++ should be faster than $|=1
:: If it is not in Perl, or worse the opposite, it means the answer is no.

Perl is not compiled to machine code. So, your reasoning is meaningless.
$|++ does *a lot* more than just incrementing a value in memory. After
all, ${chr 0x74} ++ has to increment the same value.

:: I know a client in a big company that rejected Perl, beacause he thought it w
:: not well-compiled, whatever the benchmarks results were.

Well, that is the clients loss. Larry gave the world Perl to use. Unlike
Java, Perl wasn't created to get the biggest market share possible. If
one wants to use Perl, fine. If one doesn't want to use Perl, for whatever
reason, fine. WE DON'T CARE. We don't get paid less. We don't feel hurt.
It's just the person or organization that rejects Perl that is missing out.
Noone else.

:: Moreover, if I have the choice in a program between several algorithms, and t
:: benchmarks show no or few differences, I prefer the one that will be potentia
:: faster in the future.

If micro-optimization of '$|++' vs '$|=1' is important to you, why on
earth are you using Perl? You should be programming in assembler then,
or at best C with an extremely good compiler.


Abigail
-- 
perl5.004 -wMMath::BigInt -e'$^V=Math::BigInt->new(qq]$^F$^W783$[$%9889$^F47]
 .qq]$|88768$^W596577669$%$^W5$^F3364$[$^W$^F$|838747$[8889739$%$|$^F673$%$^W]
 .qq]98$^F76777$=56]);$^U=substr($]=>$|=>5)*(q.25..($^W=@^V))=>do{print+chr$^V
%$^U;$^V/=$^U}while$^V!=$^W'


------------------------------

Date: Sat, 08 Jul 2000 09:44:38 GMT
From: elephant@squirrelgroup.com (jason)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <MPG.13d1954fd1342a2f98977a@news>

Luc-Etienne Brachotte writes ..
>Uri Guttman a écrit :
>
>> you don't get it. perl is interpeted. do you know what that means? i
>> don't think so from your posts. please read up on compiled
>> vs. interpeted languages. and note that perl has both phases.
>
>I have yet *written* interpreters and compilers

who cares .. the difference between $|++ and $|=1 is trivial .. and 6 
figure iterations need to be processed before any noticeable difference 
can be seen

and if both methods localise their $| first then there's almost zero 
difference

Luc - you originally wrote that the $|=1 was "(much) slower" .. this was 
incorrect and misleading

-- 
 jason - elephant@squirrelgroup.com -


------------------------------

Date: 8 Jul 2000 09:58:18 GMT
From: Ilmari Karonen <iltzu@sci.invalid>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <963049026.10774@itz.pp.sci.fi>

In article <3966D2C7.F5A40B6D@wanadoo.fr>, Luc-Etienne Brachotte wrote:
>Uri Guttman a écrit :
>> >>>>> "LB" == Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr> writes:
>>   LB> It depends on the CPU, but usually incrementing a memory location is
>>   LB> much faster than copying a location to another.
>>
>> this is perl, not c. perl ops are not simple memory copies or increments
>> but dispatched sub calls in C. you can not predict the speed of perl
>> code just by looking at perl.
>
>I was not speaking about C but CPUs internals, on which everything is based.

Uri is right, this thread is indeed silly, but I'd like to point out
that it's even sillier than that: On just about every processor I've
written assembly on (not that many, admittedly) storing a _constant_
(i.e. an immediate value) in memory is faster than incrementing.  This
is of course particularly true on systems which do not allow in-memory
arithmetic, requiring a load/add/store chain for $x++ as opposed to a
single store for $x=1.

Of course, many CPU's themselves have enough overhead to make storing
a constant and incrementing take exactly the same time under most
circumstances.  I can't recall the whole cycle count table anymore,
but I think this may apply to the 680x0 series.  Either that or the
increment is slower by one read access.


Perl is nowhere near as fast as well-written C, especially if you
insist on "writing C in Perl" instead of taking advantage of existing
fast routines provided by perl.  As someone who has written code where
an average improvement of half a cycle per iteration made a visible
difference, I'd like to add that C, even optimized, isn't as fast as
well tweaked assembly either.

The main advantage of Perl isn't execution speed, even though it is
certainly one of the advantages over naively interpreted scripting
languages.  What's important is development speed.  I don't really
care very much if my Perl code runs twice as slow as if I'd done it in
C, provided I can have it up and running today rather than next week.


Oh, and just to get back on the subject, $| isn't even an ordinary
variable.  Accessing it is better thought of as executing a system
call than as a simple memory access.

-- 
Ilmari Karonen - http://www.sci.fi/~iltzu/
"The screwdriver *is* the portable method."  -- Abigail
Please ignore Godzilla and its pseudonyms - do not feed the troll.



------------------------------

Date: 08 Jul 2000 11:55:18 +0100
From: Andrew Gierth <andrew@erlenstar.demon.co.uk>
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <87sntkx561.fsf@erlenstar.demon.co.uk>

>>>>> "Luc-Etienne" == Luc-Etienne Brachotte <Luc-Etienne.Brachotte@wanadoo.fr> writes:

 Luc-Etienne> According to CPU internals, $|++ should be faster than $|=1

this is of course nonsense, so your argument collapses before it even
gets underway. While there may exist CPUs for which it is true, it is
emphatically _not_ true on either current x86 processors or any of the
RISC families I'm familiar with.

Your analysis of the relative performance in terms of number of memory
locations is simply laughable, and has no relationship whatsoever with
the reality of modern CPU architectures.

-- 
Andrew.


------------------------------

Date: Sat, 08 Jul 2000 15:19:08 GMT
From: rurban@sbox.tu-graz.ac.at (Reini Urban)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <3967456e.12650700@news>

Abigail wrote:
>$| ++ is obscure and bad. $| = 1 makes it instantly clear what the
>effects are.

joking? both are obscure and bad.

use English;
use constant BUFFERED   => 1;
use constant UNBUFFERED => 0;

$OUTPUT_AUTOFLUSH = BUFFERED; # this is readable.
$| = 1;                       # this is unreadable.

--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html


------------------------------

Date: Sat, 08 Jul 2000 15:48:28 GMT
From: marcel@codewerk.com (Marcel Grunauer)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8mejl4.3pc.marcel@gandalf.local>

On Sat, 08 Jul 2000 15:19:08 GMT, Reini Urban <rurban@sbox.tu-graz.ac.at>
wrote:

>use English;
>use constant BUFFERED   => 1;
>use constant UNBUFFERED => 0;
>
>$OUTPUT_AUTOFLUSH = BUFFERED; # this is readable.
>$| = 1;                       # this is unreadable.


A lot of perl code could be considered unreadable by someone who doesn't
know perl, but if you do, it's ok to use perlvars. If you don't know
perl, you shouldn't program perl. I don't know APL, but I wouldn't go
to them and tell them APL is unreadable.


-- 
Marcel
sub AUTOLOAD{($_=$AUTOLOAD)=~s;^.*::;;;y;_; ;;print} Just_Another_Perl_Hacker();


------------------------------

Date: 08 Jul 2000 12:58:54 EDT
From: abigail@delanet.com (Abigail)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <slrn8meofv.rbj.abigail@alexandra.delanet.com>

Reini Urban (rurban@sbox.tu-graz.ac.at) wrote on MMDIII September
MCMXCIII in <URL:news:3967456e.12650700@news>:
~~ Abigail wrote:
~~ >$| ++ is obscure and bad. $| = 1 makes it instantly clear what the
~~ >effects are.
~~ 
~~ joking? both are obscure and bad.
~~ 
~~ use English;
~~ use constant BUFFERED   => 1;
~~ use constant UNBUFFERED => 0;
~~ 
~~ $OUTPUT_AUTOFLUSH = BUFFERED; # this is readable.
~~ $| = 1;                       # this is unreadable.


$OUTPUT_AUTOFLUSH = BUFFERED; is extremely obscure as it will turn
buffering *OFF*.

Furthermore, the English forms of punctuation characters are
indistinguishable from userland characters. There's nothing that gives
away that they are special, while punctuation variables look special. And
it's a hell of a lot easier not to use punctuation variables as user
variables than to not use variables that consists of characters.


Abigail
-- 
perl -we '$_ = q ;4a75737420616e6f74686572205065726c204861636b65720as;;
          for (s;s;s;s;s;s;s;s;s;s;s;s)
              {s;(..)s?;qq qprint chr 0x$1 and \161 ssq;excess;}'


------------------------------

Date: Sun, 09 Jul 2000 14:02:34 GMT
From: rurban@sbox.tu-graz.ac.at (Reini Urban)
Subject: Re: Why $|++ instead of $|=1 ?
Message-Id: <396884c8.94404566@news>

Reini:
>> use constant BUFFERED   => 1;
>> use constant UNBUFFERED => 0;

Abigail:
>$OUTPUT_AUTOFLUSH = BUFFERED; is extremely obscure as it will turn
>buffering *OFF*.

oops! but the fix would in the header only. 
the sources will stay readable in contrast to various obscurity
principles discussed before.

use constant BUFFERED   => 0;
use constant UNBUFFERED => 1;

>Furthermore, the English forms of punctuation characters are
>indistinguishable from userland characters. There's nothing that gives
>away that they are special, while punctuation variables look special. And
>it's a hell of a lot easier not to use punctuation variables as user
>variables than to not use variables that consists of characters.

agreed. to hell with use constant.
one uses it only with XS modules with "badly designed" API's anyway.
(say "OS-near").
--                                         
Reini


------------------------------

Date: 16 Sep 99 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 16 Sep 99)
Message-Id: <null>


Administrivia:

The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc.  For subscription or unsubscription requests, send
the single line:

	subscribe perl-users
or:
	unsubscribe perl-users

to almanac@ruby.oce.orst.edu.  

| NOTE: The mail to news gateway, and thus the ability to submit articles
| through this service to the newsgroup, has been removed. I do not have
| time to individually vet each article to make sure that someone isn't
| abusing the service, and I no longer have any desire to waste my time
| dealing with the campus admins when some fool complains to them about an
| article that has come through the gateway instead of complaining
| to the source.

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.

For other requests pertaining to the digest, send mail to
perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
sending perl questions to the -request address, I don't have time to
answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V9 Issue 3613
**************************************


home help back first fref pref prev next nref lref last post