Slashdot Mirror


Intel Releasing PIII Xeon Today

BMIComp writes "Yahoo! news is reporting that Intel is going to introduce their Pentium III Xeon Chip, today. " .18 microns, 700 Mhz, and integrated cache. The article talks quite a bit about how the new Xeons are going straight for Sun's throat.

4 of 131 comments (clear)

  1. CPU Horsepower Often Subservient to I/O Horsepower by Christopher+B.+Brown · · Score: 5
    Intel may want everyone to believe that this release will be heavily injurious to Sun. If people believe that, it will thereby become true.

    But it's not necessarily the truth.

    The truth is that for a whole lot of the applications for which people are installing big UltraSPARC boxes, the applications are not CPU-bound, but rather I/O bound.

    • DBMSes are dependent on having big memory caches to improve performance;
    • DBMS applications need arrays of big, fast disks, with hefty cacheing.

    Having a better, faster Xeon Pentium III processor doesn't help with either of these things.

    What helps with such applications are:

    • Faster disk drives.

      Which Seagate and Quantum and IBM are responsible for...

    • Faster RAID controllers.

      Think Adaptec, maybehaps?

    • Huge memory spaces.

      Which means more than the 8GB that appears to be supported at this point.

    • The relevant thing from Intel would be to see vastly better I2O controllers. THAT is what would fill Sun's heart with fear...
    --
    If you're not part of the solution, you're part of the precipitate.
  2. Re:The RISC/CISC holy war. by Christopher+Thomas · · Score: 5

    The thing about CISC is that they have a habit of using microcode to translate all of the complex instructions into smaller ones for the core of the processor (AFAIK). The time it takes to decode instuctions is considerable at this stage, sith several hundred instuctions.

    Trust me on this one - it's at most one clock, and possibly less. This goes for the x86 instruction set especially; each byte of the variable-length instruction has a fixed purpose, instead of being completely random. To process this, you need to prefetch several bytes ahead and have three or four shifters and a MUX to select and align the next instruction while you're processing the current one, giving a throughput of one instruction fetched and aligned per clock (or more, if you add more silicon). Once the instruction is aligned, you read out each of the fields that might possibly be there, and use a MUX to select them. You have a combinational logic block that processes the opcode and tells you if this is an instruction that can be processed atomically or that needs to be broken down, and a lookup table giving a series of RISCian stages for multi-clock instructions. If the "multi-clock" flag is set, you stall the instruction fetch unit and route in instructions from the lookup table instead.

    It should be noted that processing the argument-location byte may insert memory load/store instructions too. However, as these are very predictable, you don't need a table lookup for them (just stalls and instrucion register preloads at appropriate times).

    Lots of extra silicon, but little extra time. You do much the same thing in a RISC processor, except without the alignment stage or the lookup table.

  3. Re:What's the advantage? by lbrlove · · Score: 5

    I cannot give you a whole lot of technical detail, but practical data I have. I have a SuperMicro S6DGU dual Xeon board on which I run two 500-MHz 512k units. I have compared these to a similar SuperMicro dual P3 board, and did some time comparisons in both SCO UNIX and in WinNT 4. In both cases, the Xeon was between 10 and 25% faster at the same clock/processor speed depending on the application.

    At the time, I did not test multiprocessors, but I can only suppose that the margin would widen due to better SMP support within the Xeon/GX chipset. Also notable is the difference in chipsets between the BX and GX I tested with. The GX may make my setup a little faster with memory interleaving, more efficient bus arbitration, etc.

    What remains to be seen is whether the cost difference justifies the performance difference for small servers, workstations, and hobbyist users. Can anyone kick in their deep technical knowledge of these chips?

    -L

  4. Sun doesn't need to worry about Xeons by x0 · · Score: 5

    Intel might claim that they are going for the throat with the PIII Xeon, but they have a huge gap to close before marketing catches up with reality.

    As far as I can tell, the most the Xeon can scale to is 8 processors. At least that is the largest machine I can find for Xeon. Sun's midrange machines _start_ at 4 processors and, for now, go up to 64. The planned maximum for UltraSparc III is 1024. Sun 1, Intel 0.

    UltraSparc is 64 bit, Xeon is 32.
    Sun 2, Intel 0

    UltraSparcs have had integrated caches for quite a while, as far back as SuperSparc I. On the current cpus, the desktop boxes can have up 2MB cache, the midrange servers 4MB, and the large Enterprise servers get 8MB cache. The PIII Xeon's claim to fame is the extra electronics they add to the processor card which allows some hardware admin of the processor. The cache size is 256KB ...same as a standard PIII.

    Sun 3, Intel 0.

    Until Intel produces a cpu which can scale well and has an OS which supports that scaling, I don't think Sun has much to worry about.

    And for those of you who think MHz is a consideration, bzzzt! In the world of 24x7 server farms, torque counts more than horsepower. The UltraSparc cpu can handle a much greater load without sweat than most other cpus. The UltraSparc was designed to handle massive loads. So, while the UltraSparc will likely lag behind an equivalently rated Intel cpu, which would you rather use to make a cross country houshold move: A Kenworth or a few dozen pick-up trucks?

    --
    In the immortal words of Socrates, who said; 'I drank what?'