Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Intel 8-way Chipset

Posted by ryuzaki0 on from the more-cpus-please dept.

VJ writes "Intel just announced their new 8 way SMP chipset for use with PentiumIII-Xeons. A summary of features: 3X100 buses (2 for CPU's, and 1 for I/O. (The chipset appears to function to some degree as a crossbar switch, between the three buses) Cache coherencey features allow better utilization of L2 cache, other stuff too..) We'll have to wait and see, but this might be a relatively cheap way to get raw CPU for enterprise environments.. (Relative to Sun or HP or SGI)"

8 of 84 comments (clear)

  1. OS/2 is the best OS for this machine by timur · · Score: 2

    OS/2 scales very well to 8 CPU's - way better than NT or Linux do. For years, OS/2 has been able to scale well to 16 CPU's.

  2. Instruction set doesn't matter for this. by Christopher+Thomas · · Score: 2
    Call me crazy, but won't this actually be slower? I mean, putting that many chips on the same bus ... even if you do sync in the manner they're talking about, that doesn't help much when you're working with large volumes of data


    This is correct. Intel seems to have made a half-hearted switch to a crossbar bus system, with the result that their bus can still be easily saturated. Programs that aren't memory-intensive will still benefit from the SMP. Programs that are memory-intensive will saturate the bus and leave many of the processors idle.


    It'll be good for Quake III, but I suspect anyone in the know will probably stick with a RISC design.


    Memory performance has nothing to do with whether the processor is RISC or CISC. Memory bus design is the only thing that matters here. Point-to-point implemented on a crossbar bus beats a shared bus no matter what chips are used.


    Getting back to the Holy War, most modern implementations of CISC are almost as efficient as RISC (look at the guts of the K7 design for an example). You wind up with an extra stage in your pipeline for decoding, and that's about it. RISC is generally favoured because there's no real reason to use CISC any more (higher code density isn't as vital), and removing CISC support simplifies chip design and optimization.


    The main problem with Intel chips is that they've been repeatedly extending a design that wasn't designed to be extensible, in a rather kludgy manner. They're still stuck with it, because if they switch to a completely new architecture they lose their installed base of customers. This is why the Merced still supports x86 modes.

  3. 32 GB on the MB and Linux by redwolf · · Score: 2

    Any idea how Linux will use this much main memory?

    A large ram disk for databases?
    A larger virtual address space?

    or better yet, a _huge_ addition for my "Little Computer People" house. =^]

    1. Re:32 GB on the MB and Linux by roystgnr · · Score: 2

      Any idea how Linux will use this much main memory?

      A large ram disk for databases?
      A larger virtual address space?

      It *won't* be a larger virtual address space. How would we do that? Use 64 bit pointers on a 32 bit architecture, and force everyone to recompile? Or use the God-awful segment/offset crap that Intel seems to have a fetish for, and still force everyone to recompile?

      Technically it would be possible to give 4GB... but it would be a hideous hack - NT will do it; Linus (and therefore Linux) won't.

      There's a patch in that will give databases access to "anonymous pages" of memory - I'm not sure how they get accessed, but apparantly it's in a fashion both Linus and the large DB makers are happy with.

      But damn it, I tried to program Win16 once, and I thank God Linus doesn't want to get bogged down in a segmented architecture more than necessary. If you want more than 32 bits of addressable memory, don't use a 32 bit machine, damn it!

    2. Re:32 GB on the MB and Linux by roystgnr · · Score: 2

      Sorry about the last post; forgot to escape the less than and greater than signs...

      Any idea how Linux will use this much main memory?

      A large ram disk for databases?
      A larger virtual address space?

      It *won't* be a larger virtual address space. How would we do that? Use 64 bit pointers on a 32 bit architecture, and force everyone to recompile? Or use the God-awful segment/offset crap that Intel seems to have a fetish for, and still force everyone to recompile?

      Technically it would be possible to give less than 4GB to each process, simply allowing multiple processes access to different 4GB chunks so that the total RAM used is more than 4GB... but it would be a hideous hack - NT will do it; Linus (and therefore Linux) won't.

      There's a patch in that will give databases access to "anonymous pages" of memory - I'm not sure how they get accessed, but apparantly it's in a fashion both Linus and the large DB makers are happy with.

      But damn it, I tried to program Win16 once, and I thank God Linus doesn't want to get bogged down in a segmented architecture more than necessary. If you want more than 32 bits of addressable memory, don't use a 32 bit machine, damn it!

  4. EV6 by tamyrlin · · Score: 2

    The EV6 bus used by Ahtlon and Alpha CPU:s is probably much better for SMP than Intel's bus.
    To begin with, the EV6 bus is clocked at 200 MHz whereas the Intel bus is clocked at 100 MHz.

    The EV6 bus is also a point to point architecture, not really a bus in fact. The drawback is that the motherboard is more difficult to design.

  5. Penguin Computing or VA Linux??? by crow · · Score: 2

    So when will we be able to order 8-way systems with this chipset from our favorite Linux hardware vendors?

    Penguin has been offering 8-way systems for a while using another chipset solution, but the price for those systems is over $100,000, while 4-way systems are more like $12,000, last I checked.

  6. So run MOSIX by SEWilco · · Score: 2

    OK, so run MOSIX so processes will the automatically scattered across the cluster.