From owner-freebsd-questions@FreeBSD.ORG Sat Mar 26 22:33:07 2005 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D930316A4CF for ; Sat, 26 Mar 2005 22:33:07 +0000 (GMT) Received: from imo-d03.mx.aol.com (imo-d03.mx.aol.com [205.188.157.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4866B43D4C for ; Sat, 26 Mar 2005 22:33:07 +0000 (GMT) (envelope-from EM1897@aol.com) Received: from EM1897@aol.com by imo-d03.mx.aol.com (mail_out_v37_r5.33.) id n.92.23918b0a (16097) for ; Sat, 26 Mar 2005 17:33:02 -0500 (EST) Received: from mblk-r28 (mblk-r28.mblk.aol.com [152.163.179.18]) by air-id11.mx.aol.com (v104.18) with ESMTP id MAILINID111-3ee14245e31e324; Sat, 26 Mar 2005 17:33:02 -0500 Date: Sat, 26 Mar 2005 17:33:02 -0500 Message-Id: <8C7006AE7E80573-FAC-3B652@mblk-r28.sysops.aol.com> From: em1897@aol.com References: <1641928994.20050326192811@wanadoo.fr> <8C700529A2DFD74-A44-3A157@mblk-d34.sysops.aol.com> <439876144.20050326220638@wanadoo.fr> Received: from 24.47.89.83 by mblk-r28.sysops.aol.com (152.163.179.18) with HTTP (WebMailUI); Sat, 26 Mar 2005 17:33:02 -0500 X-MB-Message-Source: WebUI X-MB-Message-Type: User In-Reply-To: <439876144.20050326220638@wanadoo.fr> X-Mailer: AOL WebMail 1.0.0.11984 Content-Type: text/plain; charset="us-ascii"; format=flowed MIME-Version: 1.0 To: freebsd-questions@freebsd.org X-AOL-IP: 152.163.179.18 Subject: Re: hyper threading. X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2005 22:33:08 -0000 Yes, the theory is very nice; you've done a nice job reading Intel's marketing garb. However if you don't have a specific hyperthreading-aware scheduler and particularly well-written, threaded applications, you'll lose more than you'll gain. Since FreeBSDs network stack isn't particularly well threaded, nor is the scheduler optimized for hyperthreading, you get a big mess at the kernel level. So if you have a nice application that does a lot of threaded math operations, you might think you've achieved something, But what you've missed is that the overhead to manage the "better utilization" of the dual-pipelines created by HT costs more than it gains. Hence, the loss of performance. The poblem is not at the application level, but at the kernel level. The SMP overhead is so substantial, and the OS is working thinking it has 2 processors, that process switching and interrupt handling slow down considerably. A machine with a 50% load UP will run 65-70% load with HT/SMP running. Like I said, its easily measurable. Thats at the kernel level (say routing or bridging performance). Now if the machine isn't a server, it may be just fine. Thats why I suggested testing. But for a network server HT is bad. Very Bad. Not only that, but FreeBSD 5.x actually has a higher capacity network-wise with 1 processor than 2, and I'm sure you can theorize why 2 processors should be faster than one. The theory only matters if you have well written code to handle it properly. FreeBSD is a long way off from that. -----Original Message----- From: Anthony Atkielski To: freebsd-questions@freebsd.org Sent: Sat, 26 Mar 2005 22:06:38 +0100 Subject: Re: hyper threading. em1897@aol.com writes: > You'll get much better performance with 1 processor in > UP mode. I suggest you do some testing. Where can I see the results of your own exhaustive tests? The purpose of hyperthreading is to keep all hardware on the microprocessor working. Many instructions use only certain parts of the chip, leaving other parts idle. By allowing two execution contexts to be maintained simultaneously, hyperthreading makes it possible to better utilize hardware that might otherwise sit idle. The ideal case would be two threads executing completely different instruction sequences that use very different parts of this chip. I don't have exact figures but I'd guess that in ideal situations you might get 20%-30% extra out of a single processor in this way--enough to negate the greater overhead of the SMP logic. A situation in which hyperthreading would _not_ help would be any type of parallel processing, in which multiple threads execute very similar instructions. These instructions are likely to require the same parts of the microprocessor at the same time, so it's unlikely that they will be able to execute in parallel--one will have to wait for the other (because the microprocessor has logic areas that can function independently and simultaneously, but these areas don't do the same things, so they are not redundant logic). -- Anthony _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"