Date: Wed, 22 May 2002 11:44:13 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Alfred Perlstein <bright@mu.org> Cc: "Dorr H. Clark" <dclark@applmath.scu.edu>, freebsd-smp@FreeBSD.ORG Subject: Re: hyperthreading: myth or legend? (was Re: hyperthreading? (was Re: question)) Message-ID: <3CEBE6FD.626DC5DD@mindspring.com> References: <20020514222840.GB1585@elvis.mu.org> <Pine.GHP.4.21.0205220940410.28331-100000@hpux38.dc.engr.scu.edu> <20020522172759.GV54960@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > * Dorr H. Clark <dclark@applmath.scu.edu> [020522 09:58] wrote: > > I don't have access to a fancy Xeon, I just have > > a PIII dual-banger, so I'm relying on the list traffic. > > To summarize the past two months: > > > > On Thu, 14 Mar 2002, John Baldwin wrote: > > On Thu, 14 Mar 2002, Terry Lambert wrote: > > On Tue, 23 Apr 2002, FiberOps wrote: > > On Tue, 23 Apr 2002, John Baldwin wrote: > > On 23-Apr-2002 FiberOps wrote: > > > > This final message was not followed up except by me, > > although someone else informed me that while the CPUs > > launch, FreeBSD can't run processes on them. > > > > So I thought I'd try to stir up an answer to the original question: > > > > For the latest Xeon motherboards, does FreeBSD 4.x stable > > support hyperthreading? If not, does the current TOT? > > If not, why not? Is gcc an issue or not? If gcc is an issue, > > would this be an obstacle for all gcc-based OSes, > > not just FreeBSD, most prominently among these Linux? > > > > Clear answers gratefully appreciated, > > I'm glad you chose to take the word of a couple of people > that have never used a hyperthreading board above what I've > already told you. > > Here's what I know: > The additional CPUs probe. > > A benchmarking utility reports equivelant performance to a 4 way > machine. According to the Intel documentation I read, hyperthreading is not the same thing as simply having the extra CPUs on the same die (which is what you seem to be implying it is). Here is the reference: http://www.intel.com/design/Xeon/Whitepaper/WhitepaperNBHT.htm Unfortunately, the other references are the victims of a broken CGI right now (the compiler references from me, quoted in his posting). As a summary: o You must specifically set the thread stack base in order to optimize performance (FreeBSD does not do this) o You need explicit scheduler support to distinguish between logical and physical processors (FreeBSD does not do this; not really a big relative loss, since FreeBSD also does not support SMP CPU affinity, so there's no reason for stronger affinity between logical CPUs within the same CPU) o Threaded programs should be built by a compiler which is cognizant of the L1 cache effects, such that there are not pipeline stalls -- roughtly equivalent to the instrcution reordering optimizations in the DEC Alpha compiler (FreeBSD's compiler does not do this) o Code co-units need to have their code generated interleaved so that they can be co resident in the single L1 cache, without flushing stalls when simultaneously operating two or more logical CPUs (FreeBSD's compiler does not do this) o Inter-logical CPU locking can deadlock, unless you pipeline your spinlocks (FreeBSD locks are heavy weight) o Use of the PAUSE instruction is required to delay operations without effecting other logical processors (FreeBSD does not do this) See also the "Intel Pentium 4 and Intel Xeon Processor Optimization Manual" (that's the one that Intel's CGI script complains about right now) and http://cedar.intel.com/cgi-bin/ids.dll/topic.jsp?catCode=CDN . -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CEBE6FD.626DC5DD>