Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Intel

Intel Releasing PIII Xeon Today 131

Posted by CmdrTaco from the bigger-faster-better dept.
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.
This discussion has been archived. No new comments can be posted.

Intel Releasing PIII Xeon today More

Intel Releasing PIII Xeon today

Comments Filter:
  • Maybe you should go see a doctor about that... :o)
  • Click the START BUTTON...Click RUN...and type FILE:///CON\CON ..... Now Press OK..... um, you can just make that a link, unless they fixed that a href="file:///con\con" [concon]

    That was fixed a long, long time ago.
  • IMO it's the software more than the processor... I have one of those well-heeled 200MHz PPros (with 64MB mind you) running RH5.2 and Apache/PHP that blows the pants off a PII350 with four times as much RAM running Netscape Enterprise Server on NT. (Even that machine handles 20,000 hits/day more than comfortably, so it doesn't really matter... :-)
  • I certainly agree that SPARC may not be the best choice for CPU-intensive task. That's basically what I said; Sun's strength is with I/O-bound systems.

    Getting into issues of RISC versus CISC gets us away from the point.

    The point is that those that are preferring Sun systems to Intel-based systems today are doing so not out of being focused on how much stronger SPARC used to be for CPU-intensive processes, but rather (most likely) because they've got I/O-bound processes.

    The result is that the announcement doesn't scare Sun:

    • Those that used Sun for I/O-intense processing see nothing in this announcement that would cause them to prefer Intel to Sun.
    • Those that had CPU-intensive processes weren't running Sun, and thus the preference might involve them moving from SGI/MIPS to SGI/Intel, or from Compaq/Alpha to "something Intel."

      But as there weren't Origin/Crays running SPARCs (I don't think there...), while this may represent a threat to MIPS or Alpha, it's not particularly one to SPARC.

    Overall point: The article suggests that the threat was to Sun. A "threat tree" shows that this is not strongly the case.

  • Sure, running comparable software, better hardware (better I/O in particular) will trounce worse hardware. I'd rather have a recent Sun with Solaris than any x86. My point was that better hardware running crappy software will not keep up with older hardware running efficient software.
  • well I'll pick at 6-0.
    • Sparc has big AND little endian support for memory access. 7-0
    • a HUGE register space with globals locals and a great input and output sets, with rotational scheme. 10-0
    • alternate globals for faster interrupt use. 12-0
    • all registers are 64 bit. 15-0
    • 4 memory models for better multiprocessor handling 17-0 (yes you can argue this ;)
    • fixed size instructions 18-0

    And stop there. Get "The Sparc Architecture Manual V9" and you'll see 100s of this things.

  • I want a beowulf of these...:-)

    No, seriously, I think that the fact that they seriously challenge the Sparc speedwise says a lot about how overpriced the mainframe /large server processor market is. This means that we're going to (hopefully) see the server market get a little less expensive. But what'll probably happen is that when the large servers will get even more clocks, they'll discontinue the low end, and my electric bill will continue it's ever upward spiral.

  • Another News Site: (Score:3)

    by Devil Ducky ( 48672 ) <slashdot@devilducky.org> on Monday May 22, 2000 @08:02AM (#1055999) Homepage
    I tried to post this with this news story [cnet.com]. It's on C|NET. They both sat pretty much the same thing.

    Devil Ducky
  • Bring the temperature of the inside of your comptuer, roughly to the equivalent of the surface of venus!

    tcd004

    Here are my Microsoft [lostbrain.com] and AICN [lostbrain.com] parodies, where are yours?

  • Remember the Celeron 300 and 300a? Case in point. The more the better. Your logic is flawed here. It's true that going from the cacheless 300 to the 128k cache 300a was a huge improvement I wouldn't say "the more the better." It depends entirely on what application you are using the proc for.

    For instance, a computer with 32MB of ram is going to run a ton faster than one with 8mb of ram, but one with 1GB of ram isn't going to run that much faster than one with 256MB of ram for normal applications. Only really high-end apps need this much.

    The Xeon is aimed at High-end servers which could probably benefit from the cache, but is the price worth it? I dunno.

    The main reason to buy one, as you stated, is for the >2 SMP. AFAIK the only difference between the MP capabilities of the Xeon line and the regular line is that the PIII's are purposely crippled to only run on 2x SMP. It seems like a rip that Intel would do this and then charge an arm and a leg for almost the same proc with SMP turned on.

  • Not fair to whom? The Xeon? ;)

    Having looked at the reviews at Ars Technica, I'm not terribly impressed with the Xeon's improvement over the Coppermines, especially considering the cost and the recent poor quality of Intel's supporting chipsets. (QA? What's QA?)

    Call me, when Intel jettisons the x86 legacy.

  • Thoughts (Score:3)

    by Nyarly ( 104096 ) <nyarly.redfivellc@com> on Monday May 22, 2000 @08:11AM (#1056003) Homepage Journal
    • First, I found this [yahoo.com] article to be slightly more informative about the Xeon. I relaize the Intel cronies out there know a lot more about the Xeon line, but there are those of us who don't follow Intel quite so closely.
    • Then there's the issue of design and the media. Cnet is descibing the Xeon 700 as the biggest chip that Intel had ever made; last I checked more transistors wasn't necessarily a good thing, unless you were looking to cook breakfast on your motherboard.
    • And caches. Am I to understand that the biggest advance on the Xeon is the addtion of an on chip L2 cache? When Intel is so famous for using a cache well in the first place? Really, how much of a difference will it make to use a full-clock cache on chip over, say, a half-clock cache off-chip?
    • Finally, what about some metrics. Everything I've read says that the new Xeon is supposed to be fast, and that because server customers tend to be more hesitant about upgrading, testing and shipping will take longer, but I'd really like to see these chips compared to the Sun or Motorola top-of-line chips.

    Ushers will eat latecomers.

  • What about hot-swap hardware and redundant power supplies? Are you sure you fell like replacing shorted boards on 50 machines after a power surge?

    -jpowers
    You Know You've Been Watching Too Much Ranma 1/2 When...

  • Re:Sun doesn't need to worry about Xeons (Score:4)

    by Shoeboy ( 16224 ) on Monday May 22, 2000 @08:14AM (#1056005) Homepage
    As far as I can tell, the most the Xeon can scale to is 8 processors.
    And it doesn't do that well. Intel's 8 way chipset is crap. To grossly oversimplify it's two 4 way shared busses communicating over yet another shared bus. It performs about how you'd expect. Compaq has a better 8 way xeon chipset, but if they're not your hardware vendor, you're SOL.
    Somewhere Scot McNeally is screaming "Help, I'm being menaced by a dwarf!"
    Or not.
    --Shoeboy
    (former microserf)

  • And your MTBF will be.. ?

    There's a /reason/ people like those E6500s.. They make a lot of things convenient for the most expensive part of any site: The admins.

  • I was under the impression that the ID's are only being dropped on Coppermines. I was reading on Intel's site and the page I was reading stated how great it was to have the chip ID's on the new Xeons so you can monitor your "big" servers. I'd like to see what the Unisys 32 CPU server can do but Intel has a ways to go to get to big machines. Chipsets have made me leary in recent times.

  • Sun's systems consistently underperform when matched up against similar systems from almost all of their competitors.

    Depends on the jobs, benchmarks, etc, blah blah. In the market the EXX00 systems reside, they offer some damned good scalability and redundancy (predictive failure modeling on CPU/RAM and hot-spare CPU/RAM without system reboot.. Add new CPU/RAM as hot-plugs and activate without system reboot... How many Intel systems can do that?) as well as memory capacity and the 64-bit OS to support it.. I'm looking into refurb 3x00/4x00s for several system upgrades, and while some of the SPOFs are annoying (primary CPU/RAM planar errors require reboot, no alternate-pathing of PCI boards) I'm still interested in the overall improvement they offer.

    Sun offers the best scalable unix systems for business use IMHO. Between CPU/RAM options, software availability, driver support, and OS features I'm pretty happy with it...

    Now if Sun'd ever backport DSDs to the XX00 series like they did with Starfire's DR/AP... one can dream...


    Your Working Boy,
  • There are so many unique IDs in computers that I personally don't care. And plus, the PSN could always be disabled in the bios.
  • I was looking forward to this for awhile now, but I'll probably wait until the price comes down. I really don't need to shell out a thousand bucks for a processor.
  • A CPU is not designed for higher or lower load. It always runs at 100%, regarless of whether there's load of 10 or nothing but the idle loop to run.

    Semantics: some modern CPUs can go into powersaving idle modes..

    Your Working Boy,
  • Intel said the new chips are available now in limited quantities of 1,000 for $1,177 for the one megabyte of level two cache and $1,980 for the two megabyte cache version. Volume shipments will begin ramping up over the next several months.

    Too bad that availability is still a joke, as well as the exorbitant prices. Way to go Intel!

  • I agree with everything but the cache sizes. Last time I checked xeon's could be gotten with up to 2 megs of cache. That doesn't even touch Sun's hardware, but it does help the xeon.
  • What makes the Xeon better? The cache is larger, yes? Everyone else on Slashdot knocks L2 cache saying it's overrated and underutilized as is. Anyone have any insight as to what makes the Xeon a good choice in the server arena?
  • True, the cache is 'off-die', but it does run at cpu speed. This is why the Sparc modules have about 2 pounds worth of heatsink on them.

    It is also why a 450MHz/8MB Ultra module costs $9500. (Note: I haven't looked in quite a while, so that price was when I last looked -Dec, 99-, it is likely less now, and I am sure big customers get deep discounts.....)

  • oh! finally i can render Q3A to multiple remote X terminals on my server. I hope something will be done in the DRI which can render the image using the local 3D accelerator card, and then drive the image accross the network to remote clients, a la vnc for OpenGL. does something like this exist?

  • Re:Another News Site: (Score:3)

    by EisPick ( 29965 ) on Monday May 22, 2000 @08:17AM (#1056017)
    > They both say pretty much the same thing.

    That's because they're both rewrites of a press release. Welcome to the glamourous world of business journalism.
  • well how can we compare them? I mean one's 32 bit and the other is a 64 bit processor. Just that one's clocked higher than the other one
  • .. that PII Xeons can come down even further in price now? .. Be quite nice that. :)

    Although looking at Pricewatch says that PII Xeon 400s with 1MB are down around $180 .. one site says $135.. hmmm...

    *rubs hands*


    --
  • This article [yahoo.com] says that:
    "The new Xeons will be used in a 32-processor server from Unisys that Compaq also is selling, Ambrose said. And IBM will use the Xeons in a new 64-processor machine to be announced later this week, based on the Numa-Q design IBM acquired by buying Sequent." I want one.
  • Three years ago the IA-64 was supposed to put Sun out of business. Since we are now unlikely to even see a broken IA-64 in the next year Intel has dusted off the losing Xeon and will continue to wage a war of words with it. Meanwhile Sun marches from strength to strength with its multiprocessor system and the solid SPARC chips. Intel, you could learn something about engineering from Sun.
  • AFAIK, Athlons *do* support SMP, it's just the motherboards are missing... Athlon is using Alpha EV6, which supports per processor bus in contrast of Intels shared bus between all processors. Intel has some major problems with >4-way systems just because of this. Athlons should be able to do better when we finally get those MBs. :)
  • I think what they do is use clusters of eight CPUs, so that if you want a 64 CPU system, it uses eight CPU daughtercards. The net result is a cluster of eight 8-way SMP daughtercards.

    That's not exactly my number one choice for enterprise server. Still, it's quite innovative for an x86 vendor. IBM sure will go the distance for you if you really, really want to stick with the Wintel architecture.
  • I'm a little irked that the major emphasis of the article is the profit margin that Intel wants by targetted the high end, not the technological nitty gritty. It is a pretty pompous thing to just assert that this processor will give Sun a challenge (when Sparc already scales much more than Intel). See the following:

    ``Now they will be able to charge these high prices and they have their cost structure under control...The new version is so much more economical.''

    This is a financial article, not technical. Bleah. Don't get me wrong, I'm not apposed to Intel making money, I just find the article content to be flimsy and not to be "News for Nerds."

  • You're joking, right?

    We have a stack of SMP servers here on BX-based boards, and they are rock solid. One of them gets up to 10+ load average on occasion.

    About the only BX board I can think of that *is* known for instability with SMP is the Abit BP6. Unsurprisingly, you get what you pay for.
  • Get "The Sparc Architecture Manual V9" and you'll see 100s of this things.

    Yep. I've read the whole thing. :) It's exceedingly easy to program as well. And has backward compatibility in such a way that doesn't interfere with the rest of the CPU. 44-bit (64 in US-3) address space. Memory-mapped I/O. I could go on... Intel could learn a lot from the Sparc.

  • The upcoming mustang athlon will have similarly large caches and I'm sure it will be much cheaper and available at higher speeds. It should also have a 16 way associative cache and will do very well once the SMP motherboards are released in the 2nd half of the year. Even with them cutting prices in half, it is still outrageous for a 700 Mhz chip today.
  • "Really, how much of a difference will it make to use a full-clock cache on chip over, say, a half-clock cache off-chip?"

    A huge difference. Most x86 chips are memory bandwidth starved, so faster L2-to-L1 fills are always a big deal. Remember how much better the ATC (advanced transfer cache) P3's were? All they did was widen the L2 (?) cache bus.

    UltraSparcs wouldn't care as much since they have a nice very wide path to core memory (and cache), and I bet they have more load/store functional units (or hit-under-miss capability), so are less bottlenecked on memory accesses (get to know modern processor design!).
  • As for using the RISC-iest subset of a CISC, this is why RISC was developed: good fast CISC stuff only uses a reduced set and stays away from time hogs.

    Similarly, EPIC derives from the fact that good fast RISC code is that which is scheduled well. EPIC moves the scheduling to compile-time, rather than runtime.

    When x86 dies, that's the end of CISC. Yay!

  • > "UltraSparcs have had integrated caches for quite a while, as far back as SuperSparc I."

    Ha? Supersparcs had integrated L1 cache. So did the 486. And remember the old CISC vs RISC debate. Hint: CISC programs tend to be smaller than equivalent RISC programs. Also, 64b pointers tend to take more space than 32b pointers. Bottom line:
    you don't need as much cache.


    A few points:
    1. Due to processors like the SPARC having more registers, memory isn't hit as badly as on Intel's woefully inadequate architecture. This may improve cache performance, and certainly helps keep memory bandwidth available.
    2. Because RISC processors spend less time juggling variables about between registers and memory, more work can be done in the same number of instructions. And the fixed instruction length improves performance elsewhere in the processor, negating the performance impact of slightly larger avarage instruction length.
    3. Code for the UltraSPARC does not HAVE to work with 64b data. Until Solaris 7 came out, Solaris was strictly 32b on any SPARC. And instructions are always still 32b long.
    4. If you DO have to work with 64b values, the x86 will have to improvise to handle the data, resulting in more instructions == bigger hit on the cache. With BIG databases, native 64b data handling must surely be a big win when working with large databases.

    Besides, when we're talking about the sort of hardware you referenced, we are not talking PC price advantage anymore. The only real benefit of Initel hardware is the low price as a result of huge volume. These machines are definately NOT large volume.
  • Having read much that Gwennap has written for Microprocessor Report et. al, I've come to believe that either this guy owns Intel stock -- a LOT of Intel stock -- or he's the journalistic equivalent of the IT managers that say "You don't get fired for buying IBM/M$/whatever.

    I can't recall ever seeing anything he's written that says anything other than positively glowing things about Intel. It's almost like he's trying to be the personal antidote to The Register [theregister.co.uk], but whereas the Register is an admittedly biased gossip rag for IT folks, Mr Gwennap is supposed to be an independent analyst.

    My point is, take anything he says about Intel with a very large grain of salt.

  • Somehow I don't think graphics performance would be terribly important to the server market. However, if it slowed down the *network* cards, that would be a problem.

  • The article seemed poorly worded. I believe that the previous Xeons were not Pentium II based. So, the differences, in addition to the speed bump are going from .25 micron to .18 and going from half-speed, off-die cache to full-speed, on-die.
  • I read that the large cache Xeons will be released fairly soon. Probably at the end of the year. Until then, we'll have to make do with the small (256K) cache Xeons.

    Sun engineers might be laughing at the Xeons, but the managers at Fortune 500 corporations are probably going "oooh" and "ahhhh" on cue from the Intel marketing.

  • Awful nice of Intel to release PIII Xeons after letting me run a quad-proc system with 550s for the last 6 months.

    I think they mean (and the article does indeed say) that Intel is releasing 700mhz PIII Xeons. Hardly worth getting all worked up about.

    Someone else will surely have posted this by the time I finish typing, but what the hell.

    -Tommy

    ------
    "I do not think much of a man who is not wiser today than he was yesterday."

  • doh. Meant to say "I believe that the previous Xeons were Pentium II based."
  • so does my fscking g4. sun has up to 8. intel is behind here almost as badly as apple in is the gigahertz wars.

    tom

  • I think that Intel is going to be stuck in the personal computer market for a while. They just don't have what it takes (yet) to play with the big boys.

  • Cache, and where a Xeon makes sense. (Score:3)

    by Christopher Thomas ( 11717 ) on Monday May 22, 2000 @08:36AM (#1056039)
    What makes the Xeon better? The cache is larger, yes? Everyone else on Slashdot knocks L2 cache saying it's overrated and underutilized as is.

    For most personal systems, adding cache would give diminishing returns fairly quickly. However, a personal system usually has one or at most two major tasks draining resources. A server has many cpu- and memory-intensive tasks running at once. A small cache would thrash on every context switch. A larger one wouldn't. Of course, how much of a performance gain this gives depends on how long the timeslice is, but if the timeslice is short enough, it's relevant.

    Anyone have any insight as to what makes the Xeon a good choice in the server arena?

    Probably price. A Xeon system is cheap compared to its competition, if I understand correctly. It doesn't scale as well as a Sun box, and won't give you the floating-point performance of an Alpha box, and doesn't have the memory integration of an SGI box, but as an inexpensive mediocre solution it can be a good buy if you don't really need something cutting-edge.

  • Yikes (Score:2)

    by zpengo ( 99887 )
    I could put together a whole AMD system, periphs included, for that much!

    (It'd prolly be faster, too)

  • The cache size is 256KB ...same as a standard PIII

    Actually, the article indicates cache sizes of 1MB and 2MB, which seems more reasonable for a server CPU than 256KB. Still smaller than your average SPARC, though.

  • >> On the other hand, If you are running Windows >> and you need SMP then I guess you don't have >> any alternatives.

    Nobody needs SMP. People need a certain level of performance. SMP is just one way of achieving that level, and even then only for certain tasks.
  • Am i wrong in thinking that a Celeron is using exactly the same technology as the Xeon, but with a smaller cache - i.e. they both have on-die cache, as opposed to P2s (not sure about P3s, do the new ones have on-die cache?)

    Cos it seems odd to me that a 550 Mhz Xeon costs about 8 times as much as a 550 Mhz Celeron, even though they are essentially the same design.

    Does Intel use Xeon dies with broken caches as Celerons?

  • AFAIK, Dell has been offering systems with 866 MHz PIII Xeons for a few months now. I don't see why a "new" 700 MHz CPU is interesting when the "old" ones are 866 MHz.
  • Yes, MHz does make a difference, but people need to please stop touting SPEC results without taking into account other factors when comparing CPU performance...

    SPEC benchmarks are designed with minuscule datasets to reduce RAM and Cache bottlenecks... some interesting articles found at the STREAM homepage [virginia.edu] discuss how some CPU manufacturers boosted L2 cache on their chips, while ignoring RAM bandwidth considerations, simply to get higher SPEC results...
    Memory bandwidth results (MByte/s) for recent HP, RS/6000, and esp. Alphas single-CPU workstations show they can play around with much more data located in RAM alot quicker than a 733 PIII, even at low clock speeds (400MHz for POWER3 and PA-RISC 8500... the Alphas were 21264s clocked at equal to or slightly less than 733MHz, with results being about double those of the PIII)... note that the PIII wasn't a xeon... shouldn't make a big diff though, because the architecture is similar (nearly identical) for PIII and PIII-xeon... look at the results yourselves, it's innarestin...

    that being said, all Sun Ultra workstations performed a little worse than 'equivalent' HP, IBM, and DEC(Compaq) workstations regarding RAM bandwidth... Ultra60-360s perform so poorly that the PIII 733 gets twice as many MFLOPS on a particular test (but the lead is much less on two others... a 450MHz-Ultra might tie or surpass them)...

    And ALL that to say that SPEC is only useful if you're comparing systems which will be doing computations on teeny tiny datasets. At least that's the case for SPECcpu95, I don't know about SPECcpu2000. Furthermore, the SPECfp benchmarks focus mainly on double-precision floats, to the expense of single-precision floats... this might indicate why results for SGI machines make them look pokey, considering some of their CPUs (r5000) are optimized for single-precision MADD instructions, because of their ubiquity in doing 3D work...

    Here are some sites that contain benchmark results and/or link to sites with benchmark results:
    SPEC website [spec.org]
    the CPU Info Center [slashdot.org]
    FutureTech SGI info [vuurwerk.nl]
  • "Nobody needs SMP. People need a certain level of performance. SMP is just one way of
    achieving that level, and even then only for certain tasks. "

    oh, then you "get" the joke. . . riotous, isn't it?

    I just remembered this old Metallica song. . .
  • The new Xeons will be used in a 32-processor server from Unisys that Compaq also is selling,
    Ambrose said

    No, that's wrong, they will be used in the design of those systems, to figure out how to most efficiently dissipate heat. . .

    I just remembered this old Metallica song. . .
  • "What's everyone else's opinion on this? "

    um. cool? I wasn't going to be buying any Intel chips anyway.

    I just remembered this old Metallica song. . .
  • Another wonderful, overpriced and overheating Intel chip. I love the line...

    "...a higher-margin product line which is targeted to the fast-growing network server market."

    Higher-margin? You mean OVERPRICED, right?

    Thanks, but I'll stick with Sun (granted, not terribly better, but at least the hardware around it is better.

  • Many Faces of Xeon (Score:3)

    by Kommet ( 27381 ) on Monday May 22, 2000 @08:39AM (#1056050) Homepage
    Besides being a patently dumb name (sounds like a new Noble gas), Xeon is a chip with split personalities.

    The original PII Xeons were the standard Deschutes (.25 micron PII) cores with full-speed L2 cache at 512 KB, 1 MB, and 2 MB. Those were replaced by the PIII Xeons that had the Katmai (.25 micron PIII) core with the same cache and sporting the addition of SSE. Both were rated for up to 8-way SMP. These are the Xeons that maxed out at 550 MHz.

    There are a newer batch of Xeons based on the Coppermine core (.18 micron) that don't really differ from today's PIII's except that they are rated for multiprocessing (2-way only, I think). The Coppermine Xeons have 256 KB of on-chip L2 cache, just like the Coppermine PIII's, and can run on the 100 MHz or 133 MHz GTL+ bus, just like the Coppermine PIII's.

    Skip ahead to the last week. PIII's are now rated as SMP (2-way only) capable. The Xeons being announced have SSE and on-chip cache, but the cache is (mostly) the same size as the old Katmai Xeons, namely 1 MB and 2 MB. I guess 512 KB is gone for good. Also, the new high-speed Xeons are capable of 8-way SMP, like the old Katmai and Deschutes Xeons.

    One interesting note on the stability and scalability of Intel's bus design (remember it's been in use for 5 years+) is that they have pushed a bus that started at 60 and 66 MHz to 133 MHz, but in order to allow SMP beyond 2-way they can't get above 100 MHz.

    GK

    Please note that I did this all from memory and with all the holes in my for eating and hearing and whatnot I'm surprised all my memory hasn't leaked out yet. Now warned, you may flame away.
  • The big advantage is not so much that the cache is larger, it's that the cache runs at full processor speed. In all non-Xeon Pentia (II/III), the L2 cache runs at half clock speed. The original P-IIs actually offered very little speed advantage over the PPro (which has a full-speed cache), even though they had higher clock speeds.
  • like amiga users n such

  • I thought it stood for Australian Soup Pot

  • And how can these CISC processors outstrip Sun's RISCs? I don't care how many mhz it runs at, the two just work differently.

    There are efficient ways to implement CISC; the most common is to break down CISC instructions into smaller RISC-ian operations that are easily pipelined. You might have an extra clock's latency for the decoding, or you might not, depending on architecture.

    The functional units that perform operations are the same. The cache and memory subsystems are the same. Processors tend to be bound by design tradeoffs in these or in the motherboard or in things like the register file size as opposed to by the instruction set.

    Short version: RISC and CISC are different ways of telling a processor to do the same things. CISC used to make scheduling harder. Now it doesn't.
  • Peterbilt and Kenworth are the more upscale brand of cross-country tractor-trailer trucks. Kenworth's web page [kenworth.com] has pictures and details.

    D
    ----

  • Pentium II was just a PPro with MMX.

  • Better to get the story from the horses mouth:
    Intel's press release [intel.com]

    Also interesting, someone on Pricewatch [pricewatch.com] claims to be selling 800mhz PIII Xeons [pricewatch.com] for only $814, so why bother with a wimpy 700mhz for $1,177+?

    -Tommy

    ------
    "I do not think much of a man who is not wiser today than he was yesterday."

  • Re:Sun doesn't need to worry about Xeons (Score:4)

    by The Man ( 684 ) on Monday May 22, 2000 @09:22AM (#1056058) Homepage
    You missed two.

    Sun's architecture is based on high-speed switches connecting multiple fast/wide PCI or Sbus buses. The peecee architecture is based on having one to four PCI buses on another shared bus. Suns have memory buses no less than 1152 bits wide. Peecees generally have 256-bit memory buses. Summary: Suns can move far, far more bits around inside them than any peecee server can. Sun 4, Intel 0. It should be noted that this isn't entirely Intel's fault, but they aren't really helping anyone do something non-peeceeish. You _could_ build a Sun-like system with Xeons, but nobody does.

    The peecee architecture is hopelessly obsolete. 16 bit bootstrap code. A BIOS. Forget boot monitors and intelligent peripherals, you know, things that make systems manageable and flexible (just try booting a peecee from tape - you can't - or over the network - that'll cost you extra). Both system architectures have their roots in the late 70s and early 80s. Sun started with a good design and have steadily improved and enhanced it. The peecee started with a poor design and have left it essentially unchanged for 20 years. Sun 5, Intel 0. Again, not all Intel's fault, but since there aren't really any other systems available using Intel CPUs, it counts against them anyway.

    Now, even with these drawbacks, I could see the Xeons being a good choice for a midrange server if they cost much less than the Suns. Unfortunately, the Xeons are actually more expensive than the UltraSparcs, even at the same clock and with the same size L2 cache. If you have $4k to blow, you can get either a Xeon 500 w/2MB, or an UltraSparc 450 with 4MB. And the UltraSparc is faster, too. Oops, guess that's 3. Sun 6, Intel 0.

  • From the original article:

    Gwennap noted that while Intel-based servers are becoming more of a competitive threat to Sun in the low-end of the market, Sun still reigns at the high end, with much larger configurations where companies are using 16 to 64 processors in a server.

    Intel is going after the low-hanging fruit first, so to speak. An Intel box is no match for Sun's high-end servers. Intel is eating away at Sun's UNIX market from the low end.

    It won't be too much longer before every engineer will have an Intel box instead of a Sun or HP box. Once Intel has that market wrapped up, they can then go after the high end.

    This is what Sun should be worried about. They wil lstill make good money in the high-end, but they need the low-end volume to really do well financially.

  • in this [yahoo.com] article,


    "In general, the server segment is extremely crucial to Intel," Ambrose said, though he added, "Clearly, the desktop
    market is much bigger."


    why is the server crucial? so they can keep desktop control?

  • The UltraSparc cpu can handle a much greater load without sweat than most other cpus.

    I think you're confusing the CPU and the OS. A CPU is not designed for higher or lower load. It always runs at 100%, regarless of whether there's load of 10 or nothing but the idle loop to run.

    Of course I agree with the main idea. Intel servers have a long way to go to catch the Sun servers, at least on the high end. This is totally different for the low-end servers, where you can get an equivalent Linux box for much cheaper.
  • CPU speeds keep advancing, but throughput is always the limiting factor. The P-Pro 200mhz is a real workhorse. Team it up with a speedy RAID-5 array, driven by a dedicated controller (the HP NetRAID rocks), and you've got enough throughput to saturate a 100mpbs network easily.

    Some servers need big CPU cycles, but for the average server, the P-Pro is smooth, cool (heat), and reliable.

    I'd take a dual P-Pro-200 over my 400mhz P-II any day.
  • I think you're confusing the CPU and the OS. A CPU is not designed for higher or lower load. It always runs at 100%, regarless of whether there's load of 10 or nothing but the idle loop to run.

    While not strictly the CPU, I would consider the design of the I/O system to be important for high load situations. PC hardware wastes huge numbers of CPU cycles on brain-damaged I/O interfaces and devices. The interrupt latency on common PC operating systems, such as Windows NT, is poor. Many device drivers are poorly written. The PC world seems to be stuck in the MS-DOS era of I/O system design, kludges piled on top of kludges.

  • If I can play Unreal Tournament on a Sun, I buy one tomorrow! :)

    More seriously, I wonder ...

  • Disclaimer: I used to work for Intel's server division, so I may be biased...

    Faster disk drives. Which Seagate and Quantum and IBM are responsible for...

    Yup. You see a noted difference when moving from an old Ultra-Narrow 5400 RPM drive to a brand new Fibre-Channel 10,000 RPM drive...

    Faster RAID controllers. Think Adaptec, maybehaps?

    Those help, but RAID controller speed doesn't affect overall speed as much as you might think. The biggest speed improvements for RAID controllers are: bus improvements (new 64-bit controllers,) interface improvements (Ultra-160 or Fibre-Channel,) more cache (Yes, 128MB of cache helps ALOT in Database applications,) and, more channels (it really helps to have your drives distributed among a few channels. That's why three-channel RAID controllers are so good.)

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

    Actually, the current limit on Intel servers is 64GB. One of the servers I supported when I worked at Intel was their OCPRF100. An eight-way behemoth that had 64 DIMM slots, each one capable of taking a 1GB PC-100 DIMM. The big problem is OS support. NT (including 2000 Adv. Server) only support 8GB (they claim more, but they're lying,) and most other high-end server OSes either peak at 8 or 16. 64-bit Linux doesn't have that limitation, but of course, it's only for use on the upcoming 'Itanium' processors. From what I've heard, Win64's limit will be 32GB, but that's just a rumor.

    The relevant thing from Intel would be to see vastly better I2O controllers. THAT is what would fill Sun's heart with fear...

    With current 64-bit, 66MHz PCI (528MB/s of bandwidth as opposed to 32/33 PCI's 133MB/s,) and the upcoming PCI-X (1GB/s+ bandwidth,) system bandwidth is improving. Combine that with gigabit ethernet, Ultra-320 and Ultra-640 SCSI, and in the next two years, bandwidth will no longer be an issue. (PCI-X, GigabitE, and Ultra-160+ all need I2O.)

    I just miss playing Quake 3 on that eight-way system...

  • Sun is winning in the big server market with upto 64 processors, what is Intel offering, are these 2/4/8 way limited processors, or are we just going to have to wait and see what sort of motherboards appear?

    Although Sun support up to 64 CPUs with the E10000, they're not all on one motherboard. Similarly, 64 CPU Intel servers (such as the Data General AV25000) will typically only use 4 CPUs per motherboard. Some newer configurations may use 8, but time will tell. The difference is that Sun have 64 CPUs in traditional SMP configuration. The Intel machines tend to have them in NUMA configurations.

  • I took an early version of this chip for a test run a few months ago. I don't have my notes with me, but the tests made enough of an impression on my a I can post most of my findings without them.

    - Mip mapping via 133 bus using software rendering. Obviously to get the true results I couldn't make any D3D or Open GL calls or anything. Verdict: Crap. I saw a 45% DECREASE than if I used the direct memory mapped XOX function call. Not suitable for games.

    - Real-time mirrored rendering of 3D object. I took a 14 call inverse-pixel image and "mirrored" it using standard calls. No dice. Unbelievably, it was a 22% slower than a Celeron! the image was 800x600 spinning cube at 16 bit color, btw.

    - Advanced scalar addition. I just ran calculations and the PIIIZ did okay here, better but not noticably so.

    - STL dissolve under standard Win32 API blit calls. Most of these caused the chip to lock, but a quick look at the memory registers show that the 5-10-20 register to be corrupt. Yup, you read that right ... A MATH ERROR. One that is worse than the flawed Pentiums, in fact. This chip will be a PR distaster.

    I will try and find my notes, I did alot more tests of this sorry piece of crap if you're interested.

    sw

  • 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. If they were to take the 10% most used instructions for x86s (which you would probably find were used 90%+ of the time) and implemented the processor again, you could probably get so much of a performance people would think its an entirely new brand of processor. (Please note, this last statement is based solely on a *vague* notion of what happens behind the scenes, don't take it as gospel. I don't pretend to be saying anything other than baseless theories). All this is before you have simplified all of those bas***d addressing modes. Once you've got rid of all of that unnecessary complexity, you can start to make it neater.

  • Re:Sun doesn't need to worry about Xeons (Score:1)

    by Anonymous Coward
    Sun doesn't have to worry, unless price/performance matters. See this link for the TPC benchmark results:

    http://www.tpc.org/new_result/ttpp.idc

    which shows the Xeon systems dominating the price/performance curve. I don't see any Sun systems, do you?

  • Your statement is ill-informed: SUN's 8MB is off-die. On die, UltraSPARC III has 64kB data cache, 32kB inst. cache, 2kB prefetch cache, anda 2kB write cache. Only the tags for the 8MB cache are on die. This is from ISSCC, but I don't know if the backside bus frequency is the same as the core. Doubtful. Don't know about G4.


    ---

  • So when are the SMP capable AMD chips going to come out (or did I just miss something)?

    AMD Athlons are based on the DEC^H^H^HCompaq Alpha EV6 bus. They are SMP capable. The AMD 750 chipset did not support SMP, however, nor does the VIA KX133 (IIRC). Chipsets and motherboards for SMP are coming -- Tyan has announced one for fall of this year.


    The Slashdot Sig Virus
    Hey, baby, infect me [3rdrockwarez.com]!
  • This seems very odd to me. Where I work (IT for Efficient Networks, Inc.), we just got a new (ughh) COMPAQ box with dual piii-xeons. But, we didn't get it today, we got it early last week....

    Seem odd to anyone?
  • 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...
  • Actually, for the market they're aiming the Xeons at, more cache is better. Server-class Sparcs often have 8 meg of cache per CPU. RDBMs are notoriously cache-hungry. By having Intel put the 2M cache on-die, they ensure that the Sparc has nothing to worry about from the Xeon.

    The 32-bit vr.s 64-bit is also a big problem. To balance CPU/memory/disk bottlenecks, you generally want about 1 gig of memory per CPU- so finding 12-16 gig of memory in a machine isn't unusual. And you want one process- the RDBM- to use _all_ of it (or at least most of it).
  • Now I know I could have the traditional beowolf cluster of these, but how many can I get in one box/board? As the article says Sun is winning in the big server market with upto 64 processors, what is Intel offering, are these 2/4/8 way limited processors, or are we just going to have to wait and see what sort of motherboards appear?

  • Interesting comment from the article (Score:2)

    by Anonymous Coward
    (ASPs), a market also targeted by
    Sun Microsystems Inc.

    I find this very intriguing - why would Sun be intent on targeting the ASP market? You'd think that with their focus on Java, they'd be much keener on simply convincing that market space to switch to JSP's or servlets, both of which would offer far superior performance on Sun servers.

    This seems very odd -- does anyone have any comments or explanations for this?
  • Not "Active Server Protocol", or whatever Microsoft wants everyone to think it means today.

    Keep in mind, Microsoft wants everyone to think DNS stands for "digital nervous system", too. Fuck that!

    - A.P.
    --


    "One World, one Web, one Program" - Microsoft promotional ad


  • 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.

    Not to be abtuse here, but I don't get your analogy. Straight line speed is one thing, data throughput is another thing. So I thought maybe you meant that while Sparcs are slower that the PIII, they typically come with better I/O infrastructures. I'm all set to agree with you there. After all IBM sells big iron on this argument alone.

    But then you said load, and I'm thinking maybe you meant straight line speed anyway.

    So could you clarify?
  • one thing that makes xeon better - indirectly of course - its its supporting chipset.

    more ram (usually more dimms on those mobo's) and a better dual or SMP processing engine.

    its pretty well-known these days that the [in]famous BX chipset falls down when both cpus run for extended periods of time at close to 100% saturation. the chipset overhead and freezes. even if you go to lengths to cool it, it still locks up.

    I'll never run smp on BX on a 7x24 system ever again. intel - I totally lost confidence in your smp abilities on the low- to medium-end compute boards.

    --

  • Pentium II was just a PPro with MMX.

    not exactly. the ppro could run 4-way smp, I believe. p2 and p3 are hard-limited to 2 cpus, max.

    --

  • Re:The RISC/CISC holy war. (Score:5)

    by Christopher Thomas ( 11717 ) on Monday May 22, 2000 @09:14AM (#1056097)
    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.
  • I'll try and kill two birds with one stone.

    jmv is more correct than I in that it isn't strictly the cpu which is designed to 'handle' the load. I should have been more clear in that regard.

    What I should have said is that both the cpu and the OS are designed to handle higher loads more efficiently. With Sparc cpus, task switching is aided by the Context registers built into the silicon. I am no hardware designer, so I couldn't say with any authority how x86 handles task switching.

    So, to answer one of the above respondents, by load I mean how many tasks a cpu is required to switch between, and how efficiently both the cpu architecture and the OS can do that.

    Don't think 'speed' when I say 'load'. Rather compare the ability of the machine to respond when the 'loadavg' starts approaching 1 or greater per cpu.
  • Dont forget that the Celerons 300a had 1 to 1 cache which helped alot in certain apps, like games.
  • change it to, "how the new Xeons nibble complacently upon Sun's ankles" :)
  • I've read that Intel is now using a hybrid RISC/CISC design for their processors. The idea is that the control unit is built around a RISC core that directly executes the simplest commands (ADD, MOV, etc). The more complicated commands are interpreted by a microprogram, much like in the older chips. The result is that compilers can be designed to make liberal use of this RISC-style instruction subset with some performance improvement, but older programs can still be run without software interpreters.

    I got this information from a textbook, not from Intel documentation, so I may be a little off. Anyone know more about this?

  • Pentium III Xeons not new, just 700 Mhz (Score:4)

    by mbherbener ( 23179 ) on Monday May 22, 2000 @07:48AM (#1056107)
    As the article says, Pentium III Xeons have been around for a while, but were topped out at 550 Mhz. This is just faster (and different layout, I think).
  • Pronouncing Intel's chip names make is so hard it goes for *everyone's* throat. Just saying "xeon" makes me want to hurl.
    --
    Have Exchange users? Want to run Linux? Can't afford OpenMail?

  • Re:What's the advantage? (Score:5)

    by lbrlove ( 164167 ) on Monday May 22, 2000 @07:53AM (#1056113)
    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
  • well-it's out. 700MHz isn't really going to turn that many heads, though, now that people get glassy eyes when they hear 1GHz. but it's really not fair to compare the two. the fastest UltraSPARC right now is what, 440MHz? again, it's not fair to compare that to a GHz p3. I think Intel and Sun's marketing departments need to make the distinction clear between their processors. I have seen people compare my 400MHz Ultra 10 at school by saying "oh, it's only 400mhz. i have a celeron 450, how much better is it than that sun?" now we all know that a 400MHz UltraSPARC flies. it's an incredibly fast processor. as such, sun is justified for charging enormous amounts. it's not the megahertz that matter. as such, i still wonder why intel would flaunt the fact that the new xeon is 700MHz, but yet advertise their GHz pentium. i say long live the 200mhz pentium pro.
  • I'm glad the Intel decided to drop the unique chip IDs. I'm much more likely to get one now, as I think are many others.

    What's everyone else's opinion on this?

  • Sun doesn't need to worry about Xeons (Score:5)

    by x0 ( 32926 ) on Monday May 22, 2000 @07:57AM (#1056121) Homepage
    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?

Slashdot Top Deals

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Close