Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: HyperThreading Revisited

Author: Jeremiah Penery

Date: 05:02:46 11/09/02

Go up one level in this thread


On November 09, 2002 at 07:30:13, Bo Persson wrote:

>On November 08, 2002 at 20:59:09, Nolan Denson wrote:
>
>> So multithreading chess programs will have a
>>problem and multi-tasking will see the speedup.
>
>This looks like something Vincent would say. :-)
>
>Really there is no practical difference between multi-threading and
>multi-tasking (except for the shared/non-shared address space).
>
>>Now what I am wondering is such a thing possible for a chess program?
>>
>>Can a program like crafty take some of its threads and do something else that
>>doesn't use the same register's?
>
>The don't use the same registers, that's the real point of this
>Hyperthreading(TM). Like Bob explains below, the processor have two sets of
>registers that do not compete, except for memory access and execution resources.

There is only one set of registers, but 2 copies of the rename table.  Since
there must always be at least one rename register for each in-flight instruction
possible (128 on P4, I believe), and since HyperThreading can't increase the
theoretical limit on in-flight instructions, the single copy of the register
file is enough.

>For a long time now, the Pentium processors have actually just looked like x86
>processors, while they have used an internal execution core to do the real job.
>The register renaming is just one aspect of this; there are more physical
>registers than register names, so the connections between a name and a register
>is changed as needed durinf execution.

The destination registers are ALWAYS renamed during execution, not just 'as
needed'.  The reason for this is that there have to be enough registers anyway,
and a complicated logic to determine 'when needed' would be too expensive in
terms of chip resources, which can better be used elsewhere.

>So there are two distinct parts of the chip, a front end or "Architectual state"
>which contains the registers and flags that an assembly programmer or a compiler
>sees, and an execution core (or back end) that does the actual work. They have
>very little in common; so little that Intel can add a second copy of the
>"Architectual state" to the chip. The hyperthreading P4s now have two front-ends
>and one back-end.

That is not strictly true (parts of the front-end are partitioned, rather than
replicated), but that's pretty much how it works in practice.  The rest of what
you've said is pretty accurate.

>We knew from before that Intel had some problems fitting the P4 paper design on
>a limited size chip. This made the P4 a bit unbalanced, making it hard to keep
>all of its parts busy at all times.
>
>Now, with two guys feeding the execution unit it might be easier to keep it busy
>and get maybe a 20-30% better utilization.
>
>Also, with two threads already on-chip, the OS might be able to save some time
>on expensive task switches.
>
>
>Bo Persson
>bop2@telia.com



This page took 0 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.