Re: A practical benchmark shows speed challenges for Perl 6

[Tom Browder]

On Thursday, March 31, 2016, Elizabeth Mattijsen  wrote:
...

> Perhaps you could do a —profile on a case that runs about 5 seconds or so,
> to get an idea of the bottleneck?
>
> Or could you gist the code that does the actual processing??


Okay, Liz, I'll work on the instructions found here and see what I can find:

  https://doc.perl6.org/language/performance

Then I'll "gist" it if I find something "gistable."

Thanks.

-Tom

Re: A practical benchmark shows speed challenges for Perl 6

[Fields, Christopher J]

On Mar 31, 2016, at 8:56 AM, Tom Browder 
> wrote:

On Thursday, March 31, 2016, Elizabeth Mattijsen 
> wrote:
> On 31 Mar 2016, at 14:12, Tom Browder > 
> wrote:
> Liz, it's a simple reader of a text file.  The only line processing is a 
> print of the number of characters of each line.  I guess I should eliminate 
> that but I assumed that was neglible since all the reader scripts do the same.

I wonder.  I wouldn’t be surprised if not printing number of chars would make a 
significant difference.

I'll try turning any line processing off, but note the Perl 5 reader does the 
same thing.

Best,

-Tom

Just to note, I have also seen dramatic differences in IO between Perl 5 and 
Perl 6, simply iterating through large files (in this case DNA sequence data) 
by line w/ no processing.

Chris

Re: A practical benchmark shows speed challenges for Perl 6

[Tom Browder]

On Thursday, March 31, 2016, Elizabeth Mattijsen  wrote:

> > On 31 Mar 2016, at 14:12, Tom Browder  > wrote:
> > Liz, it's a simple reader of a text file.  The only line processing is a
> print of the number of characters of each line.  I guess I should eliminate
> that but I assumed that was neglible since all the reader scripts do the
> same.
>
> I wonder.  I wouldn’t be surprised if not printing number of chars would
> make a significant difference.


I'll try turning any line processing off, but note the Perl 5 reader does
the same thing.

Best,

-Tom

A practical benchmark shows speed challenges for Perl 6

[Tom Browder]

Liz, it's a simple reader of a text file.  The only line processing is a
print of the number of characters of each line.  I guess I should eliminate
that but I assumed that was neglible since all the reader scripts do the
same.

I put the code on pastebin earlier, but I'll put the code on my github
account later today. I'm sure it can be tweaked, but the gross differences
between Perl 6 and Perl 5 doing a very common task I think should be
seriously investigated by someone familiar with MoarVM internals.

Best,

-Tom

Re: A practical benchmark shows speed challenges for Perl 6

[Elizabeth Mattijsen]

> On 31 Mar 2016, at 09:50, Jan Ingvoldstad  wrote:
> 
> On Wed, Mar 30, 2016 at 9:20 PM, Elizabeth Mattijsen  wrote:
> 
> Thanks for your thoughts!
> 
> I’ve implemented $*DEFAULT-READ-ELEMS in 
> https://github.com/rakudo/rakudo/commit/5bd1e .
> 
> Of course, all of this is provisional, and open for debate and bikeshedding.
> 
> 
> Brilliant and brilliantly quick response, Liz!
> 
> In the spirit of bikeshedding, my first thought is that the variable name 
> should have something with BUFFER in it, as that is what it appears to be. :)
> 
> Functionally, it's nice to be able to set it via the environment, but since 
> the environment may not necessarily be controlled by the programmer, I 
> consider that to be a short term solution.
> 
> A longer term solution would be for a way to set it within the program that 
> the environment cannot override.
> 
> Additionally, there could also be a default, compile-time option for Rakudo.
> 
> 
> The reasoning behind _not_ setting things via environment variables, is that 
> this means the programmer now needs to worry what e.g. the webserver running 
> the Perl program does, and there are unknown stability (and possibly 
> security) implications. This adds bloat to the program.
> 
> The programmer is better off if they only explicitly need to worry about it 
> when they want to change the defaults.

The environment variable is only used if there is no dynamic variable found.  
So, if a programmer wishes to use a specific buffer size in the program, they 
can.



Liz

Re: A practical benchmark shows speed challenges for Perl 6

[Jan Ingvoldstad]

On Wed, Mar 30, 2016 at 9:20 PM, Elizabeth Mattijsen  wrote:
>
>
> Thanks for your thoughts!
>
> I’ve implemented $*DEFAULT-READ-ELEMS in
> https://github.com/rakudo/rakudo/commit/5bd1e .
>
> Of course, all of this is provisional, and open for debate and
> bikeshedding.
>
>
Brilliant and brilliantly quick response, Liz!

In the spirit of bikeshedding, my first thought is that the variable name
should have something with BUFFER in it, as that is what it appears to be.
:)

Functionally, it's nice to be able to set it via the environment, but since
the environment may not necessarily be controlled by the programmer, I
consider that to be a short term solution.

A longer term solution would be for a way to set it within the program that
the environment cannot override.

Additionally, there could also be a default, compile-time option for Rakudo.


The reasoning behind _not_ setting things via environment variables, is
that this means the programmer now needs to worry what e.g. the webserver
running the Perl program does, and there are unknown stability (and
possibly security) implications. This adds bloat to the program.

The programmer is better off if they only explicitly need to worry about it
when they want to change the defaults.
-- 
Jan