SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : Silicon Graphics, Inc. (SGI)
SGI 91.07-0.9%3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Justin Banks who wrote (4358)2/11/1998 12:43:00 PM
From: Patrick Gainer   of 14451
 
Justin Banks writes:
"My point was that two almost completely identical DG AViion systems
(on the 100GB db), went from 528.6 using Oracle 8.03 to 1135.7 using
Oracle 8.04. Because we're running 8.03, we can obviously expect a
similar speedup. That would put the same Origin @ 1718.6 on the
100GB DB. I'll not speculate on the 300GB results, as I don't think
it will be long until you'll see some.

Sorry I didn't explain myself well, but I think the numbers will
increase for SGI in much the same way that they did for DG when the
8.04 numbers are available. This would seem to indicate that the SGI
system is indeed faster."

I was confused at first by this message because I have done extensive
database performance work with several different database companies
and I have also done lots of hardware and OS performance work,
all in a previous life and I have NEVER seen a 100% increase in DBMS
performance, when moving from release x.y.z to x.y.z+1, especially
in a mature product. Then I went to the TPC web site and I noticed
the DBMS release wasn't the only difference between the two numbers
(528 and 1135). The higher number was also run on a machine with
processors having double the L2 cache size of the lower number.
So at the very least, one must admit it is not possible, from the
available evidence to conclude the Oracle code was solely responsible
for the increase and hence it is not likely that SGI will experience
a two times speedup changing only the DBMS source.

Further, it is fine to say you have no experience running tpc-d
but that is no excuse for a lousy number. When SGI ran their tpc-c
numbers with Informix, they had a huge amount of help and expertise
provided by Informix as Informix wanted the tpc-c numbers to look
as good as possible. Are you implying Oracle wasn't as interested
in what you produced? There was nobody from Oracle helping out?

And if scalability of these systems is such a selling feature,
why bother with 8-way numbers at all, especially if they aren't
very good? Why not do a 32-way number and blow everyone away?

Pat
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext