okay, what i don't get is how the 1.8 ghz or w/e e6300 is clocked so low yet performs so well in the cpu charts? have we left a clock-dependent time period again? is this just intel black magic? i mean, the 6300 isn't actually on there, but the 6400 is, and people say its like the same proc. so whats the deal with that?
Sources:
http://indigo.intel.com/compare_cpu/default.aspx?familyID=1&culture=en-US
http://www.intel.com/products/processor/core2duo/specifications.htm
It is clocked slower than E6600 (
77.77% the clock speed, or 9/7ths as explained below), has half the L2 cache (2048 KB vs 4096 KB), and the same base FSB speed. Power consumption may actually be higher due to cache hit rate being lower (as cache is smaller).
The E6300 is extremely overclockable.
FSB: 266.666 MHz base clock *(Which is quad-pumped so 1066 MHz FSB in marketing materials)
Times CPU Multiplier of:
7 *(For the E6400 this is 8, for 2.133 GHz still with 2 MB cache, For E6600 this is 9, for 2.40 GHz but with 4 MB L2 cache)
=
1.866 GHz
times 1.333 for AMD64 comparisons, Reasons:
{As it has 8/6ths the pipelines of an AMD64 processor and knows how to keep them fed damn well, it also has a larger cache, 2 cores each with 4 pipelines, can execute SSE instructions more than twice as often vs AMD64, and although it has a slower FSB it pre-fetches instuctions/data far more often to reduce stalls so it gets more utility out of its 'slow' 1066 MHz FSB [post QDR], despite claims by AMD fanboys memory latency and throughput is not that important just under-utilized - for whatever reason they never thought to pre-fetch in various ways until recently during R&D efforts -
Prob because x86 is such an ancient architecture and everyone demands backwards compatibility} = Thus it equals roughly a 2.4 GHz AMD64 processor. - Boom, That Simple.
FSB is 'quad-pumped' and the CPU has a multiplier of only 7:
As the FSB/RAM is clocked at more than half (post QDR 'quad-pump' speeds) the speed of the processor (for a E6300, at 1.866 GHz - ), the processor only needs a 42.85%+ cache hit rate to scale performance with prefetching. Thus the smaller 2 MB cache isn't going to impact performance much on the E6300.
Beyond multipliers of 8-9 CPUs typically have more cache, which is what makes the E6600 so damn good, it is only 9/7ths faster, but has double the cache, so it
[E6600] has the best cache hit rate of the entire Core 2 Duo line. It also overclocks very well and is priced well - These are the primary key reasons why I recommend the Core 2 Duo E6600 over both, the faster, and the slower ones. It is just balanced better technically speaking.
Keeping processor core speed 'nearer' to FSB speed is actually a damn smart idea, it boosts cache hit rate heaps (via pre-fetching), reduces pipeline stalls.
Just picture a bunch of bike chains / belts of various lengths, and at various rpm, carrying 'code and data' - Sort of makes sense now, right ?
It is all IPC
Instructions Per Clock-cycle
www.sun.com has some decent articles on it.
The Sun Microsystems 'CoolThreads' (UltraSPARC based) processors / systems. A few consumer style pages for you and tech links if you're interested in how it all 'really works'. (Concepts are applicable to any platform too).
Specifically: (No AMD / Intel fanboy bias here, as the architecture I am using as an example is UltraSPARC based :lol: )
http://www.sun.com/processors/UltraSPARC-T1/
http://www.sun.com/servers/coolthreads/t2000/
Oh and:
http://opensparc-t1.sunsource.net/
- the actual processor architecture is now 'Open Source', except that it is hardware. Freaking crazy :? , or freaking crazy awesome ? 8)
It always has been:
- IPC
- Vector / Array processing (MMX, SSE2/3/4+, AltiVec, etc)
- Registers (more broad than it sounds)
- L1 cache size and hit rate
- L2 cache size hit rate
- L3 (ditto)
- Front Side Bus
- Processor Socket to Processor Socket Interconnect performance
- Aggregation of resources (RAM throughput / buses) to boost utility and performance
- etc
A processor clocked at 10 MHz could beat one clocked at 10 GHz, if it was over 1000 times as efficient (especially because the FSB and RAM would run at 100 times the speed of the core, keeping hit rates very high, core counts very high, and complexity + power consumption per core very low).
Point is the RAM/FSB would be fast enough to feed 100 to 800 such 'micro cores' depending on the software and cache hit rates. (In this case 800 cores would require a constant 87.5%+ cache hit rate in all software to scale well... damn well... 8) - And yes this can apply to games. 8O -
Welcome to the Tabrisian, Dark, Peaceful, 'absolute potential' side of computing.
Most software would prob want around 320 cores in the above case though, not 800
, As such a 'much reduced' cache hit rate of only 68.75% would be required to keep them all scaling near absolute potential. Which is easy to achieve in game software benchmarks even with smaller caches.
But, of course, you'd still want 1-2 'general purpose' cores for single threaded apps that need heaps of CPU time during the transitional period.
It is a 'change' in thinking, but this is how it has always been.
(Look at the history of CPUs other than x86/x64, such as IBM / Motorola [Apple, Sony PlayStation 3, etc], Sun Microsystems, SGI, Alpha / DEC / Compaq / HP, and others).
The industry is much bigger than x86 and typical consumer thinking.
:idea: Wait until you read about STREAM processing - around April 2007 (next year) - It'll open your mind. 8O (
Why do little things +5% to +42% better year over year [?], When you can just make hardware take 20 to 200 times the inputs, process them, and output results hundreds of times per second [!] - Has massive applications in computer games, computer science, biological sciences, business collaboration, simulation, etc)
"If you disagree with my vision for the future, speak now, or forever hold your peace"
- TabrisarkPeace
:arrow: PS: I know it is a round about way of saying it, but at least it fits on 1 x A4 page (not 100+ pages of TechDocs, WhitePapers, etc you wouldn't read), but I... HATE... SAUERKRAUT... I mean "I hate advertising hogwash". - Sorry it was the only way to answer the question in full. By directing him away from Intel / AMD 'Advertising Techs', 'Sales Assistants' and even 'Google searches, as Google only finds what people publish to the net and if 85%+ of people publish crap... well 'Google Searches, Google Finds' :lol: - You are far better off reading Sun T2000 'overviews', OpenSparc / SunSource, etc 'cuz 60 minutes there is like a year somewhere else.