Author: Robert Hyatt
Date: 19:39:53 11/09/02
Go up one level in this thread
On November 09, 2002 at 08:02:46, Jeremiah Penery wrote: >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. Yes... but that is a "core" issue. The two threads each have their own unique eax, ebx, etc. One thread has them renamed to one group of core registers, the other obviously must have them renamed to a _different_ set of the core rename registers... > >>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 far as I know, that is correct for all architectures that do register renaming. IE for intel, any instruction that has a destination mov eax, mem lea eax, label Etc, each of those will result in a rename (that is not intended to be a useful snippet of code, just examples of instructions zapping the value in eax which renames eax to a new rename register so that it won't interfere with previous results using the old eax value. > >>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.