NetBurst is dead, as are the days of Intel's 31+ stage pipelines, leaving us with a much more power-efficient architecture in the second half of 2006 for all of Intel's microprocessors. From servers to notebooks, Intel's next-generation micro-architecture derived from the Pentium M's architecture is supposed to mark Intel's return to being competitive with AMD in terms of performance.

Not since Intel's Northwood Pentium 4 core has Intel really been performance-competitive with AMD. These days, the majority of Pentium 4s are just not very interesting. They are too hot, more expensive and under-performing compared to their AMD counterparts. And while Intel continues to have the lowest price on an entry-level dual core processor, the rest of their desktop product line is made up of processors that we can't recommend.

Between now and the second half of 2006, Intel does have one last card up their sleeves to send NetBurst to its grave with a proper farewell - the migration to Intel's 65nm process. At 65nm, the cores get smaller, the chips get cooler, and the clocks get higher. However, with Intel's next-generation architecture around the corner, Intel won't take their new 65nm chips too far, as they want to avoid a repeat of the Pentium 4's launch, where the new architecture is outperformed by its predecessor. So, despite what Intel's 65nm process may be capable of, the first 65nm Pentium 4s won't offer any increase in clock speeds.

As we've reported before, the 65nm line still won't break 4.0GHz. Instead, we'll see a re-release of 3.8GHz and slower parts. The tables below describe Intel's current roadmaps for the Pentium 4:

Intel Extreme Edition
CPU Core Clock FSB Mass Production
EE 955 Presler 3.46GHz 1066MHz Q1'06
EE 840 Smithfield 3.2GHz 800MHz Now
EE 3.73 Prescott 3.73GHz 1066MHz Now

Intel Dual Core Desktop
CPU Core Clock FSB L2 Cache
??? Conroe ??? ??? 4MB
??? Conroe ??? ??? 2MB
950 Presler 3.4GHz 800MHz 2x2MB
940 Presler 3.2GHz 800MHz 2x2MB
930 Presler 3.0GHz 800MHz 2x2MB
920 Presler 2.8GHz 800MHz 2x2MB

Intel Desktop Performance Roadmap
Processor Core Name Clock Speed Socket Launch Date
Pentium 672 Prescott 2M + VT 3.8 2MB LGA 775 Q4'05
Pentium 671 Cedar Mill 3.8 2MB LGA 775 2H'06
Pentium 662 Prescott 2M + VT 3.6 2MB LGA 775 Q1'06
Pentium 661 Cedar Mill 3.6 2MB LGA 775 Q1'06
Pentium 651 Cedar Mill 3.4 2MB LGA 775 Q1'06
Pentium 641 Cedar Mill 3.2 2MB LGA 775 Q1'06
Pentium 631 Cedar Mill 3.0 2MB LGA 775 Q2'06
Pentium 670 Prescott 2M 3.8 2MB LGA 775 Now

While AMD just celebrated the grand opening of Fab 36, they are still at a minimum of half a year behind Intel when it comes to 65nm production. Intel's 65nm CPUs have been sent to their partners in preparation for a launch early next year. Of course, whenever anything leaves Intel, whether it is information or a CPU, it's not too hard for us to get a hold of it. And thus today, we're able to bring you a quick preview of Intel's 65nm processors.

We will of course be focusing on performance and competitiveness with AMD parts when these CPUs actually launch, but today, we are focusing on two elements alone: power consumption and overclocking potential. As we said, at 65nm, everything gets cooler and faster, but how cool and how fast are what we are here to find out.

Introducing Cedar Mill and Presler
Comments Locked

43 Comments

View All Comments

  • highlandsun - Tuesday, October 25, 2005 - link

    Core-to-core is extremely important in a lot of multi-threaded applications. Remember that the programming model for threading is that multiple threads share one address space and so have shared access to data. Thread synchronization with mutexes and such requires that all processors have fast access to the mutex variables. As such, core-to-core communication is crucial.
  • Viditor - Tuesday, October 25, 2005 - link

    Thanks highland...some other questions if you could help.
    Do you have any idea as to how much bandwidth would increase for just the core to core traffic during multitasking?
    What effect would increased latency for the core to core have on overall multitasking?
  • JarredWalton - Tuesday, October 25, 2005 - link

    I should also mention that DC could actually be slower than 2P in cases where you have say 2 DIMMs per socket and a UMA-aware OS.

    Here's the real problem, Highland: in theory faster core-to-core speeds are important for SMP code. In reality, mutex and thread synchronization is bad. You don't want SMP software to spend a lot of time waiting to enter exclusive code blocks. In an ideal SMP application, you spend a fraction of time splitting up a task into two equal halves, then you let two cores churn away on those tasks for a relatively long time, and then you spend a fraction of time combining the results/synchronizing. If you're spending a lot of effort on thread synchronization, then you've got a task or algorithm that doesn't work very well for SMP in the first place.

    This is more guesswork and supposition than actual knowledge. If someone has a concrete set of benchmarks that show real-world SMP doing much better (or worse!) on DC vs. 2P, I'd love to hear about it. If you can prove that the faster core-to-core speeds are what leads to better results in a real scenario, I'd like to hear about the application as well. Maybe I'm just not being creative enough, but I'm having a difficult time coming up with a task that's going to do great on SMP and also show a marked improvement on DC vs. 2P. The more independent the pieces of a task are, the better it will do on SMP setups, and conversely the less important core-to-core signaling becomes.
  • highlandsun - Tuesday, October 25, 2005 - link

    Yes, "an ideal SMP application" may allow coarse grained division of labor. That may apply to supercomputing applications, where array/vector operations tend to dominate. That's a good model of SIMD computing, but that isn't the only model that users will run into.

    I think that class of problem is actually pretty rare. More often you need concurrent access to shared data. E.g., a web server with lots of front-end tasks talking to a multi-threaded database server. Since any number of threads may be writing new data while other threads are querying for data, all data accesses must be synchronized. For this class of problem, I expect the AMD design will have a noticable advantage.

    This is significant, because I believe this class of problem is far more relevant in every day use. Think of the filesystem drivers in your OS, the databases behind big search engines like Google, etc., they're all about moderating multiple accessors to shared data. The faster your core-to-core communication, the better you can handle this type of task, and you run into this task every minute that you touch a computer.
  • JarredWalton - Wednesday, October 26, 2005 - link

    There will be a few areas it helps, but I really don't think it will matter much. Most mutex accesses will be a very small fraction of the total compute time. Let's say that in a given second, you have 2 billion operations that a CPU can execute. How many of those will have to do with core-to-core work? If I were to take a stab at a figure, I'd wager that far less than 1% of instructions are going to do that:

    if(checkmutex()) {
    do_massive_subroutine();
    }
    else {
    wait();
    }

    Whatever the actual code is, the semiphore test condition and such are only a few machine instructions. The code that does the work might be thousands or tends of thousands of machine instructions. Basically, I think you'll end up with fine-grained threading benefiting a bit from the faster intercore bandwidth/latency, but it's not going to be an amazing improvement. A synthetic application to test just this "bottleneck" might be able to show a 25% improvement in intercore communication speed, but best case scenario I doubt it will end up being more than 2 to 5% faster in real code.
  • fitten - Tuesday, October 25, 2005 - link

    Yes, the more coarse grained your application is, the better it will do. The more coarse grained your application is, the less synchronization and data sharing between the threads. Fine grained is more synchronization and sharing. The synchronization costs (mutexs and such) can be small compared to the amount of MOESI traffic required when two simultaneously running threads actually work on the same data, that's why you typically try to partition the data across threads so that they share as little as possible (when you can do this, it isn't always possible depending on the algorithms you are using). I've seen benchmarks that supposedly share a bit of data between threads and that's where the dual-cores (AMD) do well compared to the dual socket/single core Opterons because the dual-core MOESI traffic overhead is a bit less than going off-chip. I haven't really seen much from the Intel side of things, though, but I would expect that they wouldn't be too much different from dual-socket/single-core Xeons if their MOESI traffic has to go off chip.
  • Viditor - Tuesday, October 25, 2005 - link

    quote:

    The difference between communications sent over the FSB, through the chipset, and to a separate socket is going to be quite a bit larger than simply splitting the cores

    I'm not so sure...the intercore communication on the split cores goes from the cache of CPU0, through the FSB to the Northbridge, and then back to the cache of CPU1. That's what happens on Smithfield as well...
    The AMD example won't be quite as severe (2P vs DC) because the the intercore comms go directly via the HT link on 2P...
    How much traffic is sent is a very good question, and frankly I have no idea (anyone else have an answer to this?).
  • mino - Tuesday, October 25, 2005 - link

    No, AMD DC's comunicate through CrossBar switch, not via HT link.

    Actually Smithfield was only a temporary measure, it is apparent Intel was able to design single die-multiple cores offering faster than multiple die-single package. Since the main reason for Smithfield is to have DC chips out ASAP, Intel has chosen the fastest route even if it meant it was more expensive. However with Presler Intel had enough time to perfect their Package&Chipset solutions to be able to accomodate 2 chips per package so the have chosen the more economical route this time.

    I also believe the only single reason for 945/955 chipsets to exist was a premature release of PD. Now when Intel finally managed to make a chipset for Presler-like dualchip implementation, 945/955 are for no use except low-end offerings.

    Anyway, IMHO Presler is much more dualchip solution the dualcore. Presler's SMP ability has almost nothing to do with the core itself. It is mostly the packaging& chipset issue exactly as with Xeon SMP implementation.

    As of dualcore products are mostly from K8 family, Power5 family, Power 970 family, Yonah, most future Intel designs and to some extent Smithfield.

    But Presler simply does not belong here.

    Poetically said, Presler is product of the past while DC/MC is the future.
  • mrgq912 - Tuesday, October 25, 2005 - link

    seems like there is lots of news from the intel front these days. People keep expecting intel to answer to amd's processor perfornmance effiency and power. But I don't here about any thing on the amd front. I am sure the gusy and amd are not sitting around waiting for intel to catch up, they must have something new in store besides a 1 more pin on a new socket.
  • GlobalAmityPeter - Tuesday, October 25, 2005 - link

    I have to agree with Lal Shimpi that Intel's imminent CPUs are less than exciting. Progress is always good, but aside from the novelty of overclocking to over 4GHz there isn't much of a draw with CedarMill and Presler. However until AMD manages to make public some plans for innovation beyond new sockets, I think Intel has a good chance at overtaking AMD in the performance realm with slow and steady progress.

    The competition between the two just isn't that hot right now. Hopefully things will get interesting when both copmanies release dual core mobile chips next year.


    http://globalamity.net">GlobalAmity.net

Log in

Don't have an account? Sign up now