Date: Wed, 25 Jan 2006 08:30:21 +1100 From: Peter Jeremy <PeterJeremy@optushome.com.au> To: Ken Gunderson <kgunders@teamcool.net> Cc: freebsd-amd64@freebsd.org Subject: Re: dual vs single core opteron 100's Message-ID: <20060124213021.GY25397@cirb503493.alcatel.com.au> In-Reply-To: <20060124110334.40e81208.kgunders@teamcool.net> References: <20060124110334.40e81208.kgunders@teamcool.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2006-Jan-24 11:03:34 -0700, Ken Gunderson wrote: >I was getting into a discussion the other day about this and decided to >see what the FBSD amd64 gurus had to say about it. Given approximately >equal cost of, for example, a single core Opteron150 (2.4GHz) and a >dual core Opteron165 (1.8GHz) under what kind of situations would >one be preferred over the other? Unless you're running exactly one single-threaded CPU-intensive task, the dual cores would provide greater total CPU power. (As others have pointed out, this may or may not be usable, depending on where the system bottlenecks are). On a server, your virtually always going to have multiple processes competing for resources. Even on a workstation, the Xserver is competing for resources with your application. >fwiw- my friend asserts it will ALWAYS be the faster single core The truth of this statement is highly dependent on exactly what 'it' is. As always, the best benchmark is your own application set. > because of context switches An SMP system should never have more context switches - since you've got multiple processes running simultaneously, you may have fewer. Consider "a|b" - on an SMP system this need never generate context switches because both processes can run (conceptually - in practice there will be other processes so you will get context switches). > and dual cores are optimized for highly multi- >threaded OS's (e.g. WInblows). I don't see how this follows. Dual core is basically the same as having two physical CPUs and it's difficult to see how optimisations for one OS would not help other OSs. (This differs from HTT where the scheduler needed to understand HTT limitations to be able to successfully utilise HTT - and I believe Winbloze did, whereas I don't believe any FOSS did). -- Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060124213021.GY25397>