“Sun Microsystems has gone totally native. Customers can now run unmodified SPARC/Solaris applications on x86 systems thank to a partnership with Transitive. The two companies also plan to craft a new package for running native x86 applications on SPARC machines. Transitive this week announced that the long in beta QuickTransit for Solaris code has moved into production form. It even gets a Solaris Ready Logo and all.”
This is great progress, but I think the performance hit is a bit too much to tempt me at this stage. There are a few areas I could definately use this, so I’ll watch this over time with much interest.
I’ll even give it a shot to investigate compatibility.
Certainly a JIT approach can be useful if you’ve got a machine around and you want to run a non-native app. But it’s never going to be a first-choice option, it’s more like an option you would choose if you’re stuck with an incompatible processor or an incompatible app. Native execution is always going to be better, unless you have an app for such an old architecture that, even with the JIT performance penalty, your new machine can still run it faster.
And that might even be the case for your old Solaris/SPARC apps. We’ve got plenty of old, underpowered SPARC hardware around here.
One place this will definitely be useful is for sales demos. This technology will allow SPARC-based products to be demonstrated using fairly standard laptops. Current solutions are more problematic; porting to Solaris x86 (which may be complicated by third party software availability), transporting a small SPARC server (even a SPARCbook may be difficult if the salesperson also needs a separate laptop), or using a remote server (prospective customer’s firewalls can create substantial problems).
Its actually for x86-64 systems. A small quibble.
The quote is confusing because on the first part you state that SPARC applications running on x86, and then in the second part of the quote it says x86 applications running on SPARC – which one is it?
Admittedly, the way the text was quoted for the summary was suboptimal. It’s actually referring to two separate announcements:
1. Now – A QuickTransit package is available that enables you to run “unmodified” Solaris SPARC binaries on the Solaris x86 platform. This package was in beta until recently.
2. Later – It is intended to develop a QuickTransit package that enables you to run (presumably also “unmodified”) Solaris x86 binaries on the Solaris SPARC platform. This is in the planning/early development stages.
I hope that clears things up.
They’re just constructing layers of code that takes up valuable memory and processor resources. Same goes for virtualisation, etc. If the software vendor cannot provide native versions of their binaries for a particular platform (there aren’t that many, for Solaris the choice is x86/64 and Sparc), well they can go to hell. The more turd you pile up on top of your OS, the more bugs and bloat you have to deal with.
Valuable memory and processor resources? What computer resource is cheaper than CPU cycles and RAM these days?
Lots of enterprise customers are running important SPARC apps that continue to make them money…. but will never be ported to another OS (i.e. the original vendor went out of business, or the source code is otherwise unavailable). This is a way to let them get on new hardware (i.e. quad-core multi-socket x86 systems, still comparatively cheap compared to SPARC gear)… and even if they lose some efficiency it will likely still run at the same speed (or faster) since x86 has a price/performance advantage.
This is just a tiny step closer to the day when any program will run on any hardware.