🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #21566

Re: superscalar

#21566
From: aglew
Date: Sun, 04 Jun 1989 19:05
31 lines
2327 bytes
>[Brooks]
>Needless to say, when the application starts missing cache (for any of the
>microprocessors) the performance rapidly drops into a hole when compared to the
>classic supercomputer.  The microprocessor vendors now need to learn the last
>lesson in supercomputer architecture, which is getting adequate main memory
>bandwidth.  Since interleaving memory chips with glue logic would raise cost
>too much, the micro vendors need to get in close collaboration with the memory
>chip vendors to get the interleaving done on the memory chips themselves.  This
>may be a good way for the U.S. manufactures to get back into the memory chip
>biz.  Design your micro with interleave control on the chip and then design
>your memory chips that have a compatible arangement, then don't tell the
>foreign memory chip vendors about the micro/memory chip interface until you
>get to market.  Interleaving on the memory chip is not a difficult thing to do,
>one only has to decide that it is time to do it.

So, we're back to memory again. I hesitate to get involved, since we all 
heard Mark Johnson saying "Don't talk about, buy it!", to us intellectual
weenies who can only talk about things - but I can only talk about it for
the moment, so here goes:

Q:  how many processor chip vendors will be willing to tie themselves
    tightly into a memory manufacturer?  Well, there are some companies
    who do both...  but are you going to risk customers refusing to
    buy your processor chip because they have to use your memory chips
    with it?
Prediction: people will be very slow to get into tightly coupled 
    processor/memory.  But when they do, the processor companies will 
    probably put out both custom memory and non-custom memory processor
    chips - probably by last stage customization of the die. Ditto memory.
    This will probably be suboptimal.
Technical Details
Message-ID: <28200329@mcdurb>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!mcdurb!aglew
References: <26356@lll-winken.LLNL.GOV>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!mcdurb!aglew
From: aglew@mcdurb.Urbana.Gould.COM
Newsgroups: comp.arch
Subject: Re: superscalar
Message-ID: <28200329@mcdurb>
Date: 4 Jun 89 19:05:00 GMT
References: <26356@lll-winken.LLNL.GOV>
Lines: 31
Nf-ID: #R:lll-winken.LLNL.GOV:26356:mcdurb:28200329:000:1865
Nf-From: mcdurb.Urbana.Gould.COM!aglew    Jun  4 14:05:00 1989