You want a comment on the vile piece of trash?
And I'm saying this from a centrist viewpoint. First of all how can a processor be made to give benchmarked applications a boost? If the processor gives the applications a boost under a test, testing the application then it will undoubtably give the application a boost when performing it's normal routine duties.
Synthetic benchmarks aside, Core 2 offers a compelling performance boost. It's noticeable even when just running Windows (especially VISTA) over AMD's Athlon64 X2 processor.
The entirety of this article with it's assumption that Intel's Core 2 is made to just look good under benchmarks seems like a conspiracy theory of the grand scale. If an apple, looks like an apple, tastes like an apple and it's DNA is that of an apple then by all accounts it is an apple. This nut is trying to tell us it's an Orange.
A few Facts that most readers understand. They are that...
1. Intel's Process technology is superior to it's competitors
2. Intel's Caching technology is also superior and plays a large role in the performance of C2D, particularly when running in Dual Core mode and having the Cache Shared.
3. Intel's SSE performance is second to none.
4. Intel's Integer performance is faster per clock then it's current competitor's AMD.
Now.. how to explain. Simple. Intel's Architectures have one flaw. They're based on an older communications bus known as the Front Side Bus. Particularly, one can see the deficiency of this older technology with the performance of Intel own Celeron style Core 2 processor the Conroe-L. It is both the cache that keeps this processor from performing as well as it's front side bus speed.
Let me explain for the Sharikou-style folks.
No doubt having 512KB of L2 cache does impact performance. But another great limiter is the 800MHz FSB. To explain this takes great patience but I will try. Core 2 Duo's have a 1066MHz Front Side Bus shared between both Cores. One would assume this means each core shares it in half. This is false. Core 2 Duo's cores make use of the shared Cache (a rather large pool at 4MB) to send and receive data (between both cores). This is used as a communications bus between both cores (The cache) therefore the entire C2D has ~ 1066MHz to play with (8.5GB/sec) as both cores do not need access to the FSB at the same time. You see the Core 2 Duo is a TRUE dual core processor. Whenever the C2D needs to communicate with the system it has a full 1066MHz bus to do so with as all the rest of the information is shared via tha cache. With Conroe-L you have a problem. For one, the FSB is decreased to 800MHz (6.4GB/s) and secondly it's Cache is striped down to 512KB (1/8th that of Core 2 Duo). Taking into account that the Cache is 1/8th and the performance drop is around 40% one can extrapolate that the Athlon64 (K8) architecture that suffers a 10% decline when the Cache is halved would suffer a 30% performance hit if the cache were 1/8th itself.
The remaining performance hit? Simple, K8 has hypertransport, Conroe-L has an 800MHz front side bus. Hypertransport is slower then the shared caching mechanism that C2D get's to use but faster then the simple FSB clocked at 800MHz that Conroe-L is stuck with.
I would assume a 30% reduction in performance of Conroe-L due to caching size and the remaining 5-10% being due to the smaller FSB.
The problem is that people are viewing C2D as Two cores on one package when in fact it's a single processor with two cores. a Dual Core Processor. Because the Cache is shared you can fully compare to a single core processor on a 1:1 basis and not 2:1.
Athlon64 X2 cannot. It is not a Dual Core Processor. It's a Dual Processor system one a single package that communicates with one another using a hypertransport link. No Cache is shared between both so they're in fact two seperate processors with an HT link between them.
Facebook
Twitter
Instagram