But, that was not my goal. My goal was to benchmark the filtering/processing methods of grep, map, and~~ against the same data set.

That implies that you have an application for filtering values against an array that is currently too slow; so you chose too benchmark alternatives. That's good.

But rather than benchmarking the actual application, you made up this 'unique random number selection' problem and used that as the basis of your benchmark. That's less good.

The chances are that if you posted a benchmark for the actual application, then one of the monks would see an alternative approach to that application that would similarly avoid the need to do O(N) processing of a huge list.

For example, for simple unique filtering of small lists of values, using a hash is way more efficient:

sub hashGen {
    my $idx = 0;
    my %mArray;
    ++$mArray{ $nums[ ++$idx ] } while keys %mArray < $uSize;
    return keys %mArray;
}

__END__
C:\test>junk
             Rate   grepGen    mapGen  firstGen  smartGen   hashGen sh
+uffleEm
grepGen    45.2/s        --      -54%      -79%      -96%      -99%   
+  -100%
mapGen     97.9/s      116%        --      -54%      -91%      -98%   
+  -100%
firstGen    214/s      374%      119%        --      -80%      -97%   
+   -99%
smartGen   1074/s     2274%      997%      401%        --      -83%   
+   -96%
hashGen    6500/s    14275%     6540%     2932%      506%        --   
+   -75%
shuffleEm 25619/s    56551%    26068%    11849%     2286%      294%   
+     --
[download]

Wow, screaming fast! Makes sense because of the nature of hashes: no duplicates. Thanks for the info.

           Rate  grepGen   mapGen smartGen  hashGen
grepGen  29.8/s       --      -3%     -89%     -97%
mapGen   30.6/s       3%       --     -89%     -97%
smartGen  278/s     833%     807%       --     -75%
hashGen  1096/s    3583%    3480%     295%       --
[download]