Re: A practical benchmark shows speed challenges for Perl 6
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
On Mar 31, 2016, at 8:56 AM, Tom Browder mailto:tom.brow...@gmail.com>> wrote: On Thursday, March 31, 2016, Elizabeth Mattijsen mailto:l...@dijkmat.nl>> 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
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
Re: A practical benchmark shows speed challenges for Perl 6
> 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 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. I think jnthn already as synchronous printing (not using libuv) on the list of things to do. Liz
A practical benchmark shows speed challenges for Perl 6
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
> 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
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
Re: A practical benchmark shows speed challenges for Perl 6
> On 31 Mar 2016, at 00:22, Tom Browder wrote: > On Tue, Mar 29, 2016 at 10:29 PM, Timo Paulssen wrote: >> On 03/30/2016 03:45 AM, Timo Paulssen wrote: >> >> Could you try using $filename.IO.slurp.lines instead of $filename.IO.lines >> and see if that makes things any faster? >> - Timo >> >> >> Actually, the method on an IO::Handle is called "slurp-rest"; slurp would >> only work with a filename instead. >> - Timo > > Okay, I've done a comparison of the three methods on a 1 Gb file: > > IO.lines > real 2m11.827s > user 2m10.036s > sys 0m1.468s > > IO.split > real 1m51.504s > user 1m51.136s > sys 0m0.352s > > IO.slurp-rest > real 2m9.821s > user 2m6.268s > sys 0m3.532s > > and Perl 5: > > real 0m4.614s > user 0m4.328s > sys 0m0.280s Just a sanity check: is this including the processing that you need to do, or just an empty loop reading lines? If the former, perhaps the overhead is not in the reading per se, but in the processing. Judging from the difference in your benchmark and mine, I would guess that only 40 seconds of the IO.lines case is actually involved in reading, and the other 90 are actually spent in processing. 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?? Liz
