Make Xeon faster than Itanium2 using SPARC

Hmm, an interesting technology.

Note this particular quote:

"Weigel asserted that QuickTransit performs well. Sparc-Solaris software generally runs faster on Xeon-Linux using Transitive's software than on machines with Sun's 1.5GHz UltraSparc IV+ chips."

Thanks to the Benchmarking Guru, we have some data showing that UltraSPARC IV+  outperforms Itanium2 again and again.

Therefore, using the transitive property in concert with Transitive's QuickTransit and similar logic, HP and Intel customers can "generally" replace their HP-UX Itanium2 servers with Linux Xeons running SPARC binaries.



One would think that a Solaris-SPARC to Solaris-X86 translator would be easier and a "good thing" for Sun to support. Transitive came in to my company a couple of weeks ago to demo this technology for us. As the Solaris Product Manager, I was concerned that the translation to Linux would reduce the viability of the Solaris-X86 ofering I'm trying to get internal support for. Is Sun working on something that will allow Solaris-SPARC to run on Solaris-X86 to try and keep customers on Solaris?

Posted by guest on August 19, 2006 at 03:13 AM PDT #

The general strategy for porting applications from Solaris SPARC to Solaris X86 is to:

  • Write your applications in Java (if possible) so porting is a moot point. While it may not be relevant for your situation, consider this relevant for other readers.
  • Re-compile your applications. This is how we release Solaris on SPARC and Solaris on X86 (and the non-Java applications that run on top of Solaris) simultaneously.

What is going to be better for customers in the long run, a native Solaris application running on Solaris X86 (on either XEON or the faster and more power efficient Opteron) or an emulated SPARC application on Xeon? Only your organization can answer that, and it's honestly not a loaded question. MainSoft made a business out of doing something similar to QuickTransit (and Solaris has BrandZ). If BTW, if you already have a Linux port of your applications, you could try leveraging BrandZ, which is lighter-weight than CPU emulation. I still prefer a native port, though.

I highly doubt applications will perform better on QuickTransit than a native application on Solaris on X86. Plus, when not running on Solaris on X86, customers cannot leverage ZFS, Zones, BrandZ, SMF, Dtrace, and all of the other innovations in Solaris 10. For example, are your potential customers interested in both application and server consolidation? How many emulated environments can they run on a Xeon versus native applications within lightweight Solaris containers? How can customers and your developers utilize DTrace in the emulated environment to rapidly get to a root cause \*in production\*? What about worldwide support and service?

Posted by John Clingan on August 19, 2006 at 04:22 AM PDT #,

What happened when you asked Transitive if they would offer their translator on Solaris for x86?

First, the only SPARC applications this solution applies to are custom code (ISVs would not support their app running in this manor), with no source code available (as John points out, if the source code exists, just recompile to x86 and you have a native app).

I think most agree, it would make more sense for someone wanting to run such a SPARC app on x86 via emulation, to do so on Solaris rather than Linux.

That said, there is likely a very good business case for Transitive on Solaris on x86 (perhaps a stronger case than for Transitive on Linux on x86).

Remember, it is up to Transitive to decide what platforms it provides its product on, not Sun. If they are not willing to provide their solution on Solaris on x86, you have to ask why. My guess is it is in other platform vendors strategic interests to get customers as far away from Solaris as possible, even if that means making that customer less successful.

Transitive seems more interested in IBM's and HP's success than in the success of Solaris customers.

Posted by Mark on August 20, 2006 at 12:15 AM PDT #

My answer from yesterday seems to have gotten lost, but here's another voice that says much the same as I do. From "" What I don't understand is why Sun is not providing an emulation layer for SPARC software on Opteron, like SGI and Apple are doing, just that the transition might become easier, and users of performance critical software can demand the portage of it. I think this would help a lot for the acceptance of Solaris/Opteron among workstation users.

Posted by Stephen Potter on August 22, 2006 at 06:07 AM PDT #

Post a Comment:
Comments are closed for this entry.

John Clingan-Oracle


« July 2016