[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Positioning the Alpha processor



Greg Lindahl wrote:

> > and arguably in performance/price (can you find
> > a single benchmark
> > which proves this wrong- which doesn't need large memory?);
>
> I can think of numerous parallel programming situations where the highest
> performing processor  coupled with less than perfect scaling (due to load
> imbalance or other factors) leads to the Alpha being a big price/performance
> winners.

Okay, let me clarify.  If your performance measure is a nonlinear function of runtime
then I could see this (e.g. 6 hours is twice as good as 9 because an engineer working
an eight-hour day can make two runs with lessons from the first incorporated into the
second; weather modeling is also very time-sensitive).  Also, when "price" only
measures system cost and not, say, cost of the operator's labor as they sit and wait
for the program to run, then this biases toward the low end; accounting for all costs
can make the high-end machine look significantly better, more so with increasing
machine load.  But this is more of what I meant by the "raw performance" measure.

If a 21264 box is twice as fast but costs four times as much as an Athlon box with the
same memory, etc., then just get one Athlon and run it for twice the time and you've
beat the 21264's performance/price by a factor of two.  If the program can be run
across two or three Athlons then all the better for an Athlon cluster's "raw
performance".  But even if not, if your price measure is linear in system cost and your
performance measure inverse-linear in runtime, I don't think you'll find a new Alpha
system beating a new Intel/AMD system on any benchmark- exept for...

> Other customers need efficient 64-bit integers and not necessarily large
> memory.

Good point, I can see Alpha doing significantly better here.

I used to put dense linear algebra in this category too, but with ATLAS on even a
PIII-450 getting about half the performance of Goto's hand-tuned assembler BLAS on
LX164-600 (which is only marginally slower per clock than 21264), and with the
availability of fast 3DNow!-based assembler BLAS on Athlon (1.5-2 flops/clock, like
Goto's), and with Altivec instructions giving PPC G4s a boost here (at least for
single-precision: 2 flops/clock sustained, 8 flops/clock "theoretical max", or so they
claim:-), Alpha seems to have lost this battle too.

If you find a flaw in this reasoning, please let me know!

Iso-H wrote:

> On Thu, 26 Oct 2000, W Bauske wrote:
>
> > Iso-H wrote:
> > >
> > >    eventually: "high end" == "dead end"
> > >
> >
> > What makes you think that? Even Intel/AMD want a piece of the
>
>   Oops, I actually meant: "high end without low end".

Right, this is my point too.  Thanks for clarifying.

-Adam P.

                 Welcome to the best software in the world today cafe!





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []