The explanation is a bit more detailed than that.
As of right now, Capacity Planner uses a fixed dimishing return rate for each additional core added. Each core aboue the first contributes 90% of it's MHz into the "effective" amount of cycles that it can add to overall speed. This is specifically for 64-bit CPUs.
Here is a list of Core count VS Effective MHz contributed for that core, at the bottom is the sum of all effective CPU measures:
Core Count | x3690 | x3650 |
1 | 2400 | 3460 |
2 | 2160 | 3114 |
3 | 1944 | 2802.6 |
4 | 1749.6 | 2522.34 |
5 | 1574.64 | 2270.106 |
6 | 1417.176 | 2043.0954 |
7 | 1275.4584 | 1838.78586 |
8 | 1147.91256 | 1654.907274 |
9 | 1033.121304 | 1489.416547 |
10 | 929.8091736 | 1340.474892 |
11 | 836.8282562 | 1206.427403 |
12 | 753.1454306 | 1085.784662 |
13 | 677.8308876 | |
14 | 610.0477988 | |
15 | 549.0430189 | |
16 | 494.138717 | |
17 | 444.7248453 | |
18 | 400.2523608 | |
19 | 360.2271247 | |
20 | 324.2044122 | |
Sum Of Resources | 21082.16029 | 24827.93804 |
I know this may not seem 100% appropriate for modern hardware, and we are looking at this ratio of diminishing returns for improvement in the optimization algorithm.
This at least provides a concrete example of Speed VS CoreCount to determine number of effective CPU cycles we can get out of a physical.
Best Regards,
Jon Hemming