[BUGS] hardware changing time .. moving forward

[Peter Jeremy]

On Mon, Jan 28, 2008 at 10:19:35PM +1100, Andrew Reilly wrote:
>employee in our midsts!), I do remember there being some noise (before the 
>transfer of the Hudson fab to Intel) about a DEC/AMD deal in which AMD got 
>to use some Alpha bus technology.

Yes.  The Athlon-XP used the same bus technology as (ISTR) the EV6.

>  There was even talk of there being 
>low-end pin-compatible Athlon/Alpha motherboards (which never happened, as 
>near as I could tell...)

My recollections are the same.  I think the major problem was the death
of the Alpha - no-one wanted to put engineering effort into a dead CPU.
The other problem would have been the incredible power consumption of
Alphas - much higher than equivalent Athlon CPUs.

>Not sure how (or if) that relates to the HyperChannel point-to-point thing, 
>or the on-chip DRAM interfaces.  I don't think that any Alphas (except 
>perhaps the one in the Multia?) had those bits.

Definitely, the LCA (Multia) had on-chip DRAM controllers - I'm not
sure about the others.  EV7 was the first NUMA Alpha and I don't think
the AMD HyperChannel was derived from the Alpha.

On Tue, Jan 29, 2008 at 09:48:32AM +1100, Andrew Reilly wrote:
>On Tue, Jan 29, 2008 at 09:14:57AM +1100, Jerahmy Pocott wrote:
>> My experience with the Alpha, was that it had absolutely TERRIBLE  
>> floating point performance..
>
>How did you manage that?  Did you have all of the "precise
>exceptions" and "go slow" switches turned on?

Depending on what you did, Alpha FP varied from abysmally slow to
incredibly fast.  Whilst the Alpha supported IEEE754 floating point,
DEC were one of the major opponents of IEEE754 and never really
accepted the bits of IEEE754 that weren't part of the VAX FP.  In
particular, everything other than normalised numbers and zero had to
be emulated in software on the Alpha.  Combine the need for exceptions
to support full IEEE754 FP with imprecise exceptions and you have a
recipe for really poor performance (you need lots of exception barrier
instructions which force pipeline drains).  Some of the later Alphas
partially fixed this by providing precise FP exceptions.

>them any edge.  MIPS has packed-up and gone embedded.  SPARC
>is chasing multi-thread web-server benchmarks and has given
>floating point a rest for a while.

The T-1 was a bit of a disaster here - 8 integer cores and 1 FPU.  The
Niagara-2 (in the T5000 family boxes) fixes this with 8 FPU cores to
go with the 8 integer cores - though I haven't seen any figures on the
FP performance.

For that matter, SPARC is another example of an architecture that
is past its use-by date.  Branch-delay slots were a good idea when
DRAM cycle times matched CPU clock speeds but that hasn't been true
for about 20 years.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://mailman.barnet.com.au/pipermail/bugs/attachments/20080129/81faf753/attachment.bin