Keep iterations below 2**30

[eregon]

• The logic already intended to do that but failed to keep it below 2**30 if the benchmark is very short when computing the cycles per 100ms.
• This potentially resulted in a very costly deoptimization for the second half of warmup, and a recompilation to either 64-bit integers or Bignum which is significantly slower.

[eregon]

For example when running https://gist.github.com/byroot/780c1fdee3585611f3bca1c49779617d on truffleruby 24.1.1, like ruby 3.2.4, Oracle GraalVM JVM [x86_64-linux], before it would hang for a very long time after:

truffleruby 24.1.1, like ruby 3.2.4, Oracle GraalVM JVM [x86_64-linux]
Warming up --------------------------------------
           say_hello

Because it would try to run the loop with a number of iterations > 32-bit, maybe even > 64-bit, that would cause a deoptimization and then we would have to run the loop in interpreter or with OSR compilation (significantly less optimized).

After:

truffleruby 24.1.1, like ruby 3.2.4, Oracle GraalVM JVM [x86_64-linux]
Warming up --------------------------------------
           say_hello     1.074B i/100ms
         public_send     1.074B i/100ms
                send     1.074B i/100ms
Calculating -------------------------------------
           say_hello     36.960Q (±15.2%) i/s    (0.00 ns/i) -     47.716Q
         public_send     36.258Q (±13.4%) i/s    (0.00 ns/i) -     49.885Q
                send     36.800Q (±16.1%) i/s    (0.00 ns/i) -     49.247Q

Comparison:
  say_hello: 36959903144559840.0 i/s
       send: 36800300321482968.0 i/s - same-ish: difference falls within error
public_send: 36258372060672192.0 i/s - same-ish: difference falls within error

It's clear the benchmark is optimized away :)
Probably the first time a quadrillion number of iterations by second is reported by benchmark-ips!

[nateberkopec]

quadrillion number of iterations by second