Slashdot Mirror
Intel Core 2 Extreme QX6700 Quad-Core Benchmarks
Slimpickin writes "Intel gave access to quad-core Kentsfield-based systems to select members of the press at IDF. The embargo has been lifted on a preview of performance numbers with the new 2.66GHz Core 2 Extreme QX6700 processor. HotHardware showcases Intel quad-core performance from a few different angles, from digital video processing and encoding, to 3D modeling and rendering, along with a few of the more standard benchmarks. the new Intel quad-core puts up performance numbers, depending on the application, at nearly double the performance of a 2.93GHz Core 2 Duo processor based system. Core 2 Quad will also drop right into existing motherboards that are compatible with the Core 2 processor line."
A few weeks ago Anandtech already tried to plug two 2.4 GHz Quad-Core Clovertons (Xeons) samples into the new Mac Pro featuring two LGA-771 sockets. Worked like a charm, a nice eight core machine. And since dual socket motherboards are quite expensive, the Mac Pro might even be a cheap version.
memomo: free web based language trainer DE-EN-ES-FR-IT
exactly. i've heard the amd quadcore will excel in memory management and cache efficiency.
Why did everyone told me to rush on Core2 Duo when it got released saying it's the perfect time buying CPU..... now quad core get released a few months after.
I'm reminded of a cartoon I saw years back, where a computer salesman is showing a customer a selection of computers: "Here we have the ones that will be obsolete in 6 months, and over here are the ones that will be obsolete in 9 months."
Thing is, that though Intel is releasing a consumer grade quad soon, they're only releasing the "Extreme" version, which will be their highest-priced CPU. You won't see reasonably priced quads for 4-6 months after the Extreme version hits the supply chain. Unless you're doing hardcore 3d or video, a moderately-priced Core 2 Duo *should* be good enough to handle most of your tasks for the next 2-3 years before you start feeling the irresistable upgrade itch.
- Greg
Start a happiness pandemic
Well that linking format didnt' work: http://www.extremetech.com/article2/0,1697,2021888 ,00.asp
Calling Hypertransport a "kludge" is a stretch. The advantage of Hypertransport with multi-core comes into play regarding access to main memory. All processors can access main memory simultaneously, with theoretical bandwidth actually scaling with the number of processors, rather than being divided among them. It really is better than the FSB, but AMD needs to get kicking with 65 nm and below.
FYI, Kentsfield has 64 bit instructions, and therefore is 64 bit capable. Please stop spouting this "AMD is the only pure 64 bit processor" garbage.
So why does an app or a library have to care how many CPUs or cores the PC has? Surely that's the job of the OS?
Yes and no. Programs can split the hard work across several threads and all of those threads will be managed by the task scheduler regardless of how many cores there are. The hard part is making an algorithm that can split the heavy processing work to multiple threads, that threading has to be programmed. If the program has all the hard work in one thread, then it's not going to use more than 100% of one CPU, 50% each of two CPUs, etc.
Calling either solution a "kludge" is of course wrong. However, just running everything across HyperTransport is an obviously worse approach for core-to-core communication than shared L2. The trick about sharing cache though is that it stops making sense to talk about the cores "sharing access to main memory", since any memory fetches go into the shared cache. Plus that Intel isn't stupid, their current platform has two separate front-side buses, so there is quite a bit of bandwidth to work with.
On the other hand it is of course also true that the HyperTransport approach is perfectly symmetrical and scales to almost any number of processors, so AMD has a good hold on the 8 core and above market.
To elaborate:
Usually, if an application can split its work up into 2 threads, it can split its work up onto n threads (if it's well designed). This isn't
always the case, but it tends to be. The hard part is breaking an algorithm up into pieces, usually not the number of pieces in particular.
So, for example, it could spread its work over 100 threads on a 1-CPU machine. This would be an inefficient use of threads, if they're all doing work. Usually 1 or 2 threads is ideal for a 1-core machine.
Similarly, it could spread over 2 threads on a 4-core machine. This would also be inefficient, since 2 of the cores would be idle.
So, ideally, the program usually should have some way of asking the OS, "how many threads should I run for best efficiency?" In general, the question it really asks is, "how many execution cores are there?" and then it just uses that, or multiplies by 2, or something.
So, the application needs to know how many cores there are as part of its auto-configuration, for performance. Often apps don't auto-configure this sensibly, and just spawn a fixed number. This isn't ideal, since it requires the user to twiddle something for no particular reason.