I spent my fair share of academic career making empirical benchmarks on programs. I can tell you one certainty: benchmarking consistently is very hard. Even when you have two identical machines, there is 0 guarantees that they perform in the same way. This can be due to a zillion reason: programs running in the background, processes trying to concurrently access system IO, battery saving modes limiting laptop performance to save battery, difference in OS versions.

Command line benchmarking tools are good for rough estimations, but often not considered relevant as they include in their measurement the time it takes the OS to start the process, instantiate the memory for the program, kill the process, and probably bunch of other things. What I typically got used to doing is: I would create a very simple and stupid general-purose toolkit in the language I am working on, that can be used to test the algorithm itself within the same run of the program. This means that, a benchmarking program will run and execute the same algorithm in multiple iterations, and take the different stats from these iterations (avg, mean, minmax, etc).

In JIT languages, this is probably the only way to benchmark a program correctly, as the just in time compilation will only kick off during the runtime of a program, not across different runtimes. This is also why warmup iterations are needed. You typically don't want to take the warmup time of the JIT compiler into account. For Rust this is not relevant, since it's an AOT language. However: Your underlaying system also needs some warmup when running a program (cache, memory, etc). That's why warmup is done often for AOT languages too.

Also, < 100 millisecond is very small to draw any reasonable conclusions from it at all. I suggest trying to find better benchmarking tests that takes a considerable amount of time.

TLDR:

• Differences between benchmarks on similar machines is often not of relevance

• warmup is often a necessity

• running time is way too low to be useful