Skip to main content

More Perl 5 - Comparing "split range" vs "test in loop"

Although the difference I found between the split range and the test within loop implementations were small, it seems to me it's wrong.

So I boiled the test down to a bar minimum. I created a benchmark test consisting of nothing but the loop. I had to do something within the loop, so I stored the number in a variable.


  test8  => sub { for ( 0..8 ) {
                  next if $_ == 8;
                  my $j = $_;
              } },
  range0 => sub { for ( 0..-1,1..8) {
                  my $j = $_;
              } },



As the names and the code suggest, I actually had 9 test and 9 range instances, for each value in 0..8. While there was a little variation within the sets, the difference between sets was significant! Using a split range was 60% faster than testing within the loop. The test achieved 376923 .. 390809 iterations per second, compared to 596918 .. 606710 for the split range, when tested for 10 seconds per version. Testing just test4 vs range4 for a minute gave similar results:


          Rate  test4 range4
  test4  386996/s     --   -35%
  range4 593520/s    53%     --



How about if the loops are larger? If we go from 0 to 80 or 0 to 800 instead of just 0 to 8, the test should get worse, since it's repeating the test over and over, while the split range has no extra work to do.


  0-8,000
        Rate  test4 range4
  test4  540/s     --   -39%
  range4 886/s    64%     --

  0-80,000
         Rate  test4 range4
  test4  55.4/s     --   -38%
  range4 88.7/s    60%     --



And in fact the relative speed improves linearly as the loops size grows by powers of ten from an upper limit of 8, to 8,000, after which the improvement decreases ... guess that's log(N). But by 80,000 it's only doing 50 or 100 reps a second, accuracy may be fading.

So the question is, in isolated testing, the range is definitely better than the test within the loop. Why does the test perform better in the otherwise identical program? After all, all that was happening within the loop was hash and array de-referencing, and an integer comparison.


       return     # collision
          if $val == $self->{grid}[$row][$c];



Using -d:FProf, I see that BruteForceTest.pl took 0.030 seconds to run a total of 5450 row, column and block tests, while BruteForceExplicitList.pl took 0.026 seconds for 5450 calls to the unified test. using the timings from the first test, above, the explicit list loop should have been 9 ms while the repeated test should be 14 ms. Presumable the 16ms is the hash and array de-referencing and the comparison.

But the test wrapper, cell_value_ok used to be a trivial call to the row, column and block tests, but now it constructs a few arrays. That must be why it has gone from 0.006 ms to 0.015 ms.

Of course the real lesson is that profiling programs that take 1/10 second overall is a waste of time

Comments

Post a Comment

Popular posts from this blog

Perl5, Moxie and Enumurated Data Types

Moxie - a new object system for Perl5 Stevan Little created the Moose multiverse to upgrade the Perl 5 programming language's object-oriented system more in line with the wonderfull world of Perl 6. Unfortunately, it's grown into a bloated giant, which has inspired light-weight alternatives Moos, Moo, Mo, and others. Now he's trying to create a modern, efficient OO system that can become built into the language. I've seen a few of his presentations at YAPC (Yet Another Perl Conference, now known as TPC, The Perl Conference), among them ‎p5 mop final final v5 this is the last one i promise tar gz While the package provides some POD documentation about the main module, Moxie, it doesn't actually explain the enum package, Moxie::Enum. But delving into the tests directory reveals its secrets. Creating an Enum package Ranks { use Moxie::Enum; enum by_ARRAY => qw( unused 2 3 4 5 6 7 8 9 10 J Q K A ); enum by_HASH => { 2 => 2, 3 =...
5 comments
Read more

Implementing the Game with Perl & Moxie

I've been creating classes relating to playing cards using the new Moxie module for the Perl programming language. The objective is to implement the card game Go Fish! as specified at Rosetta Code . The Outside-In View An actual program file should be simple; all the real code should be in testable modules. In this case, play_go_fish.pl takes this to an extreme. #!/usr/bin/env perl use warnings; use strict; use 5.026; use lib '.'; use Game; Game->new()->play(); As of Perl 5.26, the current directory is not automatically part of @INC, the search path for modules, so it is necessary to include it manually. That makes it possible to load the Game module, to instantiate an instance, and play a game. package Game; use Moxie; use lib '.'; use Deck; use Computer; use Human; use Const::Fast; extends 'Moxie::Object'; const my @PLAYERS => qw( human computer ); const my $INITIAL_DEAL_COUNT => 9; A Game.pm object begins like most ot...
Post a Comment
Read more

Creating Perl5 Objects with Moxie

Having in the previous article prepared data types for car suits and card ranks, I can now combine them to provide a playing card class, using Stevan Little's Moxie module (version 0.04, so definitely early days.) The goal is to provide an object-oriented paradigm to the Perl 5 programming language which is more sophisticated, more powerful and less verbose than manually bless() -ing hashes. To achieve that goal it needs to be faster and light-weight compared to Moose. Currently, Moxie.pm and and MOP.pm are add-on modules, but eventually, when they are more complete, when the wrinkles have been ironed out, and when they have gained acceptance and a community of users, they might be merged into the Perl core. One significant feature of Moxie is that it reduces boilerplate code. You don't have to specify warnigns or strict . As well, the features or the perl you are using are enabled, among them say , state , signatures , and post_deref . A Simple Moxie Class packag...
Post a Comment
Read more