4D/35 vs. 4D/3xx

Sam Fulcomer sgf at cs.brown.edu
Fri Jan 25 06:37:20 AEST 1991


In article <1991Jan24.164248.9291 at odin.corp.sgi.com> tj at merlin.asd.sgi.com (tj) writes:
>In article <113 at tcela.COM>, tak at tcela.COM (Michael Takayama) writes:
>>  
>> server configurations.  How do you justify 4D/3xxS compute servers vs.
>4D/35S 
>> compute servers given the price/performance discrepancies? 
>
>The answer is simple for performance. If all you are looking at is single 
>process performance with no concern for expandibility of VME, memory, etc
>then the 4D35S is a better buy than a 310S. Many of our customers do in fact
>create compute farms of many 4D35S. It is entirely dependent on your 
>application as to wether 8 4D35S or 1 4D380 is a better buy. Remember that 

Well, somebody please correct me if I'm wrong, but doesn't the 3x0 use the same memory
(arch.) as the 2x0? If so, then it's seriously max'd out on a 380. If you want to 
buy a 3x0 with the thought of upgrading to a faster machine down the road, then definitely
don't load the thing up with 3rd-party memory unless you've got some other machine to
dump it into later.

The 35 will, without doubt, be much less expensive to upgrade in view of the fact that
the tricked-up memory architecture will support a much faster processor (ie, your memory
will survive the upgrade). 

The main performance issue is memory utilization and cache size. The data/instruction cache 
sizes grew from 8k/16k on the 4D20 to 32k/64k on the 4D25. I would hope that the data
cache size on the 35 is 64k. That would bring it into line with the IP7 64k cache size.
A small data cache will hurt performance on computations using traditional memory access.
"block-mode"-style algorithms can improve a cache-machine's performance on big problems,
however once the run queue starts getting big the cache can still thrash. That's why the 
4D20 was such a pig.

So, what are the data cache sizes of the 35 and the 3x0?...

It's always been true that esd-type people have had a certain pressure to not produce
a too-versatile product. The typical result has been a smaller cache and limited i/o 
bandwidth. It's true that to a limited extent this reduces cost, however the main result  is
a machine less suited to a time-sharing environment. 

I'd have to say that the 3x0S really isn't an attractive option right now (for most people).
I'd rather buy a couple of 35's and ride out the inveitable new product announcements.
Of course, I could be completely wrong in my assumptions about the 3x0 memory architecture...



More information about the Comp.sys.sgi mailing list