THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Joe Chang

HP ProLiant DL980-Oracle TPC-C Benchmark spat

The Register reported a spat between HP and Oracle on the TPC-C benchmark. Per above, HP submitted a TPC-C result of 3,388,535 tpm-C for their ProLiant DL980 G7 (8 Xeon X7560 processors), with a cost of $0.63 per tpm-C. Oracle has refused permission to publish.

Late last year (2010) Oracle published a result of 30M tpm-C for a 108 processors (sockets) SPARC cluster ($30M complete system cost). Oracle is now comparing this to the HP Superdome result from 2007 of 4M tpm-C at $2.93 per tpm-C, calling the HP solution a clunker. The SPARC cluster is comprised of 27 nodes. Each node is 4 socket, 16-core (64 cores total) with 8 threads per core (512 logical processors total) and 512GB memory. The complete cluster is comprised of 1728 cores and 11,040 x 24GB SSD drives.

Microsoft wants system vendors to move the newer TPC-E benchmark. A ProLiant DL980 or any 8-way Xeon 7500 TPC-E results other system vendors would be good to see. Oracle has not published any TPC-E benchmark result. The rumor mill has it that Oracle on a single system runs TPC-E just fine. The problem is believed to be that Oracle RAC cannot scale on TPC-E to degree desired by marketing (even if it is ok by technical standards).

Published Saturday, March 12, 2011 12:39 AM by jchang

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Jimmy May @aspiringgeek said:

What, a rumor regarding mitigated scalability of Oracle? ;-)

March 12, 2011 2:17 AM
 

anonymous said:

"Oracle has refused permission to publish"

No surprise there. Esp with crap SUN hardware.

Finding your recent acquisitions hard to fake results for Larry?

Just do what you do with other business units: charge more and perform less

March 14, 2011 2:20 PM
 

jchang said:

In theory, maximum throughput from a single die is achieved with many simple cores instead of fewer faster cores. This follows from Moore's law. Each doubling of transistor budget (die area) should lead to 1.4X performance on a single die.

Furthermore, for b-tree operations emphasizing serialed memory accesses, multi-threads per core is also a big gain.

Based on this, the Sun approach is best. However, for other applications that cannot be easily distributed over very many threads, the really fast core approach is best. So what is best overall? I am thinking it would be good to have both really fast cores, and very many small cores. I am not sure whether this should be on a single die, or to have a multi-scoket system that can take a mixed of fast and many.

Sure, we all know not to take marketing material to seriously, from any vendor. But for that big yacht, and other toys, I would probably sell out too.

March 15, 2011 2:44 PM
 

anonymous said:

"I would probably sell out too."

then your "advice" becomes worthless

March 16, 2011 4:21 PM
 

jchang said:

ok, I definitely would. If you want to trust the guy who swears on his mother's apple pie, that he will not lie, even for all of Larry's money, then that's your judgement

March 16, 2011 10:49 PM
 

Glenn Berry said:

It is pretty hard to put too much stock in in the opinions of someone who makes anonymous comments.

March 17, 2011 12:07 PM
 

jchang said:

March 23, 2011 12:47 PM

Leave a Comment

(required) 
(required) 
Submit

About jchang

Reverse engineering the SQL Server Cost Based Optimizer (Query Optimizer), NUMA System Architecture, performance tools developer - SQL ExecStats, mucking with the data distribution statistics histogram - decoding STATS_STREAM, Parallel Execution plans, microprocessors, SSD, HDD, SAN, storage performance, performance modeling and prediction, database architecture, SQL Server engine

This Blog

Syndication

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement