From owner-freebsd-questions@FreeBSD.ORG Sat Feb 10 20:16:38 2007 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5006F16A401 for ; Sat, 10 Feb 2007 20:16:38 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 2E73213C442 for ; Sat, 10 Feb 2007 20:16:38 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141] (may be forged)) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l1AKGbvY022023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 10 Feb 2007 12:16:37 -0800 X-Auth-Received: from [192.168.10.41] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id l1AKGaeW011908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 10 Feb 2007 12:16:37 -0800 Message-ID: <45CE281C.20902@u.washington.edu> Date: Sat, 10 Feb 2007 12:16:28 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.9 (X11/20070122) MIME-Version: 1.0 To: freebsd-questions@freebsd.org References: <935627.87795.qm@web34514.mail.mud.yahoo.com> In-Reply-To: <935627.87795.qm@web34514.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.10.120434 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Dual Core Or Dual CPU - What's the real difference in performance? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2007 20:16:38 -0000 Nicole Harrington wrote: > --- Cy Schubert wrote: >> In message >> <142261.76672.qm@web34514.mail.mud.yahoo.com>, >> Nicole Harrington >> wri >> tes: >>> --- Cy Schubert wrote: >>>> In message >>>> <17866.47828.219523.71972@bhuda.mired.org>, Mike >>>> Meyer writes: >>>>> Generally, more processors means things will >> go >>>> faster until you run >>>>> out of threads. However, if there's some >> shared >>>> resource that is the >>>>> bottleneck for your load, and the resource >> doesn't >>>> support >>>>> simultaneous access by all the cores, more >> cores >>>> can slow things >>>>> down. >>>>> >>>>> Of course, it's not really that simple. Some >>>> shared resources can be >>>>> managed so as to make things improve under >> most >>>> loads, even if they >>>>> don't support simultaneous access. >>>> Generally speaking the performance increase is >> not >>>> linear. At some point >>>> there is no benefit to adding more processors. >> In a >>>> former life when I was >>>> an MVS systems programmer the limit was seven >>>> processors in a System/370. >>>> Today we can use 16, 32, even 64 processors with >> a >>>> standard operating >>>> system and current hardware, unless one of the >>>> massively parallel >>>> architectures is used. >>>> >>>> To answer the original posters question, there >> are >>>> architectural >>>> differences mentioned here, e.g. shared cache, >> I/O >>>> channel, etc., but the >>>> reason the chip manufacturers make them is that >>>> they're more cost effective >>>> than two CPUs. >>>> >>>> The AMD X2 series of chips (I have one), they're >> not >>>> truely a dual >>>> processor chip. They're analogous to the single >>>> processor System/370 with >>>> an AP (attached processor) in concept. What this >>>> means is that both >>>> processors can execute all instructions and are >> just >>>> as capable in every >>>> way except external interrupts, e.g. I/O >> interrupts, >>>> are handled by the >>>> processor 0 as only that processor is "wired" to >> be >>>> interrupted in case of >>>> external interrupt. I can't comment about >> Intel's >>>> Dual Core CPUs as I don't >>>> know their architecture but I'd suspect the same >>>> would be true. Chips in >>>> which there are two dual core CPUs on the same >> die, >>>> I believe one of each >>>> of the dual core CPUs can handle external >>>> interrupts. >>> Wow I love ansking questions without too many >>> specifics as I learn so much more. With this >> however >>> it really seems to be a love hate relationship >> with >>> dual core. >>> >>> Based on what you stated above, would that mean >> that >>> when using a dual core system, using polling >> interupts >>> might be better or perhaps monumanally worse? >> No. CPU 0 would be interrupted. It would schedule >> the interrupt in the >> queue. Either CPU could service the interrupt once >> the interrupt was queued. >> >> Some devices need to be polled as they do not >> generate interrupts or they >> generate spurious interrupts. Otherwise allowing a >> device to interrupt the >> CPU is more efficient as it allows the CPU to do >> other work rather than >> spinning its wheels polling. This is the Von Neumann >> model. >> >> >> -- >> Cheers, >> Cy Schubert >> FreeBSD UNIX: Web: >> http://www.FreeBSD.org >> >> e**(i*pi)+1=0 >> > > Yes, I have heard that, thanks. > > However, how does one know or tell which is the > right mode/model for which devices? I have seen people > on either side (poll vs interupt) claim one is better > or much like an infomercial, just do blah and your > system will be so much faster. Altho of course that > would be the pro polling side, since by default, > interupts are used. Is it all just imperical testing? > Take this pill and see let me know how you feel? > > It seems as though when it's heavy networking, use > polling. Otherwise stick with interupts. I have even > heard when using X network card, use polling. How > would know when one card will do better with polling > while another may not? > > > Thanks for helping me understand the debate better. > > Nicole Nicole: If you're doing something regularly, no matter what the task, polling is the better method. Interrupts are for cases when you do something occasionally, but not all the time over your clock cycle. It's really dependent on the situation and the use of the software, for when interrupts are better than polling. Not sure how AMD does it over Intel, but different things are done in different ways in either chipmaker camp, so interrupts may be better with AMD, than with Intel (I'm just thinking pipeline length because Intel's always had long pipelines in their processors). Anyhow, best of luck deciding with method is better, although depending on your situation it probably doesn't matter all that much, esp since there are other limiting factors in the system like bus speed, harddrives, chipset speed, etc. Just basing the factors off CPUs is a bad way to go as it's not a complete analysis. Cheers, -Garrett