--- Gleb Natapov <[EMAIL PROTECTED]> wrote: > On Wed, Dec 27, 2006 at 04:13:00PM +0100, Arjan van de Ven wrote: > > The original p4 HT to a large degree suffered from a too small > cache > > that now was shared. SMT in general isn't per se all that different > in > > performance than dual core, at least not on a fundamental level, > it's > > all a matter of how many resources each thread has on average. With > dual > > core sharing the cache for example, that already is part HT. > Putting the > > "boundary" at HT-but-not-dual-core is going to be highly artificial > and > > while it may work for the current hardware, in general it's not a > good > > way of separating things (just look at the PowerPC processors, > those are > > highly SMT as well), and I suspect that your distinction is just > going > > to break all the time over the next 10 years ;) Or even today on > the > > current "large cache" P4 processors with HT it already breaks. > (just > > those tend to be the expensive models so more rare) > > > If I run two threads that are doing only calculations and very little > or no > IO at all on the same socket will modern HT and dual core be the same > (or close) performance wise? > Hi Gleb, this is a real interesting question. Ganglia is coming [originally] from the HPC side of computing. At least in the past HT as implemented on XEONs did help a lot. Running two CPU+memory-bandwith intensive processes on the same physical CPU would at best result in a 50/50 performance split. So, knowing how many "real" CPUs are in a system is interesting to us.
Other workloads (like lots of java threads doing mixed IO and CPU stuff) of course can benefit from HT. Cheers Martin ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/