Dual-Core and Quad-Core performance question

Steve Phillips steve at focb.co.nz
Tue Feb 26 04:22:49 UTC 2008


Burke, Thomas G. wrote:
> I can't talk about the diffwrent systems specifically, but I can say this:
> 
> 1). The multi-core systems should be slightly faster that the multiple single-core systems.  This is because the big bottleneck is "getting on the bus.". Memory access times for shared memory resources will be required to go out to main memory, which runs at approx 1/8 the speed of the processor.  This, of course, assumes that the data gets held in a common location, and the programs looking at that common location actually need that data.  Wh( the speed difference might be mosrt likely depends on the applicatron(s)
> 
> 2). Speed p-up over a single core/processor - if the appplication is written to take advantage of multiple processors, the speed-up should be pretty good, but less than 100%.  If the process is a single-processor architecture, 25% or seems about right.  This is because the OS will run on one CPU/core and parse out tasks to the CPU/core with the most available resources.  Thus, on a dual-core system, the program may get 100% of the resources on 1 core while the OS resides on the other.  If the process coul support multiple execution threads, one of those might be on an otherwise empty processor, burt the other mustr share resources with the OS.  With 3 processors, say, a single-stringed app would see the same (maximum) speedup as with the dual-core system, but a multi-threaded system might see as much as 200%, but less than 300% speedup.
> 
> This all assumes, of course, that memory latencies and such don't overwhelm the gains from having multiple processors - at some point there becomes a point of diminishing returns.

Actually, it's been an accepted fact for a while that Physical dual chip 
systems tend to out perform dual core systems in general, infact, Oracle 
adjusted its pricing quite a few years ago when Sun came out with some 
of the early dual core CPU's to '0.75% of a real physical chip' and have 
since re-adjusted to 25% of a real T1 processor (a type of SPARC CPU) 
and 50% of a real AMD processor, and 75% of 'other sun processors'

While this is just an indication of a products pricing, a lot of the 
logic behind it was due to performance drops that customers were seeing 
when comparing dual core systems to multiple single core systems, and 
oracle charging licence fees based on a 'per cpu' count, and 
subsequently charging a second core as if it were '100% of a second 
physical CPU' - there are a bunch of whitepapers out there that discuss 
some of the limitations and advantages of one over the other, and 
surprisingly, the 'bottleneck' argument issues in point 1/ above is more 
true for 'dual core' systems than single CPU systems where each CPU has 
its own dedicated bus. Some of these figures however only come into 
effect when a system is heavily CPU bound (in these cases a physical 
separation will tend to have more advantages) and it is entirely 
dependant on what applications you are using and what system you 
purchase, as well as your budget.

For the most part, the difference is negligible and if I were you, I'd 
go with the cheaper option, which tends to be dual/multi core CPU's over 
single discrete components.

-- 
Steve.




More information about the redhat-list mailing list