Forgot your password?
typodupeerror

Core Duo - Intel's Best CPU? 305

Posted by Zonk
from the shadow-knows dept.
Bender writes "How good is Intel's Core Duo mobile processor? Good enough that Apple chose to put it in the iMac, and good enough that Intel chose to base its next generation microprocessor architecture on it. But is it already Intel's best CPU? The Tech Report has managed to snag a micro-ATX motherboard for this processor and compared the Core Duo directly to a range of mobile and desktop CPUs from AMD and Intel, including the Athlon 64 X2 and the Pentium Extreme Edition. The results are surprising. Not only is the Core Duo's performance per watt better than the rest, but they conclude that its 'outright performance is easily superior to Intel's supposed flagship desktop processor, the Pentium Extreme Edition 965.'"
This discussion has been archived. No new comments can be posted.

Core Duo - Intel's Best CPU?

Comments Filter:
  • by Sonic McTails (700139) on Tuesday April 18, 2006 @09:45AM (#15148424)
    I have to say the Intel Dual Core Processor is quite impressive. It's fast enough to run just about anything I throw at it, and still keep chugging, but I believe that the article negects the fact that the dual core processor runs extremely hot vs other Intel processor. My old Sony VAIO never got as hot as my MacBook Pro does, and it is something that should be considered.
  • Depends (Score:5, Informative)

    by 2.7182 (819680) on Tuesday April 18, 2006 @09:46AM (#15148432)
    I would argue that the 8080 was. If you normalize for date/speed that is...
  • Even more reviews (Score:5, Informative)

    by adam1101 (805240) on Tuesday April 18, 2006 @09:53AM (#15148511)
    More reviews here [vr-zone.com] and here [extremetech.com].
  • Benchmarks (Score:3, Informative)

    by SilentChris (452960) on Tuesday April 18, 2006 @09:59AM (#15148575) Homepage
    I already posted some benchmarks of a Core Duo Mac Mini running Windows (http://slashdot.org/comments.pl?sid=182379&cid=15 077120 [slashdot.org]) and to be honest I was fairly impressed. The gaming benchmark was obviously miserable, the "general purpose" benchmark (zipping files, encoding audio/video, etcdid very well. The Apple zealots may say "it's because it's a Mac", but really the hardware is almost identical to your average Intel laptop. The only major difference is the Core Duo, which not many laptops have (although that's increasing all the time), and that's what I'm putting my money on. Can't wait to see a benchmark with this thing in a gaming rig.
  • Re:What? (Score:5, Informative)

    by DrDitto (962751) on Tuesday April 18, 2006 @10:03AM (#15148611)
    The reason for going to 64-bits is to increase the amount of physical address space, not for speed. The majority of applications, especially integer, do not benefit from bigger registers and wider ALUs.
  • by phrasebook (740834) on Tuesday April 18, 2006 @10:09AM (#15148661)
    How important is heat, really?

    Heat is a huge consideration to many people, often the deciding factor.

    Assuming that the machine has been engineered sufficiently well to prevent the processor from melting down

    It doesn't matter how well the machine is engineered. If you have hot componentry you'll have a hard time getting rid of the heat without making a lot of noise, especially under load.

    But I never even considered not buying one because of the heat

    What choice did you have? With laptops (especially Apple) you basically take what you can get. There's very little mention of heat or cooling considerations at all.

    And no consideration at all to desktop buyers

    I bought an Athlon X2 solely because it runs much cooler than the P4.

    and in server rooms where it is a consideration... they'll have an A/C system anyway
    The consideration is power consumption. More heat means more power draw means more expensive.

    I doubt Intel is going to lose any customers because their chip gets too hot.

    They lost me in the last round. Thankfully they're finally about to put the P4 to rest and we can get back to the good old P3. I mean, P-M. I mean, 'Core'. Whatever.

    By the way, once you start caring about heat (and you will!) go here for starters: http://www.silentpcreview.com/ [silentpcreview.com]
  • Re:Load of Crap (Score:4, Informative)

    by NCG_Mike (905098) on Tuesday April 18, 2006 @10:13AM (#15148709)
    Our QA department is testing my universal application right now (AppKit based). They've recorded a 20 to 30 percent increase in performance of a 1GB MacBook Pro over a 3GB 2Ghz Dual G5 doing a particular operation (mostly mathematics based done in cross-platform C++). It's single threaded, I might add, since OpenMP isn't here yet. The *ONLY* difference in the XCode settings between the two architectures that I made was to enable SSE3 for the Intel build. I can't believe that it's that alone, of course, and suspect it's just better code gen for the Intel architecture coming out of GCC.
  • Re:What? (Score:5, Informative)

    by Jeff DeMaagd (2015) on Tuesday April 18, 2006 @10:17AM (#15148736) Homepage Journal
    Actually, x86-64 does have some speed benefits over standard ia32 for smaller programs and data sets in that it doubles the number of exposed registers. Most other archs were not register starved on the 32 bit version, so going 64 bit generally slowed the system down a bit because the pointer size doubled, taking more memory bandwidth to store pointers.
  • Re:What? (Score:1, Informative)

    by Anonymous Coward on Tuesday April 18, 2006 @10:23AM (#15148797)
    Amm... working with large numbers sure does benefit from 64bits. For one, multiplying large numbers is at least 3 (yes, three) times faster! Also, Java (that uses lots of "long" types) is also generally 2-3 times faster---as well as Lisp, Haskell, etc.

    Of course, all these speed improvements only happen on the AMD's 64bit architecture---as the Intel's versions only provide the instructions, but still run just as slow as the 32bit version would.
  • by NutscrapeSucks (446616) on Tuesday April 18, 2006 @10:24AM (#15148815)
    There's not a huge difference between Pentium-M and Core Duo due to the dieshrink.

    Pentium-M 2.26GHz 90nm 27W
    Core Duo 2.16GHz 65mn 31W

    Of course, there's low-watt versions of all of these.
  • Re:What? (Score:5, Informative)

    by darkmeridian (119044) <william.chuang@g ... com minus distro> on Tuesday April 18, 2006 @10:25AM (#15148831) Homepage
    Hate to say this, but there are not that many uses for 64 bit processors yet. Manufacturers do not provide 64-bit drivers for their products. The drivers that exist are buggy. To the average Joe, 64-bit is useless. He doesn't need the extra horsepower for his Internet browser or word processor. Well, unless Vista comes out.
  • Re:Load of Crap (Score:4, Informative)

    by nsayer (86181) <nsayer.kfu@com> on Tuesday April 18, 2006 @10:27AM (#15148850) Homepage
    It is not faster than the G5 period!

    It sure the hell is. I have a 2.0x2 G5 desktop machine and one of the new 1.66 GHz Core Duo Mac Minis. Running Handbrake [m0k.org], the mini is easily twice as fast.

  • by Midnight Thunder (17205) on Tuesday April 18, 2006 @10:57AM (#15149158) Homepage Journal
    In a unit like the iMac, where there is plenty of air flow around the case heat is less of an issue, and you are not likely to spend your time with your hand on it. In a portable heat is a big issue, since the under side has zero air flow when on a desk, and on the upper side where heat is going to be noticed your hands are resting, for large amount of time.

    Also, heat can actually reduce the life-span of components.
  • Re:What? (Score:4, Informative)

    by NutscrapeSucks (446616) on Tuesday April 18, 2006 @11:28AM (#15149481)
    The "more registers" with x86-64 has been massively overhyped. There's very little real world benefit.

    For example: AMD's claims about UT2004 being 20% faster in 64-bit mode turned out to be bogus (more like 2%).
  • by uarch (637449) on Tuesday April 18, 2006 @11:55AM (#15149818)
    Yeah, they use both HDL coding and EDA (cad-like) tools to design most microprocessors. The designs are too massive to design them by placing each wire manually - they haven't done that for _several_ generations (1980s? - not sure really)

    That's not to say there isn't a small army of design engineers at Intel and AMD who work with nothing but schematics - there are. Its just that most of the logic design work is done on the HDL coding level (with either VHDL, IHDL, Verilog, or some other tool). You only start dealing with schematics at a much later stage of development. Until then your designs are constantly changing and its infinitely easy/faster to change a few lines of HDL code than to re-write hundreds/thousands of wires and transistors.

    I've worked at both Intel and AMD in the past and in both cases you could take the entire codebase for a processor (HDL, microcode, ROM, etc), compile it with the right HDL compiler and run the entire thing with small test programs as a simulator. Thats how much of the validation/verification work is done before they make the masks.

    As for using the old code bases... That's done a lot. There's just too much complexity and too little time for them to re-write every processor from scratch. You also have countless hours invested in making sure previous designs work. If you're only doing small changes it would be hard to justfy building something from scratch since you'll have to do all of that validation work again.
  • by nikanj (799034) on Tuesday April 18, 2006 @12:30PM (#15150205)
    But laptop heat is a major threat to male fertility. See this article [msn.com] for more details.
  • by Sebastopol (189276) on Tuesday April 18, 2006 @12:39PM (#15150312) Homepage
    But let's not pretend that Intel is winning the benchmarks with this quite yet.

    'Yet' is now.

    Merom/Conroe defeats AMD-AM2 hands down, and AMD has nothin' on the roadmap for the next two years, because AM2 slipped a full 12 months.

    Go surf around Anandtech.com

    AMD is in deep doo doo.

  • Re:What? (Score:2, Informative)

    by AcidPenguin9873 (911493) on Tuesday April 18, 2006 @03:15PM (#15151786)
    x86 processors since the Pentium and the Am586 have more registers than they expose, and when you perform a context switch, they can swap in the other registers, meaning they can cut the time of a context switch down a great deal.

    Register renaming has nothing to do with context switches. The "invisible" registers are used to remove false dependencies in the instruction stream to increase Instruction-Level Parallelsim (ILP) within a single thread. In fact, on a context switch, the architectural state exactly matches the physical state (no "invisible" registers are in use), and so the processor doesn't have to save any extra registers other than the architecturally-visible ones. The details (skip if you're not interested):

    loop:
    movl %ecx, (%ebx)
    # Do something complicated with ECX
    addl $4, %ebx
    cmpl $64, %ebx
    jl loop

    In the above assembly, the instructions are dependent upon one another: you can't execute the incl until after the movl because the incl overwrites EBX. You can't start executing the next iteration of the loop until the current iteration is finished, because the movl at the top of the loop overwrites ECX. These restrictions only arise because you are reusing the registers EBX and ECX. If you could somehow use different "copies" of these registers, you could execute multiple iterations of the loop in parallel, and execute instructions inside the loop out of order.

    Inside the processor, the instruction stream may be seen like this:

    %r0 <- (%r1)
    # Do something complicated with r0
    %r2 <- %r1 + 4
    cmpl $100, %r2
    jl loop

    %r3 <- (%r2)
    # Do something complicated with r3
    %r4 <- %r2 + 4
    cmpl $100, %r4
    jl loop

    ...

    The processor has removed all false dependencies by using its internal, non-visible registers to remap different loop's "instances" of EBX and ECX to different physical registers. This enable out-of-order execution: since the next "copy" of EBX has been renamed to be a different physical register (r2) than the original value of EBX (r1), the processor can execute the addl instruction LONG before it executes the "Do something complicated" portion of the loop.

    This then allows the processor to execute multiple iterations of the loop in parallel (with branch speculation and recovery) by performing the addl instruction very soon after the loop begins, which will allow further iterations of the loop to run by calculating the "next" value of EBX. The processor has effectively performed loop unrolling in hardware.

  • by Senjutsu (614542) on Tuesday April 18, 2006 @03:59PM (#15152159)
    Intel started a mobile CPU revolution with the Pentium M, so it's a little disappointing to hear that its latest successor doesn't improve further.

    Wha?? Did you even glance at the article?

    The Core Solo uses the same power as the Pentium-M to deliver more performance. The Core Duo uses slightly more power than the Pentium-M to deliver a lot more performance. Ergo, the performance per watt figures in both cases are better than the Pentium-M's.

    In what sense, exactly, does the Core (Yonah) series not continue making improvements on its predecessors?
  • Re:Keep in mind that (Score:3, Informative)

    by ciroknight (601098) on Wednesday April 19, 2006 @03:58AM (#15155430)
    The problem is, Intel is way ahead on their 45nm manufacturing process, which could virtually negate AMD's 65nm step. (Intel says they're going to be ready in 2007, which is when everyone expects the new AMD 65nm fab to come online).

    If Intel could get to 45nm before AMD even gets to 65nm, you could kiss any performance gain that 65nm would lend AMD totally goodbye. (There's no telling how likely it is that this could happen, but seeing as both Intel and AMD are putting a great deal of their resources into it, it's anyones guess).

Machines certainly can solve problems, store information, correlate, and play games -- but not with pleasure. -- Leo Rosten

Working...