Re: AMD vs Xeon 64 bit
- From: James Foronda <James.Foronda@xxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 14 Sep 2006 19:03:20 -0400
Hi,
I sent this to the oracle-l list a couple of days ago but it has not
appeared. I just re-subscribed and I was told by Steve Adams that I can
post again. Apparently, my address was automatically unsubscribed as a
result of fatal bounce messages.
Anyway....
==============================================
Hi,
Just a few points/comments for this thread:
> I just advised a customer to replace their 16 cpu SUN sparc box with
> a 4 CPU dual core Opteron. The sun box was 1 million dollar, the
> opteron costed around 30K dollar.
Can you please let us know which Sun boxes you are referring to?
The Sun Fire E6900 would be close to this 16 CPU SPARC box described.
The E6900 can have up to 24 UltraSPARC IV+ processors. Price starts at
US$295,095 (very far from 1 million US$). Here's a pointer:
http://www.sun.com/servers/midrange/sunfire_e6900/index.xml
As for Opteron based servers, the Sun Fire x4600 can fit the description
above -- it can be configured with 4 dual core AMD model 884 CPUs. The
price of this configuration is US$25,995. See details here (look at
Small configuration column):
http://store.sun.com/CMTemplate/CEServlet?process=SunStore&cmdViewProduct_CP&catid=151018
Another Opteron-based server, the Sun Fire V40z can have up to 4 dual
core Opteron model 885 CPUs. Price is approximately US$28K. Here's a
pointer (look at the Extra Large configuration column):
http://store.sun.com/CMTemplate/CEServlet?process=SunStore&cmdViewProduct_CP&catid=116125
> But I can't understood why customers still buying HW based on RISC
CPU-s. There have to be something good about RISCs beside politics
> and good mng relationship with vendors' representatives. Can anybody
> advice ? (Anjo?)
Although I'm not an expert on SPARC chips, I have attended quite a lot
of our internal information sessions at Sun. One thing that I can
remember off the top of my head that I can freely share (i.e. no
non-disclusure) is that Sun's SPARC-based servers have the capability to
"blacklist" a failed component such as I/O, memory, or CPU. For the
UltraSPARC T1 chips (T1000 and T2000 servers), this blacklisting can go
to the processing thread level (it can blacklist a defective processing
thread WITHOUT blacklisting the entire core, let alone an entire CPU).
When a component is blacklisted, the server will operate in degraded
mode (i.e. reduced resources) but at least, it will know that those
components are defective and will no longer use them. As far as I know,
the Opteron chips do not have this blacklisting capability as of Solaris
10 Update 1. This feature is very important to some of our customers.
If this is important to you, I suggest you ask your Sun sales rep to
bring in a SPARC expert so that he can give you the entire story.
The SPARC servers also have more vertical headroom. For example, they
can be equipped with more CPUs and memory. One machine, the E25K,
starts at US$567,190 (still way below US$1 million) and it can be
configured with up to 72 dual core UltraSPARC IV+ processors for a total
of 144 processing threads on a single machine. It can take over 1TB of
memory. They also have availability features like replacing memory/CPU
while the machine is running. To some companies, these features
are important. Again, if you want a full treatment of the subject, I
suggest that you ask for a SPARC expert to come in and explain
everything to you. Here's a pointer to the E25K page:
http://www.sun.com/servers/highend/sunfire_e25k/index.xml
At the lower end of the SPARC spectrum are the CoolThreads servers using
the UltraSPARC T1 chips (code named Niagara). These chips can have up
to 8 cores with 4 parallel processing threads per core for a total of 32
processing threads per chip. Yes, 32 parallel processing threads on a
single chip. Some companies are running their databases on these
servers. Price starts at US$8,419. Here's a pointer:
http://www.sun.com/servers/coolthreads/t2000/index.xml
You can also run supported version of Ubuntu with the CoolThreads servers.
> Please don't tell me that is is about skills that particular customer
> have on board. There is no that significant difference between Linux
> and Unix.
For Solaris, there are very little differences when it comes to system
administration between Solaris SPARC and Solaris x86/64. I think it is
worth pointing out that Solaris SPARC and Solaris x86/64 are built from
a single source tree. If you are working at the database layer and you
don't deal with the storage layer, you may not even notice the
difference at all.
> Qs 3 Will moving to Opteron CPUs require RE-Compilation & porting of
existing Application Code?
If you are talking about moving an application from Solaris SPARC to
Solaris x64, the answer is that you will need to rebuild your
application in your target platform environment. IOW, Solaris SPARC and
Solaris x86/64 are *not* binary compatible. BUT as long as the
application follows some basic coding rules (e.g. using only published
interfaces, not talking directly to hardware layer, etc.), then it
should just be a matter of rebuilding the app. To a great extent,
applications built for Solaris should be compatible at the source code
level. IOW, you should be able to move between the Solaris SPARC and
Solaris x64 without too much trouble. Of course, this will not work if
you want to move a 64-bit Solaris SPARC application to Solaris x86
(32-bit). But the simple solution to that would be just to go to
Solaris x64. Again, the SPARC and x86/64 versions of Solaris are built
from a single source tree. This fact should be a good indication on how
the different Solaris versions are compatible with each other.
Once you are in a specific Solaris platform, Sun guarantees forward
*binary* compatibility even across OS versions (from Solaris 8 onwards,
if I'm not mistaken). Again, the application should not be using
unpublished interfaces for this to work. Sun has tools to scan binary
files to see if it is using problematic code.
> Moving from Sparc/Solaris to Intel/Redhat requires a change to the
> code (recompile/relink)
A simple recompile/link may be all that is needed for applications that
deal only with the database. However, if that same application makes
use of an OS feature that is not implemented in the same way in the
other platform (e.g. different API), then the code has to be modified.
When we migrate applications from other platforms (like Inter Redhat) to
Solaris, we scan the source code of that application with a tool that
flags these potential issues. My experience is that the vast majority
of Pro*C type of apps just compile without any problems. But I have
seen a couple of Pro*C apps that make use of platform-specific features
and we had to port those calls to Solaris-specific calls.
> ANY COMPARATIVE COMPUTING POWER, COST FIGURES OF OPTERON VERSUS SPARC
> CHIP machines from SUN?
We have something at Sun that can tell you comparative computing power
but I'm not sure if I can share it with you (non-disclosure stuff). I
think your best bet is to call your Sun sales rep and ask him this
question. Similarly, if you are considering other vendors like HP or
IBM, you should ask them if they can give you access to product
specialists so that you get definite answers to your questions.
If published benchmark numbers satisfy you, you can take a look at the
SPEC benchmarks at http://www.spec.org.
But nothing beats running your entire application stack on a server that
you might be considering. Depending on where you are based, you might
be able to take advantage of Sun's "Try Before You Buy" program. This
is a program where Sun will ship you a server and you can play with it
for 60 days. If you are not satisfied, send it back and Sun will pay
for the return postage. Details: http://www.sun.com/tryandbuy/
HTH.
James
http://jforonda.vintarinian.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
