Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Magic 200MHz

Author: Tom Kerrigan

Date: 23:50:41 05/22/03

Go up one level in this thread


On May 22, 2003 at 22:24:29, Robert Hyatt wrote:

>On May 22, 2003 at 13:43:55, Tom Kerrigan wrote:
>
>>On May 21, 2003 at 22:20:57, Robert Hyatt wrote:
>>
>>>On May 21, 2003 at 15:48:46, Tom Kerrigan wrote:
>>>
>>>>On May 21, 2003 at 13:46:26, Robert Hyatt wrote:
>>>>
>>>>>On May 20, 2003 at 13:52:01, Tom Kerrigan wrote:
>>>>>
>>>>>>On May 20, 2003 at 00:26:49, Robert Hyatt wrote:
>>>>>>
>>>>>>>Actually it _does_ surprise me.  The basic idea is that HT provides improved
>>>>>>>resource utilization within the CPU.  IE would you prefer to have a dual 600mhz
>>>>>>>or a single 1000mhz machine?  I'd generally prefer the dual 600, although for
>>>>>>
>>>>>>You're oversimplifying HT. When HT is running two threads, each thread only gets
>>>>>>half of the core's resources. So instead of your 1GHz vs. dual 600MHz situation,
>>>>>>what you have is more like a 1GHz Pentium 4 vs. a dual 1GHz Pentium. The dual
>>>>>>will usually be faster, but in many cases it will be slower, sometimes by a wide
>>>>>>margin.
>>>>>
>>>>>Not quite.  Otherwise how do you explain my NPS _increase_ when using a second
>>>>>thread on a single physical cpu?
>>>>>
>>>>>The issue is that now things can be overlapped and more of the CPU core
>>>>>gets utilized for a greater percent of the total run-time...
>>>>>
>>>>>If it were just 50-50 then there would be _zero_ improvement for perfect
>>>>>algorithms, and a negative improvement for any algorithm with any overhead
>>>>>whatsoever...
>>>>>
>>>>>And the 50-50 doesn't even hold true for all cases, as my test results have
>>>>>shown, even though I have yet to find any reason for what is going on...
>>>>
>>>>Think a little bit before posting, Bob. I said that the chip's execution
>>>>resources were evenly split, I didn't say that the chip's performance is evently
>>>>split. That's just stupid. You have to figure in how those execution resources
>>>>are utilized and understand that adding more of these resources gives you
>>>>diminishing returns.
>>>>
>>>>-Tom
>>>
>>>
>>>You shold follow your own advice.  If resources are split "50-50" then how
>>>can _my_ program produce a 70-30 split on occasion?
>>>
>>>It simply is _not_ possible.
>>>
>>>There is more to this than a simple explanation offers...
>>
>>Now you're getting off onto another topic here.
>>
>
>Read backward.  _I_ did not "change the topic".
>
>I said that I don't see how it is possible for HT to slow a program down.
>
>You said "50-50" resource allocation might be an explanation.
>
>I said "that doesn't seem plausible because I have at least one example of
>two compute-bound threads that don't show a 50-50 balance on SMT."

I said it before and I'll say it again, a 50-50 _core_ resource split does not
mean a 50-50 performance split. Again, you have to account for how those
resources are utilized. Anybody who's passed the first semester of comp arch
should be able to grasp this immediately.

>If Eugene is right, and I don't know as he was not sure and I haven't read
>anything similar to what he mentioned, that _could_ explain it (ie if some
>resources are split 50-50 between the two logical processors even if one
>could use more than the other due to the particular application being run.
>However that seems like a _bad_ design decision if it is true...)  However
>there are probably other plausible explanations as well.  What is the _real_
>explanation?  That will likely take some time to figure out.

Complete bull. This design is no secret--Intel wants everybody to know exactly
how HT works so they can optimize their software for it. This information is all
over Intel's web pages and developer documentation. Links to said pages have
been posted to this message board. It will only take YOU some time to figure out
because your head seems to be stuck in the sand.

-Tom



This page took 0.01 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.