HP3000-L Archives

May 2002, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Andrew Harrison SUNUK Consultancy <[log in to unmask]>
Reply To:
Andrew Harrison SUNUK Consultancy <[log in to unmask]>
Date:
Wed, 8 May 2002 07:31:46 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (163 lines)
Fred Kleinsorge wrote:

> Andrew Harrison SUNUK Consultancy wrote in message ...
>
>>
>>Fred Kleinsorge wrote:
>
>>>into account the tricked up compiler that caused the temportary "upgrade"
>>>
> of
>
>>>USIII speed).
>>>
>>>
>>
>>There you go again posting about something you don't understand.
>>
>>1. The optimisation used by Sun only effected SPECfp note that Bill
>>is talking about SPECint. Even you should be aware of the differences.
>>
>>
>
> It should beat Sparc using any measurment.  Heck, an old guy with a hand
> calculator will give it a good run for the money.
>


Thank you for the wonderfull technical response Freddy.

But lets be specific what measurement were you refering to, wafer

size. Tell us which measure you are sure IA-64 will beat SPARC
on ??


>
>>2, It wasn't a trick and if you think it was perhaps you could back up
>>your claim with evidence other than suppostion on your part.
>>
>>
>
> They tricked up the computer to beat a specific test.  It wont take long for
> everyone else to bite te bullet and add the same optimization to their
> compilers.
>


They tricked up the computer !!! What are you some sort of marketing
person. So far 0 techical content from dear old Fred now why am I not
suprised.

Sun released a new compiler which does a better job of optimising FP
applications, evidence of this is the improvement in Sun's SPECfp
results which mostly due to compiler improvements but also processor
improvements.

The Forte 7 compiler improves the performance of all 14 CPF2000
benchmarks used to measure the CFP result which is a geometric
mean of the results. In particular ART (Neural networks/image
processing benchmark) improved by a factor of 7.5 x but other benchmarks
such as EQUAKE (Seismic Wave Propagation) improved by 5.2 x, LUCAS
(Number Theory) 2.2 x, GALGEL (Fluid Dynamics) 1.6 x and APSI (Polutant
distribution) 1.5 x. The other 9 improved by an average of 28% rather
higher than the 17% clock hike of the CPU's.

Remember CPF2000 is the Geometric mean of the 14 results.

So which test did we "trick" ? Tricking one might cause for concern
tricking at least 5 less so or are you questioning the validity
of CFP2000 as a test at all. If you are remember that its virtually
the only measure that shows Alpha based systems in a good
light.


> There was no leap in hardware speed, and almost no user code will be faster
> because of the trick.
>


Well apart from the fact that we increased the clock speed from 900 to
1050 Mhz increased the size of the TLB cache and made a number of other
improvements then discounting all this you are right there was no leap
in HW speed. It was a combination of HW and Compiler (exactly what
you are hoping for from Mckinley).

This would be a more interesting contest Freddy if you had a clue what
you were talking about since you don't appear to, its less of a contest
and more of a blood sport.


>
>>>So IA64 systems will at minimum be performance competetive with USIII,
>>>
> and
>
>>>from what I understand will be priced much lower.
>>>
>>>
>>This would have been an interesting point had your previous ones been
>>correct since they were not it isn't :):)
>>
>>
>
> Alright, let's ignore the future, and talk about the present.  Why would
> anyone run slowaris on a uniprocessor Sparc when an IA32 is faster and
> cheaper?
>


Ask yourself the same question about Alpha. BTW the Slowaris jibe is
dumb since you havn't come up with any examples of Tru64 or OpenVMS
being faster have you.


> Eventually, even Sun users will wake up and smell the coffee.
>


If you are right then the same applies to Tru64 and OpenVMS on
Alpha/IA64.

Of course the real reason is that people buy systems for reasons
other than Performance and Price. They must do because if they
only used these criteria no one would have bought Tru64/OpenVMS
systems. In case you hadn't noticed on benchmarks that measure
price performance you are not first league players and never have been.

So to Sumarise

You are complaining about Sun improving its compiler performance
which is exactly what you hope for in McKinley.

You claim Solaris is slow without yet having managed to provide
comparative benchmark results to Tru64 and OpenVMS that show this.

You claim Sun cannot compete price performance wise with single
CPU x86 boxes. You seem unaware of the fact that Sun produces
a sub 1000 dollar Sun that does compete with x86 boxes and
at the same time the division of the company you work for does not
have a low end x86 competitor. While you are working on porting
OpenVMS and Tru64 to IA64 a platform which everyone knows
will not compete for the single CPU x86 market. Its too hot,
too expensive and too slow.

Not a good prospect for you Freddy with your CV whatever skills
you outlined in your resume didn't include NT/Win2000 which would
seem to be what you are destined to have to learn if your
predictions come true. I would get as many MS training courses as
your employer du jour will pay for under your belt.

Marvelous I hope this has been a usefull lesson to you
in your own company, benchmarks and why you should stick
to whatever you are good at and avoid what you are not.
You don't need to thank me for the career advice, from
the tone of your postings you appear to have reached the same
conclusion yourself.

Regards
Andrew Harrison

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2