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. -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
