Re: [SUN] Throughput Computing
Paul Eggert <email@example.com> wrote in message news:<firstname.lastname@example.org>...[color=blue]
> Rich Teer <email@example.com> writes:
> > Throughput computing is a wonderful idea, but I think Sun
> > also needs to concentrate on CPU performance for applications
> > that don't fit the CMP model very well.[/color]
> But Sun has limited resources; they can't concentrate on everything.
> > I'm thinking of single threaded apps that are CPU heavy.
> > For example, compiling a large (single file) program.[/color][/color]
> If you want to motivate Sun to do fast single-threaded CPUs, you'll
> need to have a better argument than that.[/color]
Well, what about designing, simulating and verifying large
Or small ones, for that matter.
All the major DA/CAD tools for logic synthesis, placement, routing,
logic simulation, circuit simulation, and timing analysis are
single-threaded, operate on large amounts of data and are very
difficult to multithread (it's been tried many times for the
Very nearly all these tools have Linux ports and no chip development
companies I know of are purchasing SPARC HW or Solaris SW for compute
farms unless absolutely forced by >4GB process size. Needless to
say, you scramble like a SOB to structure your design so you don't
need that big process size.
(This could just as easily be Solaris x86, but NONE of these vendors
have Solaris x86 ports; apparently Sun has very successfully
It would be fairly fascinating to know how long the Sun HW design
groups will continue to "eat their own dog food" in their
compute farms; it is a 1.2-2.0X throughput disadvantage per
application license, when you compare a 2.8GHz P4 box against
a 1.2GHz USIII box. Big cache is the reason for some of the
the 1.2X numbers.
Yes, my Linux boxes require 2-3X the admin time compared to my
Solaris boxes, and it *pisses* me off that I have to deal with
that, but I don't see my company ever going back. Cost-effective
time-to-tapeout is what matters.