Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Intel

Intel's Big Chip 282

Posted by CmdrTaco from the not-so-micro-after-all dept.
DeadBugs writes "News.com has an article about the size of the upcoming revision for the Itanium. The "McKinley" chip will be 464 square millimeters which would make it one of the largest ever produced. Most of this is due to the 64 bit registers and 3MB of Level 3 Cache. There is also a link to an article about "Chivano" an Itanium which will include concepts from the Alpha architecture"
This discussion has been archived. No new comments can be posted.

Intel's Big Chip More

Intel's Big Chip

Comments Filter:

  • Wow! (Score:2, Insightful)

    by JoeLinux ( 20366 )
    Intel gets it right! Morce_Cache==Good_Thing. Was anyone else scratching their head over the 8k of level 1 cache on the Pentium 4?

    Joe

    • It's how you use it (Score:4, Interesting)

      by ouija147 ( 467204 ) on Monday February 04, 2002 @04:04PM (#2951839)
      Way back when the 386 was hot stuff there was a series of mother boards that had a 64K of cache that was outperformed by a board that had 16K of cache.

      How? The 16K board cache was four way set associative. This allowed for the CPU to determine in one clock cycle if the next instruction was in cache. The 64K cache design could not always do this. Thus it was often slower. Why not make the 64K cache 4 way set associative? Cost. The overhead in silcon and motherboard space made this impossible at the time.

      • Re:It's how you use it (Score:2, Informative)

        by Anonymous Coward
        That's not what set associativity means, although you're quite correct that 16Kb of 4-way sa cache will usually be better than 64Kb of direct mapped cache.

        If you actually want to know what you're talking about, I'd suggest reading "Computer Organization and Design : The Hardware/Software Interface" by Patterson and Hennessy.

        • For those who don't know, n-way set associativity means that a cache can retain n values that map to the same cache line, so a 4-way cache can hold 4 lines that map to the same cache position.

      • Actually, given otherwise equivalent designs, a 4-way set associative cache is going to be slower (in terms of maximum access frequency) than a direct-mapped cache. Thus the assertion that 4-way associativity allowed the cache to be accessed in one clock is false. Maybe some other engineering feat allowed them to do this, but it wasn't associativity (because that hurt, not helped).

        But as far as overall performance, yes I'd be willing to bet that the 4-way cache beat the larger 1-way.

    • Re:Wow! (Score:2, Funny)

      by Sinfamous ( 522772 )
      /me looks over at the powermac's 1ghz dual G4's with 2MB cache each already selling. /me shrugs. nothing to see here.

    • Re:Wow! (Score:2, Interesting)

      by pagercam2 ( 533686 )
      Well more cache is a good thing an unmamafacurable chip or an overly pricey chip is really bad. The yeilds on a 464 sq mm chip will be really low, thats 21.5mm on a side assuming a square die and they ussually are. 25.4mm=inch means that this is very nearly a square inch. I'm working on a 10mm x10mm chip now and we expect a ~40% yeild just due to area. SRAM is twice as likely to fail as general logic so large caches L1 or L2 just go to reducing yeild. The larger the chip failures go up exponentially. An example of this would be you wanting to make a table out of pine so you go to the lumber yard and buy some wood, you get what you get and some pieces have wholes or knots that would ruin you table so you toss those. If you make a small table you may be able to get the table by avoiding the knots, but as the table gets bigger your ability to find a good full size peice deceases to the point that every peice of wood has at least one knot so you can never make a knot free table. If you get 20 defects per wafer and you only get 50 die per wafer you will probably get 30 chips (60% yeild) if your die increase to 30 per wafer you may only get 10 (33% yeild). If the die grows to 20/wafer you may get none (0% yeild). All wafers cost pretty much the same so yeild*wafer cost pretty much sets the cost, the lower the yeild the higher the cost. HP has done some interesting work in making chips with extra resources, such that problems can be avoided, route around the defect, they are quite a ways from making this work but this is probably what the future of silicon is going to look like. The other big factor in cost is testing and the more complex a chip the longer the test, its getting to the point that testing costs are out weighting silicon costs, so a self repair chip can help both yeild and testing issues.
      • You are basically right about exponetial drop in yield as area goes up. Some of your calculations do miss the mark however as you assume uniform distribution of defects instead of the more realistic random distribution.

        What intel (and any sane manufacturer who drop a significant amount of memory on die) will do is to add redundancy to regular structures. The l3 cache _will_ have redundancy, l2 most likely. l1 is more of a toss-up.

        Redundancy is currently a standard engineering practice (Actually, most designs use IP modules bought from specialiced memory vendors who can integrate this kind of functionality for you).

  • big chip... big fan (Score:3, Insightful)

    by Transient0 ( 175617 ) on Monday February 04, 2002 @03:48PM (#2951725) Homepage
    i wonder if the oversized chip will lead to particular cooling difficulties(i.e. standard fans and heatsinks can't cool the entire surface area)...

    • Re:big chip... big fan (Score:3, Funny)

      by Anonymous Coward
      Nope. I'm already moving on this issue, with the assistance of several eager venture capitalists.

      We're going to start up a business modifying Sears deep freezers, providing a means of placing a PC directly into it.

      Although your entire computer system will be the size of a bathtub and double your electric bill, you WILL be able to use PC's based on these new CPU's.

      We're also going to figure out how to work rain forest defoliation into the process.

    • Re:big chip... big fan (Score:4, Troll)

      by fobbman ( 131816 ) on Monday February 04, 2002 @04:13PM (#2951900) Homepage
      Actually, according to this article [theinquirer.net] over at The Inquirer [theinquirer.net] Intel can now demo a 5GHz chip using the .13 micros process that can run at room temperature. That'd be interesting to see in action if it benches as well as a 5GHz chip should in comparison to current chips.

      • Intel can now demo a 5GHz chip using the .13 micros process that can run at room temperature.

        Big deal. It has 12 instructions, is ~2mm^2, and consumes 267mW. This looks more like research than something that you would use for real work.

  • Die size war? (Score:5, Funny)

    by Guitarzan ( 57028 ) on Monday February 04, 2002 @03:51PM (#2951746)
    Is this the start of the manly "Mine is bigger than yours" battle?

  • Nice review. (Score:2, Informative)

    by Psmylie ( 169236 )
    Another analyst said, "Jesus, that's big."

    Straight and to the point. Nice.

  • Our new CPU is so big it will CRUSH the competition... No, really. We mean it quite literally :)
  • if Pentiums cost $50 to produce, will these cost 6x as much as a Pentium?

    hmmm... sorry Intel, I'll stick to AMD till I hit the lotto, or have some other good reason to spend money like it was going out of style.
    • This chip ain't for you or me. It's for big datacenters with processing requests that boggle the mind. Kinda like the Xeon processors.
      • processing requests that boggle the mind.

        like if you wanted to play Q3 in a VMWare session?

        (or play D00M 3 at all)
      • And this justifies the mark-up HOW exactly?

        Going from $300 to $3000 per processor at retail seems a bit extreme if you ask me. And don't mod this as a flame, I actually LIKE Intel's work, but it's a joke how much they charge for their processors compared to how much it costs to make them.
        • Well, those chips have to be designed for instance, and since the numbers are low there's lots of markup just for that. Then there's the bad yields due to the big die-size, and marketing and the other kind of expenses a company has to pay just to survive, such as office space, computers, secretaries, Microsoft software, Linux softwa^H^H^H^H^H^H^H^H^H, etc. A company which just re-sells its employees' work has often a markup of 50% just for these things. Then there's the manifacturing plants' mortage (you know, a silicon manifacturing plant costs a few billion euros), and you see how it stacks up quite fast..
          • One would assume that the $300 cited for manufacture would INCLUDE such things as R&D and Administrative expenses. Otherwise, you're not really telling people how much they cost. (And this is really besides the point-- the things you list, while accurate for a startup, don't really apply to a company like Intel with a lot of cash to burn on innovation). I'm still missing the justification of those rather large prices.

  • L3 on die? (Score:2, Interesting)

    by Soong ( 7225 )
    Sounds silly to me. By the time you get out to the 3rd level of cache, on a 1GHz core, there should be enough slow down that chip to chip interconnect will be adequately fast.

    Either Intel has actually put research into this and discovered that it's a good tradeoff performancewise, or they've still got marketing driven engineering and someone said "wow! over 3 MB of on chip cache!"

    Any guess on the wattage? Has Intel broken 100 Watts on their upward march of hot chips?
    • Eventually you'll have 128MB of DRAM on chip. Why? Because it'd be faster. Closer memory is better.

      Having the L3 on chip makes the same amount of sense as having the L2 on chip -- which is to say, lots. First, you can run the L3 at core clock speeds. No external bus is ever going to run as fast as pure silicon. This means that the latency is going to be much lower than for an off-chip L3. This means the average memory access time will be lower, which means better performance. Second, the bandwidth can easily be higher, since you don't have to pay with pins for extra data lines and, again, you're running at core speeds.

      For those programs whose working sets fit into this amount of memory, the on-chip L3 is going to blow the doors off an otherwise equal off-chip L3.

  • Note, this is the *DIE* size (Score:4, Informative)

    by jaxdahl ( 227487 ) on Monday February 04, 2002 @03:55PM (#2951777)
    The Athlon chips i have are around 2-2.5 inches on a side, however, the die in the middle is quite small, i'd estimate it it be 200-250 square mm, so a 400+ square millimeter is huge, compared to that.

    Anyone have any exact numbers for the chips? I didn't get a ruler out to measure it.

    • Amd competition. more numbers. (Score:5, Informative)

      by leuk_he ( 194174 ) on Monday February 04, 2002 @04:32PM (#2952018) Homepage Journal
      Now that you mention AMD. It has been roumoured last week all over the net that intel has a backup plan, an P4 with 64bit extenstions

      os.opinion article [osopinion.com]
      news.com [com.com]

      by the way, the amd hammer is expected to 105 mmm^2 [theinquirer.org] on 130 nanometer (.13).

      the current amd MP (palomino) has a die size of 129mm [electronicstimes.com] on .18.

      the original P4 has a die size of 217mm and is now at 150 mm^2.(with a bigger cache)

      Note that the original article does mention the 424 size is on .18 and the next generation is on .13. note that this can make a differce of a factor 2 (13^2/18^2= 0.52)

    • AMD Athlon (Score:2, Informative)

      by Vagrant ( 518197 )

      184 square mm die size (prior to Athlon 800)

      102 square mm die size (Athlon 800) ... source [earthweb.com]

      Note that this article also states that: Intel has also incorporated a substantial amount of redundant circuitry in the processor, Krewell said. Chipmakers often use redundant circuitry to boost yields. Sometimes, circuits come out scrambled on a finished chip. If the manufacturer has put in two sets of the same circuits, the chip will function properly because it can use the second set.

      You could have a dual Pentium machine and not even know it :)

      I guess this redundancy is why the chip has gone up 10% in size in the last couple of months ... (see this article) [com.com] which quotes: One of the reasons for McKinley's bigger price tag, Krewell said, is that it will cover nearly 440 square millimeters in area--or more than twice that of the Pentium 4.

  • Die Photo and Size (Score:5, Informative)

    by rbeattie ( 43187 ) <russ@russellbeattie.com> on Monday February 04, 2002 @04:01PM (#2951824) Homepage
    Ace's Hardware has this bit with more information [aceshardware.com] including links to an Intel presentation.

    "Slide 22 of the presentation features a die photo of McKinley. The large 3 MB L3 cache is notable, and according to the presentation, it consumes 20% less area than traditional designs and is overall 85% efficient (~70% for traditional designs)."

    And here's a story with the photo [theinquirer.net] from that same article (no need to download 2.5 meg pdf...)

    -Russ

  • A few minor points (Score:4, Insightful)

    by mtnharo ( 523610 ) <greengeek AT earthlink DOT net> on Monday February 04, 2002 @04:03PM (#2951836) Homepage
    Just for some minor clarifications: The 464 mm squared is the area of the actual cpu die. Like the little square on top of an athlon. So 2 cm per side die is kind of huge for a processor. The actual processor out of the box would have to be much larger than previous models. Next, 3 MB cache sounds nice, but L3? It may be on die, but by that point the clock reduction probably makes it perform equivalently to a 256 k L1 cache, or a 512 or larger L2. Not that it won't help a lot for complicated instructions, and it's probably less expensive/difficult to engineer to hook a larger amount of cache to a slower pipeline than to add more cache deeper into the cpu's core. 64-bit cpu's will be important in the future, but only when compatible apps and OS designs become mainstream.
    • Thanks for your "clarifications". You have saved us all from a life of ignorance.

      What you meant to say (and what the article said), is that 464mm^2 is size of the actual die size of the processor This includes the CPU and the caches. The CPU is a relatively small portion of the processor die, and noting there is 3MB of L3, the total cache may amount to 2/3 of the die size. The square on top of the athlon is also the entire processor die: cpu, caches and all.

      Also, L3 cache can never perform "equivalently" to L2 or L1 cache unless it runs at core speed. And I can tell you now, it doesn't -- or they wouldn't need L1 and L2. The L3 cache probably runs at something like 10 access cycles or more. It's not difficult to engineer 10 access cycles into any pipeline -- it's impossible. Which is precisely why it's not L1.

      I'm quite sure the engineers at Intel have done their modeling homework and determined that however fast the L4 memory may be, the L3 will improve performance by that much more.

      Remember, this processor is not meant to go on you or any other Joe Sixpack's desktop. It is meant to sit inside the workstations on the desks of engineers and in the racks of high-bandwidth servers. These platforms are specifically designed to run hundreds of tasks simultaneously and handle staggeringly high memory bandwidths. It has nothing to do with "complicated instructions." The L3 exists for swapping out large pages of memory in large bursts from a significantly larger sized L4 memory (think on the order of 100's of GB) from L5 memory (local drives and SANs) that has an incomprehendable virtual memory space.

      This has absolutely nothing to do with mainstream. I'm quite certain an OS already exists that will run on the platform. An IA-64 Linux is well under way (try http://www.linuxia64.org [linuxia64.org]) and you can bet that Compaq, HP, Dell, and Intel have put a total of more than 100x your lifetime earnings into developing software for that platform.

      Intel could not care less whether you or 99.9% of the /. readers out there ever buy an IA-64. They don't give a crap about your market segment, but I'm sure if you want to drop $10K+ on a IA64 workstation, be my guest. Your choices are limited. Either choose IA64 or UltraSparc. Or maybe if AMD ever gets a design win, you might get a chance to buy a Hammer box.

    • Next, 3 MB cache sounds nice, but L3? It may be on die, but by that point the clock reduction probably makes it perform equivalently to a 256 k L1 cache, or a 512 or larger L2.

      A fundamental rule of building caches is that a larger cache is slower and dissipates more energy per lookup than a smaller cache. This is why multilevel cacheing exists in the first place (otherwise we'd just have a huge L1 cache - and before you mention it, due to architectural sneakiness, HP's giant L1 cache isn't really an L1 cache).

      So, you can't just spend the L3 area on making a bigger L2. You'd end up with a slower, hotter L2, which could easily _degrade_ performance.

      As long as the L3 cache is faster to access than main memory, it'll be useful for some things. Whether it'll be useful for *most* things is another issue. This depends on the "working set" of the applications you're running (how much memory they repeatedly access). I guess Intel's banking on working sets being larger than most caches.

      Another possibility is that they're testing the cache architecture for use in future SMT or CMP designs (both of which would have multiple independent executioin contexts running). If you're running multiple *independent* contexts, the working set grows with the number of contexts.

  • Itanium at 1.6 GHz in 2003 ? (Score:3, Insightful)

    by Utopia ( 149375 ) on Monday February 04, 2002 @04:07PM (#2951861)
    For the article
    Madison is expected to come out in 2003 and run between 1.2GHz and 1.6GHz, according to sources.

    I wonder how Intel expects people to adopt Itanium-based processors considering
    that x86 processors will be running at 4GHz in 2003.
    • AFAIK, current Itanium chips run around 1 GHz and are way faster than a P4 2.2 GHz. Did someone mention "clockspeed is not everything"? It you look at (non x86-based MPP) super-computers, I'd bet none of them runs with CPUS faster than 1 GHz, yet each processor is often an order (or two) of magnitude faster.
      • According to SPEC CPU2000 Results [spec.org], The Itanium at 800 Mhz performances equivalent to a Pentium III 800 Mhz. In fact the Pentium III is a little faster.

        Do you have any other figures to substantiate your claim ?

      • Re:Itanium at 1.6 GHz in 2003 ? (Score:4, Interesting)

        by HiredMan ( 5546 ) on Monday February 04, 2002 @08:00PM (#2952936) Journal
        AFAIK - Enough said.


        As people have pointed out the 800Mhz Itanium chips - the fastest you can buy - have an integer performance slightly less than an 800Mhz PIII.


        From the article: "Applications will be about one and a half to two times faster than what you get on a (current) Itanium"
        I'm assuming this is WITH the huge L3 cache in pilot systems if they are claimed actual application performance.

        Let's compare this to the REAL competition: IBMs Power4.

        IBM Power4 1.3GHz - shipping for a while now:
        SPECint2000 = 814 SPECint_base2000 = 790
        SPECfp2000 = 1169 SPECfp_base2000 = 1098

        Even the best Itanium reported int numbers are:
        SPECint2000 = 365 SPECint_base2000 = 358
        (Same box) SPECfp2000 = 610 SPECfp_base2000 = 526

        Even if the McKinley (which doesn't ship for 6 months or so) produces double the Itanium numbers (which it won't) it'll still lag the currently shipping Power4 chips.
        And with only an clock speed increase of 60% over the next three years IBM can stay ahead simply by getting the 1.8Ghz models out the door in the next 24 months. (That's assuming that the 1.6Ghz McKinleys will even outperform the current Power4s.)

        It looks like Intel has increased clock speed by 25% added a bunch of L3 cache and is claiming 150%-200% gain. I think Intel has a (big) dog on their hands and they're trying to dress it up. The P4 performance will probably continue to outrun their flagship "server" chip and because of AMD Intel can't afford to strangle the P4's performance as they might have been able to in the past.

        Intel said, "Wait for Merced." - which we did for years. Then they said, "Well, the Itanium sucks, but wait for McKinley!"

        =tkk

    • Who cares about GHz... (Score:5, Insightful)

      by jbf ( 30261 ) on Monday February 04, 2002 @04:32PM (#2952017)
      ... if you can't run the apps.

      Intel x86 is restricted to 48-bit addressing (with segment registers), and practically 64GB with modern OSes. (http://linux-mm.org/)

      If I want more than 64GB of addressable physical memory (which I do for some apps), then who cares if you can give me a 32-bit x86 running at 900GHz, it's not going to do diddly squat for me, since _going over the PCI bus_ for swap is going to kill me vs a 1.6GHz 64-bit processor. And since you need to go over the PCI bus just to get to a pseudo-disk stuffed with RAM, that solution is still bogus.

      I see your point that this isn't what Joe Blow's gonna put on his desk. But the improved address space is definately a big win, and that's assuming that they can't ramp up the clock speed in a hurry.
    • IA32 and IA64 are radically different ISAs aimed at radically
      different markets. There's nothing on any recent Intel roadmaps that
      will have Itanic replacing x86 on the desktop. Conversely, 4ghz of
      Hot P4 Action is meaningless to an application that requires more than
      4gb of process address space.

      A 1.6ghz McKinely ought to be a very competitive performer, especially
      on floating-point intensive code.

      Peace,
      (jfb)

  • 64 bit regs is new? (Score:4, Interesting)

    by gTsiros ( 205624 ) on Monday February 04, 2002 @04:07PM (#2951865)
    Yeah, right. Intel is the big player. Right.

    My calculator's [google.com] processor has 64 bit registers. You think i'm trolling? Check it out for yourself:
    google search [google.com]

    There are a lot more (and more powerful) procs out there, but this one just seems more appropriate for intel bashing ;)
    • Your calculator also has a lack of cache, a variety of register instructions and compatibility with other architecture. Your point is?
    • Yah, but how MANY does it have? The IA-64 architecture, as I recall, calls for 256 such registers. I sincerely doubt your calculator has that many (let alone the redundant sets that no doubt exist internally to speed up execution). It is dumb to say it's the first processor with 64-bit registers, though..
    • A quick summary of the Saturn microprocessor, for those interested...

      The Saturn processor is a propietary HP chip used in many of its calculators. It's generally considered a 4 bit chip (since this is the internal data bus size), but it has four 64-bit registers [zoy.org]. I think the coolest part of the chip is that each instruction can operate on various portions of these registers -- for example, only the upper nibble, or only the lowest 4 nibbles. Since this is a calculator, math is generally done in BCD format. Externally, the chip connects using an 8-bit data bus. The address bus width (and therefore the PC, too) is 20 bits wide, and each address refers to a nibble of data. Maximum addressable memory = 1 meganibbles = 512KB. Most of the calculator firmware (such as calculating the sine of a number or matrix manipulation) is interpreted RPL to allow code reuse code (to save time, and to ensure bug-free implementations)

      HP did a great job with this calculator, including releasing internal documenation and development tools. More info here [hpcalc.org], or use google.

      It's a shame that HP shut down thier calculator division. [slashdot.org]
  • ..perhaps we're trying to get back to the good ol' days when you could walk around inside your computer....

    or maybe they're taking the term "big iron" a little too seriously..

  • Coffee warmer built-in! (Score:3, Funny)

    by Insightfill ( 554828 ) on Monday February 04, 2002 @04:20PM (#2951940) Homepage
    At that size, a smallish mug should fit nicely on it. No use wasting all that heat!
    • At that size, a smallish mug should fit nicely on it

      Now, someone needs to figure out how to mount it on the CD/DVD tray, so the cup-holder will be heated.
    • At that size, a smallish mug should fit nicely on it. No use wasting all that heat!

      For now, maybe. According to an article [theinquirer.net] linked in an above post, the chips will be cooling down ... to room temperature! Unfortunately, this means no more hot coffee. :) Here's the quote from the article:

      And Intel claims McKinleys in the future will run at .13 micron and at 5GHz at normal room temperature, because of the low power circuits it will use.

      I don't drink coffee, but I was kinda hoping to have something to keep my feet warm. :)

  • That's Almost 3 bits per millimetre! (Score:3, Funny)

    by Bobzibub ( 20561 ) on Monday February 04, 2002 @04:26PM (#2951979)
    "464 square millimeters which would make it one of the largest ever produced....due to the 64 bit registers." 464^.5=21.54mm a side.
    64bits/21.54mm=2.97 bits/mm

    They've GOT to start using smaller wavelengths!

  • Nothing new here - take a look at the hp-pa 8800 (Score:5, Interesting)

    by Anonymous Coward on Monday February 04, 2002 @04:31PM (#2952011)
    http://www.lostcircuits.com/cpu/hp_pa8800

    Has 3Mbyte L1 cache and 32Mbyte L2 cache and
    a transistor count of 300 million.

    To quote:

    "The HP PA-8800 L1 cache is probably the biggest L1 that ever existed so far with separate 750 KBytes of data and instruction cache for each core. This results in no less of 4 blocks of ¾ MB density each for a total of an unprecedented 3 MB L1 cache, physically twice as much as the combined L1+L2 on IBM's Power4. Accordingly, the transistor count of the HP-PA8800 is with 300 Million transistors almost twice as high as the 170 Million transistors of the IBM Power4 and results in a die size of 23.6x15.5 mm2 or 361 mm2. The L2 cache of the PA-8800 is off-chip and consists of four 72 Mbit "1 Transistor SRAM" chips developed by Enhanced Memory Systems.

    http://www.cpus.hp.com/technical_references/PA-8 70 0wp.pdf

    has a roadmap of the hp-pa and Itanium chips so
    really there is nothing new or exciting to report
    that hasn't already been said 9 months ago.
  • Last I heard, Intel may have dug themselves a hole with Itanium. It's incompatibility with existing apps means that there is no desktop demand to drive economy of scale. Therefore the price isn't coming down and the price/performance is not improving faster than the older, "inferior" technology. How will they escape this death spiral?

    sPh
    • You are correct, alas.

      Technically, the Itanium architecture is a great idea, but with no real software available for the CPU (do we really have a native-register Linux distribution for this CPU?) the processor is not going to be very popular.
      • Technically, the architecture is terrible. Intel bet that they could eliminate on-chip support for out-of-order execution and designed an architecture around that assumption, hoping that compilers would be able to compensate. They lost the bet. So Itanium is good for regular workloads, especially those with predictable memory accesses, but sucks hard for workloads with irregular memory access (like, say, programs that spend a lot of time traversing complex data structures).
    • I think it does run older programs. In a simulation/emulation mode. Don't know much on how it works though...
  • I wonder if AMD will start some sort of "size isn't everything" initiative.

    Maybe they could offer some sort of conversion system, so that consumers can easily convert between centimeters and inches, and understand that AMD's new 1.5"+ chips perform about the same as Intel's 20mm McKinleys...

  • So... (Score:2)

    by sohp ( 22984 )
    Is that an Itanium in your pocket, or are you just glad to see me?
  • ... since Intel basically already owned the Alpha chip, and the Alpha already outperforms the standard Intel chips, and the Alpha is already 64-bit, and already has software for it, and has a long proven track record, and had design plans going out many many years to make improvements to the design ... Why is Intel spending so much time and money on this new chip which is already over budget and behind schedule?

    I've never been able to figure that out.

    • First, pride. Not invented here syndrome -- while Intel has already digested some external technology like the StrongARM, still their engineers must have some pride left -- and big ones, since the best engineers have already left and the mediocre ones tend to be the proudest. Also, it's not Intel only, but Intel and HP, so if Intel would shift everything to the Alpha HP would have to agree on that.

      Second, dumbness. VLIW probably isn't a good idea anyway to general purpose microprocessors, and while EPIC tries to address some VLIW shortcomings it makes for a pretty complex architecture which negates some of the VLIW proposed benefits. The picture gets still worse if you throw in IA32 compatibility.

      Third, they own the design, but once again the best engineers left the company. No self-respecting engineer wants to work for Intel, they have a long history of abusing employees and imposing dumb management decisions on technicians for a long time now, in their branchs all over the world.

      So the only sane architectures left with a future on the market are PowerPC and UltraSPARC. Sad but true.
  • "... also announced was the new 'Chicanium', which combines the 200Mnerdz power processing of the Itemium with the sexual prowess, digitally extracted, of a cheap Tijuana hooker and her little brother. Release date, 2002."

    (The processor, not her little brother.)
  • The computer world is increasingly reaching the point that we need 64-bit addressing - the price of memory has reached the point that computers with more than 4GB of RAM are not only feasible, but becoming common, and for a couple years we've had disk drives bigger than 4GB. This means that 32-bit addresses are no longer enough - and with the 36-bit and 48-bit segment-based things that allow machines to address more memory, we're rehashing all the ugly tricks we had to play with 20-bit and 24-bit addressing on 16-bit-addressed 8086/80286 machines. Ugly, ugly, ugly!

    For most people, 64-bit arithmetic isn't critical - most applications don't deal with ints larger than a billion, though us crypto people who do lots of bignum math are happy to get a 4x speedup. Otherwise, the quality of floating point implementations is likely to be more important. So it would be possible to get by with 32-bit arithmetic and 64-bit addresses, like we did with the Motorola 68000's 16-bit-ints and 32-bit registers and addresses - but that was also somewhat tacky, and led to *lots* of bugs in code that assumed ints and pointers were the same size, though perhaps we've evolved enough past K&R C that newer software won't make that mistake as often.


    A real problem this time around is that the C language and its relatives really do like 32-bit integers, and many of the Unix system calls also assume 32 bits. If you make the native int/pointer sizes 64 bits, there's a lot of stuff that will probably break. What kind of experience have people had running code on DEC Alphas and other real-64-bit chips?

  • Of all the media bull I've heard about the 64-Bit Intel/AMD chip, I've yet to hear ONE SINGLE person claim that the new chip will be somehow better than the Alpha.

    Tell you what. Since all the apps need to be fixed (or at least recompiled) to work on 64-bit processors anyhow, why not just go the route of porting everything to the Alpha? We could use this to finally get the hell away from Intel's terrible chipset.

    And for all of you that think the Alpha will be dying soon, there are plenty of companies other than Compaq with Alpha products that are far better quality than Intel, and will likely be cheaper as well.

    http://www.microway.com/products/ws/alpha_21164.ht ml [microway.com]
  • EETimes has a nice article [eet.com] with a good graphic comparing the internal workings of the Itanium vs. McKinley ... a good level of detail: 10 vs. 8 pipeline stages, differing bus widths and speeds, execution units, etc.

    The article also talks about other intel innovations disclosed at the International Solid-State Circuits Conference

Slashdot Top Deals

Solutions are obvious if one only has the optical power to observe them over the horizon. -- K.A. Arsdall

Close