Some Improvements for Benchmark Page

[mert-kurttutan]

To make the benchmark more clear (and easier to reproduce (modulo hardware specs)), I think a few more details are needed.
For instance, it is said that the benchmark are run with 12 threads. But, it is not fully clear how many threads are actually used. There are several factors that determines it (depending of the what kind of wrappers are used around BLAS implementation).

To give an example, # threads is managed by $OMP_NUM_THREADS with openmp parallelization enabled (or $MKL_NUM_THREADS and $OMP_NUM_THREADS for intel mkl. What I am saying is that it can be difficult to conclude how many threads are actually used.

It would be better to state number of threads explicitly with environment variables.

The results for singled threaded for other libraries would also be beneficial to include in the benchmark page.

The theoretical limit should also be included (in GFLOPS)

[oscardssmith]

also, I think it would be nice if the benchmarks were line graphs rather than tables.

[mert-kurttutan]

Another detail:

• Sometimes OS does funny things for choosing which cpu cores to run. So, it would be nicer to set cpu affinity through some api either through rust or command line. For me, the easiest option is to use taskset since it does not require any change in code base.
• Regarding cpu core issue (due to OS assigning different clock speed to cpu cores), when you measure the time taken either through criterion or std::time, in the rust version of gemm functions, it sometimes chooses slower cpu cores and (longer run time) and sometimes the faster one. Funnily enough, the versions from C codebases, e.g. openblas, consistently chooses faster cpu core.

[mert-kurttutan]

also, I think it would be nice if the benchmarks were line graphs rather than tables.

I think this would be especially useful when you want to represent GFLOPS, which it should. Otherwise, time taken involves wildly different scales, making it a bit more difficult interpret