Follow along with the video below to see how to install our site as a web app on your home screen.
Note: This feature may not be available in some browsers.
Normal
I have to admit I'm having trouble following your post but I think maybe you misunderstood my last post - I was writing it very early in the morning and sleep deprived so I apologize for any confusion. Unfortunately I'm still not feeling great so I apologize in advance if any confusion continues in the following post.My conclusion was that the tests show the hallmarks of being largely compute-bound rather than memory-bound. This does not however mean that none of the tests had 0 response to the improvement in memory on top of the improvements in clocks and indeed the improvement in memory bandwidth (and latency) could be aiding the clock speed increase (as in without the memory bw/latency improvements performance wouldn't have even kept up with the clock speed increases). I can't rule that out and a priori no I don't know much about the individual tests. I could try to run Instruments to record memory bandwidth during each test manually, but that would be a challenge and the last time I tried it on the Cinebench GPU test it crashed my computer. How I reached my conclusion was as follows:1) I knew that the average of the GB6 compute tests had increased by 13.7% off a 9.7% increase in clocks while the memory bandwidth had improved by 20% and that many of the graphics benchmarks as presented by reviewers had similarly increased by about 10%, so I knew that overall that benchmarks were increasing in concordance with the increase in clocks rather than the memory bandwidth increase. This indicates that the increase in clocks is the primary driver of the increase in performance rather than bandwidth - at least for these benchmarks.2) What I was wondering however was if any of the GB6 compute subtests would show a more significant bump in performance more commensurate with the 20% increase in bandwidth than the 10% increase in clocks. Since the tests are iso-clock normalized, in order for that to be the case most of the subtests would have to be at 1 (in line with the clock increase) while one or at most two would be closer to 1.1 since the average has to work out to about 1.03. Instead what we see is basically every subtest from M3 to M4 falls between 1 and 1.045. This indicates that the algorithms used in GB6 are overall compute constrained. There may be some small additional uplift from the memory bandwidth on top of the clocks for a few of the tests, but it falls short of providing the full extra boost. To really nail that down better though I'd have to do what [USER=263]@leman[/USER] and I did for the CPU tests and make violin plots to get a sense of the variance for each individual subtest. Just don't have the time/energy to do that right now. Here are the actual numbers in table form rather than chart version if that clears anything else:[ATTACH=full]29757[/ATTACH]
I have to admit I'm having trouble following your post but I think maybe you misunderstood my last post - I was writing it very early in the morning and sleep deprived so I apologize for any confusion. Unfortunately I'm still not feeling great so I apologize in advance if any confusion continues in the following post.
My conclusion was that the tests show the hallmarks of being largely compute-bound rather than memory-bound. This does not however mean that none of the tests had 0 response to the improvement in memory on top of the improvements in clocks and indeed the improvement in memory bandwidth (and latency) could be aiding the clock speed increase (as in without the memory bw/latency improvements performance wouldn't have even kept up with the clock speed increases). I can't rule that out and a priori no I don't know much about the individual tests. I could try to run Instruments to record memory bandwidth during each test manually, but that would be a challenge and the last time I tried it on the Cinebench GPU test it crashed my computer. How I reached my conclusion was as follows:
1) I knew that the average of the GB6 compute tests had increased by 13.7% off a 9.7% increase in clocks while the memory bandwidth had improved by 20% and that many of the graphics benchmarks as presented by reviewers had similarly increased by about 10%, so I knew that overall that benchmarks were increasing in concordance with the increase in clocks rather than the memory bandwidth increase. This indicates that the increase in clocks is the primary driver of the increase in performance rather than bandwidth - at least for these benchmarks.
2) What I was wondering however was if any of the GB6 compute subtests would show a more significant bump in performance more commensurate with the 20% increase in bandwidth than the 10% increase in clocks. Since the tests are iso-clock normalized, in order for that to be the case most of the subtests would have to be at 1 (in line with the clock increase) while one or at most two would be closer to 1.1 since the average has to work out to about 1.03. Instead what we see is basically every subtest from M3 to M4 falls between 1 and 1.045. This indicates that the algorithms used in GB6 are overall compute constrained. There may be some small additional uplift from the memory bandwidth on top of the clocks for a few of the tests, but it falls short of providing the full extra boost. To really nail that down better though I'd have to do what [USER=263]@leman[/USER] and I did for the CPU tests and make violin plots to get a sense of the variance for each individual subtest. Just don't have the time/energy to do that right now. Here are the actual numbers in table form rather than chart version if that clears anything else:
[ATTACH=full]29757[/ATTACH]
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register. By continuing to use this site, you are consenting to our use of cookies.