And for some reason, it decided to run 'trivial2' 16 times as many times as 'trivial1'.

The reason is the same as the problem with the OP's original benchmark.

c:\test>perl -mstrict -we"1;"

c:\test>perl -mstrict -we"2;"
Useless use of a constant in void context at -e line 1.
[download]

1 is a special cases for Perl constants that does not get optimised away, and is the reason why I used  ... and 1; to avoid the "Useless use in a void context" in my benchmark.

This special case is so that things like these work:

while( 1 ) {...
... if 1;
1 while ....;
[download]

However, 2 is not special and so gets optimised away. Hence, trivial1 takes longer than trivial2, so the loop has to be run many, many times more in order to accumulate the "for at least 1 second of cpu" in

timethese -1, {
    trivial1  => sub {1},
    trivial2  => sub {2},
};;
Benchmark:
running
  trivial1, trivial2
 for at least 1 CPU seconds
...
[Range iterator outside integer range at (eval 57) line 1, <STDIN> lin
+e 7.
[download]

I guess my machine is faster than yours. Faster enough that when Benchmark attempted to run the loop for sufficient iterations to accumulate the required cpu usage, it encountered my pet hate of the perl iterator!

it took about 5 _minutes_ to run this benchmark.

Unsurprising. When the bodies of the iterator loops is doing next to nothing, or actually nothing, when Benchmark does it initial timings of them in order to calculate the number of iterations to run it for, it attempts to subtract a small amont to account for the overhead of the loop itself, with the result that the calculation are probably being subjected to rounding errors.

When it takes 84 million iterations of a test to accumulate 1 second of cpu on a modern processor, it certainly indicates that something is wrong with your benchmark.

This is why I tend to incorprate for loops within the test when benchmarking very small pieces of code, rather than relying on the benchmark iteration count.