Um, okay,  But I'm still seeing the same behavior Andy is, using the
last rakudo star release 2019.03.1, Perl 6.d:

   seq 1000000 | perl6 -ne 'my Int $y += $_; END { print $y; }'
   500000500000

This is on linux, (32 bit Debian 9, aka stretch).


On 9/26/19, Andy Bach <andy_b...@wiwb.uscourts.gov> wrote:
>>  Still, it's just "works for me":
>
> seq 1000000 | time perl6 -ne 'my $y += $_; END { print $y; }'
>
> I think that's still the wrong one - your missing the "Int"
> $ seq 1000000 | perl6 -ne 'my Int $y += $_; END { print $y; }'
> 500000500000
>
> though that works here, admittedly, my p6 is sort old
> This is Rakudo version 2018.03 built on MoarVM version 2018.03
> implementing Perl 6.c.
>
> I'm a little puzzled, I'd've thought the loop around the 'my Int $y' would
> redeclare a local $y each time.  Instead it behaves like:
> $ time perl6 -e 'my Int $y = 0;for ( 1 .. 1000000) { $y += $_} ;  say $y; '
>
> (which is signficantly faster ;-)
> 500000500000
> real 0m1.229s
> user 0m1.254s
> sys 0m0.040s
>
> )
> ________________________________
> From: Joseph Brenner <doom...@gmail.com>
> Sent: Wednesday, September 25, 2019 11:13 PM
> To: William Michels <w...@caa.columbia.edu>
> Cc: Marc Chantreux <e...@phear.org>; Vittore Scolari
> <vittore.scol...@gmail.com>; Elizabeth Mattijsen <l...@dijkmat.nl>; perl6
> <perl6-users@perl.org>
> Subject: Re: anything faster than say [+] lines?
>
> Oh, wait.  I tried the wrong one-liner.  Still, it's just "works for me":
>
> seq 1000000 | time perl6 -ne 'my $y += $_; END { print $y; }'
> 50000050000029.29user 0.06system 0:28.41elapsed 103%CPU
> (0avgtext+0avgdata 76196maxresident)k
> 63328inputs+0outputs (32major+15588minor)pagefaults 0swaps
>
>
>
> On 9/25/19, Joseph Brenner <doom...@gmail.com> wrote:
>> I just gave that one-liner a try, but I didn't see that error:
>>
>>> seq 1000000 | time perl6 -e 'say [+] lines'
>> 500000500000
>> 28.70user 0.07system 0:28.29elapsed 101%CPU (0avgtext+0avgdata
>> 74188maxresident)k
>> 63424inputs+0outputs (32major+15409minor)pagefaults 0swaps
>>
>>
>> perl6 --version
>> This is Rakudo Star version 2019.03.1 built on MoarVM version 2019.03
>> implementing Perl 6.d.
>>
>> uname -a
>> Linux fandango 4.9.0-8-686 #1 SMP Debian 4.9.144-3 (2019-02-02) i686
>> GNU/Linux
>>
>>
>>
>> On 9/24/19, William Michels via perl6-users <perl6-users@perl.org> wrote:
>>> I'm seeing a strange error. I started trying out Marc's original code,
>>> then tried to adapt some Perl5-type solutions from SO to see how they
>>> performed when re-written as Perl6. One thing I wanted to explicitly
>>> test was how restricting to an "Int" type affected performance.
>>>
>>> However, I found a surprising result: a sequence of one-million Ints
>>> throws an error, but a sequence of 999,999 Ints does not:
>>>
>>>> mbook:~ homedir$ seq 1000000 | time perl6 -e 'say [+] lines'
>>>> 500000500000
>>>>         4.81 real         4.86 user         0.20 sys
>>>> mbook:~ homedir$ seq 1000000 | time perl6 -ne 'my $y += $_; END { print
>>>> $y; }'
>>>> 500000500000        4.88 real         5.06 user         0.19 sys
>>>> mbook:~ homedir$ seq 1000000 | time perl6 -ne 'my Int $y += $_; END {
>>>> print $y; }'
>>>> Type check failed in assignment to $y; expected Int but got Num
>>>> (500000500000e0)
>>>>   in block <unit> at -e line 1
>>>> 499999500000        4.77 real         4.97 user         0.19 sys
>>>> mbook:~ homedir$ seq 999999 | time perl6 -ne 'my Int $y += $_; END {
>>>> print
>>>> $y; }'
>>>> 499999500000        4.86 real         5.05 user         0.19 sys
>>>> mbook:~ homedir$ perl6 -v
>>>> This is Rakudo version 2019.07.1 built on MoarVM version 2019.07.1
>>>> implementing Perl 6.d.
>>>> mbook:~ homedir$
>>>
>>> Any comments or explanation appreciated,
>>>
>>> Best Regards, Bill.
>>>
>>>
>>>
>>>
>>> On Tue, Sep 24, 2019 at 1:59 AM Marc Chantreux <e...@phear.org> wrote:
>>>>
>>>> hello,
>>>>
>>>> > > > > nice ... but when x is ~ 75440 (not always), there is a problem
>>>> > > > What is x here?
>>>> > > sorry. x is the arg of seq (number of lines).
>>>> > That never happens on my laptop
>>>>
>>>> well.. so it's a problem with my station. nevermind :)
>>>>
>>>> thanks again for helping
>>>> marc
>>>
>>
>

Reply via email to