Categories:

• General Questions
• QuickTransit Solaris™/SPARC®-to-Linux®/x86-64

General Questions

1. What does QuickTransit® technology do?
QuickTransit technology allows existing applications that are compiled for one processor/operating system (OS) pair to run on a different processor and OS without the need for any binary or source code changes.

2. How are QuickTransit products designed?
QuickTransit products are built around a modular architecture. At the heart lies an “Optimizing Kernel” that is shared across all products and all Instruction Set Architecture (ISA) combinations. A modular front end decodes the binaries and generates the Intermediate Representation, which is the abstract format used by the Optimizing Kernel. A back end instruction encoder generates and schedules the new code for the target platform. Different front-end and back-end modules support multiple combinations of source and target processor/OS pairs.

3. Can I run QuickTransit software alongside other applications?
QuickTransit is a normal user space application and can be run alongside any other applications.

4. Should I use a QuickTransit solution for my in-house developed applications or ISV applications?
QuickTransit works for both in-house developed applications and third-party applications.

5. Will my application work the same with a QuickTransit implementation?
For users there will be no change. The behavior and the look and feel of an application translated by QuickTransit products do not change in any way; it will work in exactly the same way as on the native platform.

6. Is QuickTransit a software solution or does it require specialized hardware?
QuickTransit technology is a pure software solution; no specialized hardware or devices are required.

7. How does QuickTransit compare to an emulator or interpreter?
QuickTransit technology is a Dynamic Binary Translator, not an emulator. It generates code on the fly to execute directly on a target platform and optimizes the frequently-executed code. It does not interpret individual instructions, so the result is much faster execution (near native) and low latency.

8. Is Transitive’s technology protected by patents?
Yes – Transitive’s software is covered by one or more of the US, UK and other patents and/or published patent applications as described in the Transitive Patent Portfolio.

9. Does QuickTransit technology generate a new application?
At no point is any extractable stand-alone binary generated. This approach results in improved performance, because it is designed to take advantage of dynamic optimizations specific to the current application and platform.

10. Can users tell that an application is being translated?
For the user, the application is transparent and in no way differs from a native one. For GUI apps the native window manager is used, and there is no container or SPARC desktop. Invocation and execution is the same as any native application.

11. Can I use a QuickTransit application inside a VMware or XenSource virtual machine?
Yes, as a user space application, QuickTransit runs inside virtual machines as long as the physical server and virtual machine support the QuickTransit® for Solaris™/SPARC®-to-Linux®/x86-64 and QuickTransit® for Solaris™/SPARC®-to-Linux®/Itanium requirements, (e.g. x86-64/EMT64 support).

12. Can translated applications work with native applications (and vice versa)?
In general the answer is yes. There are three cases:
1) Applications that communicate by exchanging files:
These will work as long as the data format is defined ‘endian-safe’ (which most are). For example, translated applications will produce data files that are exactly the same as when running on a SPARC machine. Therefore, if you can take a data file produced by the SPARC system and use it in your Linux/x86 application, it will work the same when the Solaris application is running translated.
2) Applications that communicate via sockets/networking:
Unix has a standard way of communication between applications.
It is intended to work between different machines with different endian characteristics. The application running translated and the native Linux application will work the same as if having the Linux server and SPARC server on the same network.
3) Applications that communicate via shared memory:
If applications share data via shared memory, both applications must be translated (or both could be native) in order to work. Due to the endian difference between x86 and SPARC, there is no “magic” way to support shared memory across architectures with different endian-ness (All data of translated memory is kept in SPARC endian-ness in memory).

QuickTransit Solaris™/SPARC®-to-Linux®/x86-64

13. How will the user install applications - will there be any differences?
Installation is done from the standard SPARC media. From within a SPARC shell the standard installer/scripts or RPMs can be executed.

14. What about the endian-ness differences between SPARC and x86?
All data on disk and in memory remains in the original SPARC endian-ness, so translated applications can share memory. All data files are directly compatible with a SPARC system and can simply be copied to the x86 server. No data conversion is necessary.

15. How do I maintain my application under translation?
The application can be maintained the same way as the SPARC port. There is no need for any x86 development tools or x86 debugging. A SPARC debugger can connect to the application under translation, so developers can debug a translated application the same way that they already do. In general, if a bug only occurs when running under translation, the OEM and Transitive will work together to fix it.

16. What about my license manager/licensing enforcement/copy protection?
License managers (e.g. flexLM) are translated along with the application. Users still require a license, just like on any SPARC system. The system will report the hostid of the underlying x86 system. The number of CPUs is the same as the underlying x86 system.

17. How long does it take to install QuickTransit?
QuickTransit requires the installation of two RPMs, which only takes a few minutes.

18. What are the requirements for a target machine?
The QuickTransit product itself has the following minimum requirements:
• 64-bit x86 processor (Intel or AMD) running in 64-bit mode
• Linux Red Hat AS 4 U3 or SLES 10 (running in 64-bit mode)
• 256MB RAM (also refer to Q23)
• 1GB available storage (for the Solaris environment and QuickTransit product)
Memory and storage requirements of the Solaris applications that are being translated need to be considered in addition to the above minimum requirements.

19. How much additional memory does QuickTransit need?
The QuickTransit software typically needs about 10-100MB of memory per translated application to cache the generated code, depending on the code segment size of the application. The memory requirement of the application that is being translated, generally used for application data, remains unchanged and needs to be considered in addition to the memory used by the translator.

20. Does QuickTransit technology support 64-bit binaries? What SPARC ISAs are supported?
32-bit and 64-bit binaries in SPARC V9, V8 and V8+ ISA are supported, including the VIS instruction extensions.

21. What kind of performance can I expect?
Because QuickTransit uses dynamic translation technology, applications typically run almost as fast as native ports. Translated applications running on the latest x86-based platform may perform at about 110% of the fastest UltraSPARC IV+(1.5Ghz). The performance advantage can be even greater – 200% to 400% – when compared to older models in the SPARC installed base (UltraSPARC III and UltraSPARC II). Translated applications are very responsive and there is no sluggishness, both in interactive use as well as networking and other I/O.

22. Does the translator need to be customized for my application? What software will run with it?
QuickTransit technology is a complete translator; all user space SPARC/Solaris applications will work, and the translator does not need to be customized for individual applications.
Exclusions are:
• Dependencies on proprietary Solaris kernel modules
• Solaris Real-Time extensions.
• Use of certain system administration features (e.g. Zones). These are only used by system administration/monitoring tools, for which native Linux versions should be used.

23. Can I run Java applications on QuickTransit?
Java (including JIT-based environments) is supported, including support for JNI (Java Native Interface) calls.

24. Which Solaris versions are supported?
QuickTransit Workstation and Server Editions supports Solaris applications built for Solaris 8 and above.
QuickTranit Legacy Edition support Solaris applications built for Solaris 2.5.1 and above.

25. Do I need any Sun libraries?
Transitive provides an entire Sun environment, based on Sun’s OpenSolaris. No license agreement with Sun is required.

26. What about executing shell scripts? Do I need to convert them to Linux shell scripts?
QuickTransit® for Solaris™/SPARC®-to-Linux®/x86-64 provides full support for the Solaris shell, which is translated by QuickTransit. The Solaris shell then executes the Solaris shell script and provides the necessary Solaris environment to make sure the script will work unmodified. No conversions of Solaris shell scripts are necessary.

27. What is the supported floating point precision?
Floating point operations are translated to native x86 format, so the same precision is achieved as a native x86 port of the application.

28. Does QuickTransit work with multiple CPUs/cores and threading?
All x86 CPUs and cores are available to translated SPARC applications. Atomic instructions and synchronization primitives are being maintained, so applications remain thread-safe. The same number of threads as on a SPARC machine will be created, so a translated multi-threaded application will scale the same way as a native x86 port.

29. Does QuickTransit technology require any Linux kernel modifications?
QuickTransit technology does not require any kernel modifications. It is a user-space application that works on the standard kernel supplied with Linux distributions