The efficiency of ikegami's solution appears to be due to the efficiency of its list generation. The second code sample above using ikegami's list generation + integer division is only marginally slower than ikegami's code. I presume this is due to the 4 vs. 5 ops for int($n/$m) vs. ($n-$r)/$m mentioned in ikegami's explanation of the performance differences between these two expression.

# using Benchmark::cmpthese(-1, ...) on input (10,3)
# Debian (Etch) Linux, Perl 5.8.8

          Rate   syp   buk eli_1 eli_2   ike
syp   146161/s    --  -23%  -50%  -65%  -66%
buk   189150/s   29%    --  -35%  -54%  -56%
eli_1 289616/s   98%   53%    --  -30%  -32%
eli_2 412559/s  182%  118%   42%    --   -3%
ike   425821/s  191%  125%   47%    3%    --
[download]

I also note that the comparison results for syp, buk, eli don't seem quite the same as BrowserUK's results. The iterations per second are much higher and the comparison % quite different.

For example,in BrowserUK's results buk is 42% faster than syp, but here only 23%. In BrowserUK's benchmark, buk & eli_1 are roughly comparable (9% difference) and ike is 106% faster than eli. But here, eli_1 is 53% faster than buk and ike is only 47% faster than eli_1.

Any thoughts on why? Differences in Perl implementations? Inputs? Number of iterations? Just noise due to OS or machine differences?

Update: The results do seem dependent on input. Changing the input to (10000,3) makes no real difference in benchmarks, but changing the input to (10000, 9999) results in this benchmark. The ranking is still the same, but the results clearly break into two clusters based on list construction: (syp, buk,eli_1) and (ike,eli_2).

        Rate    syp    buk  eli_1  eli_2    ike
syp    63.9/s     --   -70%   -89%  -100%  -100%
buk     212/s   231%     --   -62%  -100%  -100%
eli_1   560/s   776%   164%     --   -99%   -99%
eli_2 61265/s 95828% 28846% 10847%     --    -3%
ike   63015/s 98569% 29673% 11160%     3%     --
[download]