All,
(Wades into discussion late, having read (and tried to follow) the whole tread...)
I was involved in the benchmarking group that came up with HS06. It was clear at the time that HT has an impact on the benchmark score of a 'processing unit', significantly in some cases but dependent on system architecture etc as well as workload.
The recommendation from the group was that sites should benchmark their systems in the configuration that is to be used in production, so that for HT on with all threads used, benchmark for that. So for example two 6-core HT chips with HT on (24 threads) and with a two 'job' overload, you benchmark with HT on and 26 jobs in the SPEC run.
That way the HS06 score per 'processing unit' (call it hyperthread for HT on and core for HT off) - Total HS score / number of benchmark threads - reflects what you're actually doing in real life. Then a job landing on a 'processing unit' on your cluster can expect on average a performance of <wibble>HS06.
And if you benchmark in one mode and then turn HT on/off, you *must* re-benchmark because your cluster performance changes.
It is not clear to me that the intention stated above was actually promulgated, but that was the intention for use of the HS06 benchmark. Otherwise it's meaningless and you may as well use clock speeds.
As to how you cater for this in the info system: publish the HS06 score that a 'thread' will get on your cluster, and count the number of simultaneous threads possible.
<ducks>
Martin.
--
Martin Bly
RAL Tier1 Fabric Manager
|