Re: AMD vs Xeon 64 bit

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

--
http://www.freelists.org/webpage/oracle-l