First, some (hopefully) obvious remarks:
- you only need to present CPU specs if you are going to publish CPU timings
- CPU timings depend on variety of factors, including hardware specs, OS, drivers, libraries, software, configuration of this software, etc. It is unlikely that the combination of all these factors will be reproduced exactly.
- Even a very detailed list of hardware specs that can be published in an academic paper is likely to be incomplete: for example you can say that CPU is i5, but will you mention the rev? will you mention the microcode version? will you mention how well the CPU is cooled and how recently the thermopaste was changed?
- The same is probably true for the software: it is unlikely that one can report versions of all drivers / libraries / software involved in the process.
It becomes clear that any publishable list of specs will not be sufficient to reproduce the settings. In my opinion, the exact reproduceability is not achievable and hence is not the aim.
I always provide and use the CPU specs as a rough guide that helps me to understand the behaviour of the CPU timings reported as a function of problem parameters. Can this slowdown be due to the data falling off the CPU cache? Can it be due to insufficient memory and hence disk swapping? Does this software allow to use all CPU cores or is only one core active? Can we (roughly) compare the timings reported in this paper with the timings reported by competitors, or are the setups too dissimilar?
At least once in my own experience I encountered an example of scientific fraud, when the reported timings could not be achieved on the declared CPU due to trivial complexity estimations — it could be easily shown that even at 100% efficiency the stated CPU could not perform the calculations needed in time claimed. In this case the details of the setup were handy to make the case.
Final note: reporting CPU specs is important, but making the code available is far more important and I wish people in academia do it more often!