By: , May 31, 2013 5:59 pm
Room: Moderated Discussions
rwessel (robertwessel.delete@this.yahoo.com) on May 31, 2013 3:20 pm wrote:
> Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on May 31, 2013 2:22 pm wrote:
> >
> > - Ah, so it simply gives full priority to a second thread to utilize unused execution units? If so; can
> > you please explain as to why some applications that ARE indeed multi-threaded, but still don't benefit
> > from multi-threading? It's weird how I find some game benchmarks to either take very little/none at all/a
> > performance HIT with hyperthreading enabled, when it's for sure that they use multiple threads...
> >
>
> There remains contention for resources. For example the decoders, branch prediction units, reservation
> and reorder stations, caches, memory, etc. Consider a simple case where the first thread is creating
> nearly enough memory references (after caching) that the available memory bandwidth is large consumed
> by the first thread. Adding a second thread won't make any more memory bandwidth available. Likewise,
> a single thread might cache well, but with two threads running, and both threads competing for a
> fixed size cache, they may both start generating many more cache misses.
Oh-- perfect! I understand all you have said now! Thank you very much!
Just one last little thing; why is this only done for two threads and not a variable amount of threads? Was it done for some sort of balancing; that having more than two threads would create way too much stress on the resources of one core? So they chose two as a middle ground?
> Sebastian Soeiro (sebastian_2896.delete@this.hotmail.com) on May 31, 2013 2:22 pm wrote:
> >
> > - Ah, so it simply gives full priority to a second thread to utilize unused execution units? If so; can
> > you please explain as to why some applications that ARE indeed multi-threaded, but still don't benefit
> > from multi-threading? It's weird how I find some game benchmarks to either take very little/none at all/a
> > performance HIT with hyperthreading enabled, when it's for sure that they use multiple threads...
> >
>
> There remains contention for resources. For example the decoders, branch prediction units, reservation
> and reorder stations, caches, memory, etc. Consider a simple case where the first thread is creating
> nearly enough memory references (after caching) that the available memory bandwidth is large consumed
> by the first thread. Adding a second thread won't make any more memory bandwidth available. Likewise,
> a single thread might cache well, but with two threads running, and both threads competing for a
> fixed size cache, they may both start generating many more cache misses.
Oh-- perfect! I understand all you have said now! Thank you very much!
Just one last little thing; why is this only done for two threads and not a variable amount of threads? Was it done for some sort of balancing; that having more than two threads would create way too much stress on the resources of one core? So they chose two as a middle ground?
