Binary recompilation and task assignment method and device for asymmetric multi-core processor

Abstract

The invention discloses a binary recompilation and task assignment method and device for an asymmetric multi-core processor. The method comprises the steps that a computing device receives a starting request of an application program through a scheduling service; the computing device determines, using a scheduling service, whether the application is using a first instruction set architecture (ISA for short) or a second instruction set architecture. The computing device, upon determining that the application program uses the second instruction set architecture, determines whether the application program is of a compute-intensive type or a non-compute-intensive type. The computing device, upon determining that the application is computationally intensive, performs binary recompilation to convert application instructions based on the second instruction set architecture to instructions based on the first instruction set architecture. The computing device executes instructions based on a first instruction set architecture on one or more cores supporting the first instruction set architecture.

Description

Technical Field

[0001] The present disclosure relates generally to computing devices and, more particularly, to binary recompilation and task scheduling techniques for asymmetric multi-core processors.

[0002] Cross-references

[0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This application claims priority to U.S. Provisional Application Serial No. 63 / 513,903, filed on July 17, 2023, entitled “Binary Recompilation and Task Dispatch for Asymmetric Multi-core Processors,” which is hereby incorporated by reference in its entirety. Background Art

[0005] Asymmetric multicore processors (AMPs) have become increasingly popular in recent years, especially in mobile devices and embedded systems. These processors combine high-performance cores (big cores) with energy-efficient cores (small cores) to achieve a balance between performance and power consumption. Traditionally, the big and small cores in an AMP system support the same instruction set architecture (ISA), allowing the operating system to seamlessly migrate tasks between cores based on workload requirements and energy constraints.

[0006] However, as the demand for higher performance and improved energy efficiency continues to grow, chip designers have begun to explore new AMP configurations. One trend is the introduction of asymmetric 32-bit systems-on-chip (SoCs), in which the big cores support only 64-bit instruction set architectures, while the small cores support both 32-bit and 64-bit instruction set architectures. The motivation for this design choice is that supporting traditional 32-bit instructions on high-performance cores can increase the area, power consumption, and complexity of the chip. By limiting the big cores to only 64 bits, designers can optimize their performance and efficiency.

[0007] Challenges arise when running traditional 32-bit applications on these asymmetric 32-bit SoCs. Since the big cores do not support 32-bit instructions, these applications are restricted to running on the small cores, which may not provide the required performance level. This can lead to a significant degradation of the user experience, especially for compute-intensive applications such as gaming or media processing. Summary of the invention

[0008] The following briefly introduces one or more aspects in order to provide a basic understanding of these aspects. This summary is not an extensive overview of all potential aspects and is intended to neither identify the key or core elements of all aspects nor define the scope of any or all aspects. Its sole purpose is to serve as an introduction in a simplified form to introduce some concepts of one or more aspects in preparation for the more detailed description that follows.

[0009] In one aspect of the present disclosure, a method, a readable computer medium, and an apparatus are provided. The apparatus may be a computing device. The computing device receives a launch request of an application through a scheduling service. The computing device uses the scheduling service to determine whether the application uses a first instruction set architecture or a second instruction set architecture. After determining that the application uses the second instruction set architecture, the computing device determines whether the application is compute-intensive or non-compute-intensive. After determining that the application is compute-intensive, the computing device performs a binary conversion to convert application instructions based on the second instruction set architecture into instructions based on the first instruction set architecture. The computing device executes instructions based on the first instruction set architecture on one or more cores that support the first instruction set architecture.

[0010] To accomplish the above and related ends, one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The accompanying description and drawings set forth in detail certain illustrative features of one or more aspects. However, these features are indicative of but a few of the numerous ways in which the principles of the various aspects may be employed, and this description is intended to include all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is a diagram showing a computing device that includes hardware components and software components.

[0012] Figure 2 is a diagram showing a computing device executing software on processors that include large cores and small cores.

[0013] Figure 3 It is a flow chart illustrating a method (process) of dispatching an application to the appropriate execution path based on its instruction set architecture (ISA) and computational requirements.

[0014] Figure 4 is a diagram showing another computing device executing software on processors including large cores and small cores.

[0015] Explanation of symbols

[0016] 100, 200, 400 charts

[0017] 300 Flowchart

[0018] 102 Computing Devices

[0019] 112 64-bit processor

[0020] 122 System ISA

[0021] 124 64-bit User ISA

[0022] 126OS

[0023] 128 64-bit system calls

[0024] 132ISA binary translation component

[0025] 134 32-bit User ISA

[0026] 136Binary recompilation components

[0027] 138 32-bit system calls

[0028] 180 32-bit applications

[0029] 202, 402 computing device

[0030] 210 Dispatch Service

[0031] 220 Execution Service

[0032] 222 Execution Service A

[0033] 224 Execution Service B

[0034] 226 Execution Service C

[0035] 230, 232, 234, 236, 430, 432, 434, 436 applications

[0036] 260, 460 asymmetric multi-core processors

[0037] 262-1, 262-2, 462-1, 462-2 large core

[0038] 264-1…264-6, 464-1…464-6 small core

[0039] Operations 302, 304, 306, 308, 310, 312

[0040] 410 Dispatch Service DETAILED DESCRIPTION

[0041] The following detailed description and attachment Figure 1The detailed description includes specific details in order to provide a thorough understanding of the various concepts. However, for a skilled person, these concepts can be practiced without these specific details. In some cases, in order to avoid obscuring these concepts, known structures and components are shown in block diagram form.

[0042] Several aspects of telecommunication systems will now be introduced with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, components, circuits, processes, algorithms, etc. (collectively referred to as "elements"). These elements may be implemented using electronic hardware, computer software, or a combination of both. Whether these elements are implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0043] For example, an element, any part of an element, or any combination of elements may be implemented as a "processing system" comprising one or more processors. Examples of processors include microprocessors, microcontrollers, graphics processing units (GPUs), central processing units (CPUs), application processors, digital signal processors (DSPs), reduced instruction set computing (RISC) processors, systems on chips (SoCs), baseband processors, field programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, independent hardware circuits, etc., as well as other hardware suitable for performing the various functions described in the present disclosure. One or more processors in a processing system may execute software. Software should be broadly understood as instructions, instruction sets, program codes, program code segments, program program codes, programs, subroutines, software components, applications, software applications, software packages, routines, subroutines, objects, executable files, threads, programs, functions, etc., whether referred to as software, firmware, middleware, microprogram code, hardware description language, or others.

[0044] Therefore, in one or more example aspects, the functions described can be implemented in hardware, software, or a combination of the two. If implemented in software, these functions can be stored or encoded as a computer-readable medium on one or more instructions or program codes. Computer-readable media include computer storage media. The storage medium can be any available medium that a computer can access. For example, and not by way of limitation, such a computer-readable medium can include a random access memory (RAM), a read-only memory (ROM), an electrically erasable programmable ROM (EEPROM), optical disk storage, magnetic disk storage, other magnetic storage devices, a combination of computer-readable media of the above types, or any other medium that can be used to store computer executable program code in the form of instructions or data structures that can be accessed by a computer.

[0045] Figure 1 100, illustrating a computing device 102 including hardware components and software components. In particular, the hardware components include one or more 64-bit processors 112, capable of executing 64-bit instructions. The hardware components also include a system call binary translation component 136 and an ISA binary translation component 132. The software components include an operating system (OS) 126.

[0046] The 32-bit application 180 is written using a 32-bit user instruction set architecture (ISA) 134 and makes 32-bit system calls 138. To enable the 32-bit application 180 to run on the 64-bit processor 112, the computing device 102 includes an ISA binary translation component 132 that translates the 32-bit user ISA 134 into a 64-bit user ISA 124, and a system call binary translation component 136 that translates the 32-bit system call 138 into a 64-bit system call 128.

[0047] Additionally, OS 126 runs on 64-bit processor 112 using system ISA 122. OS 126 manages the execution of recompiled instructions and system calls, and interfaces with system ISA 122, which interacts directly with hardware components 104, including 64-bit processor 112.

[0048] When a 32-bit application 180 is launched, the ISA binary translation component 132 converts the 32-bit user instructions into 64-bit user instructions that can be directly executed on the 64-bit processor 112. Likewise, when the 32-bit application 180 makes 32-bit system calls 138, the system call binary translation component 136 converts these into 64-bit system calls 128 that the OS 126 can handle.

[0049] This binary translation occurs at the process level in user space. As the binary translation component converts the system calls and instructions of the 32-bit application into a 64-bit format, the OS 126 perceives and treats the 32-bit application 180 as a 64-bit application. Therefore, the OS 126 schedules the recompiled 32-bit application 180 to run on the 64-bit processor 112.

[0050] Binary translation involves converting 32-bit instructions to 64-bit, mapping 32-bit registers to 64-bit registers (which may require using 2 registers in 32-bit mode to hold 64-bit values), and converting 32-bit system call numbers and parameters to their 64-bit equivalents. This allows legacy 32-bit applications to take advantage of the performance of 64-bit processors, especially high-performance cores in asymmetric multi-core systems, without recompiling the application.

[0051] Asymmetric multicore processors (AMPs) are becoming increasingly common, especially in mobile devices and embedded systems, due to their ability to provide higher performance and lower power consumption than homogeneous multiprocessors. In a typical AMP configuration, such as ARM's big.LITTLE architecture, the system includes a mix of large high-performance cores (big cores) and small energy-efficient cores (little cores). Traditionally, both big and little cores support the same instruction set architecture (ISA), allowing the operating system to transparently migrate processes between cores based on performance and power requirements.

[0052] However, as the demand for higher performance and energy efficiency increases, chip designers are exploring new AMP configurations. One trend is the introduction of asymmetric 32-bit SoCs, where the big cores support only 64-bit ISAs, while the small cores support both 32-bit and 64-bit ISAs. The motivation for this design choice is that supporting traditional 32-bit instructions on the high-performance cores would increase the area, power consumption, and complexity of the chip. By limiting the big cores to only 64 bits, designers can optimize their performance and efficiency.

[0053] The problem arises when running traditional 32-bit applications on these asymmetric 32-bit SoCs. Since the big cores do not support 32-bit instructions, these applications are restricted to running on the small cores, which may not provide the required performance level. This can lead to a significant degradation in the user experience, especially for compute-intensive applications such as games.

[0054] To alleviate this problem, binary translation is used to convert 32-bit instructions into 64-bit instructions, enabling these traditional applications to run on high-performance large cores. This translation occurs at the process level in user space and involves two main components: the ISA binary translation component and the system call binary translation component. The ISA binary translation component converts 32-bit user instructions into 64-bit user instructions, while the system call binary translation component converts 32-bit system calls into their 64-bit equivalents.

[0055] For example, the computing device 102 solves this problem through binary recompilation. The instruction set architecture (ISA) binary recompilation component 132 recompiles 32-bit user instructions into 64-bit instructions, and the system call binary recompilation component 136 recompiles 32-bit system calls into 64-bit system calls. This allows 32-bit applications to take advantage of the big core to achieve higher performance.

[0056] Challenges arise when running traditional 32-bit applications 180 on an asymmetric 32-bit system where one or more 64-bit processors 112, or big cores, only support a 64-bit ISA. Traditional approaches restrict these applications to run on small cores, resulting in performance issues due to the limited processing power of the small cores.

[0057] One way to solve this problem is to recompile the 32-bit application to a 64-bit architecture. However, since source code for all applications is not available, this may not always be possible.

[0058] Another approach is binary recompilation, which recompiles instructions from the 32-bit user ISA 134 to the 64-bit user ISA 124, allowing 32-bit applications 180 to execute on a 64-bit processor 112. However, not all instructions can be recompiled offline. Some instructions rely on runtime information, such as interrupt branches or dynamically generated program code, making it impossible to recompile them in advance. This limitation makes runtime recompilation necessary, which may introduce additional overhead due to the real-time nature of the recompilation process.

[0059] For example, the process of recompiling instructions during execution may incur additional overhead compared to executing native instructions. The behavior of emulating certain 32-bit instructions on a 64-bit architecture may introduce additional computational steps. Recompiling system calls 138 from 32-bit format to 64-bit format involves overhead in mapping parameters and handling differences in system call conventions.

[0060] Figure 2 2 is a diagram illustrating a computing device 202 executing software on a processor 260 including large cores 262 - 1 and 262 - 2 and small cores 264 - 1 through 264 - 6 . The computing device employs a scheduling service 210 and an execution service 220 to efficiently run an application 230 on the asymmetric multi-core processor 260 .

[0061] The scheduling service 210 receives application requests and determines the appropriate execution path based on the application's instruction set architecture (ISA) and computing requirements. When an application launch request is received, the scheduling service 210 checks whether the application uses the new 64-bit ISA or the old 32-bit ISA.

[0062] For applications using the new 64-bit ISA, such as application 232, the scheduling service 210 passes the application information (e.g., application name, archive path) to the execution service A 222. The execution service A 222 then forks a new child process or selects a pre-forked child process that loads the application data and initializes itself to run the application 232 on the large cores 262-1 and 262-2 or the small cores 264-1 to 264-6, depending on the scheduling policy of the operating system.

[0063] For applications using the old 32-bit ISA, the scheduling service 210 determines whether the application is CPU-bound or non-CPU-bound. Non-CPU-bound applications, such as application 234, are typically I / O-bound or lightweight and do not require significant computing power. In this case, the scheduling service 210 passes the application information to the execution service B 224, which forks a new child process or selects a pre-forked child process to run the application 234 directly on the small cores 264-1 to 264-6 using the old 32-bit ISA. This approach avoids the overhead of binary recompiling for applications that do not need to run on the big cores to gain performance benefits.

[0064] On the other hand, CPU-limited applications using the old 32-bit ISA, such as application 236, are dispatched to execution service C 226. Execution service C 226 uses binary recompilation to convert the 32-bit ISA of the application to the new 64-bit ISA, enabling it to run on the big cores 262-1 and 262-2 or the small cores 264-1 to 264-6. This allows CPU-limited application 236 to take advantage of the higher performance provided by the big cores, even if it was originally written for the old 32-bit ISA.

[0065] The decision to binary recompile CPU-bound applications is based on the trade-off between the performance gain of running on a big core and the overhead introduced by the recompilation process. In some cases, the performance of a big core can be 3-4 times higher than a small core, while the overhead of binary recompilation is usually around 10-20%. Therefore, even with the recompilation overhead, running a CPU-bound application on a big core after binary recompilation can achieve 2-3 times performance improvement compared to running directly on a small core.

[0066] Scheduling service 210 may employ various policies to determine whether an application is CPU-bound or non-CPU-bound. These policies may include using static whitelist or blacklist application signatures, collecting runtime configuration results, or training artificial intelligence (AI) models to make scheduling decisions based on application characteristics and historical data.

[0067] When the execution service (A 222, B 224 or C 226) receives the application information, it forks a new child process or selects a pre-forked child process. The child process then loads the application data and initializes itself to run the application on one of the processors 260. The selection of the big core 262 or the small core 264 depends on the requirements of the execution service and the application. For example, the execution service C 226 using binary recompilation can run on the big core 262 or the small core 264, because both support 64-bit ISA after recompilation.

[0068] The selection of the big core 262 or the small core 264 to execute the recompiled application depends on the scheduling policy of the operating system. The operating system manages the execution of tasks on an asymmetric multi-core processor by using CPU affinity masks. These masks determine which tasks can be scheduled on the big core or the small core.

[0069] In this example, the scheduling service 210 determines whether an application requires binary recompilation based on its instruction set architecture (ISA) and computing requirements. However, the actual work of scheduling the recompiled application to a specific core is handled by the operating system 126.

[0070] When Execution Service C 226 runs a recompiled 32-bit application using a 64-bit ISA, it creates a child process that is treated as a 64-bit application by the operating system 126. The operating system 126 is then responsible for scheduling this child process to either the big core 262 or the small core 264, depending on factors such as the current system load, power requirements, and the performance characteristics of the application.

[0071] For example, if the system is heavily loaded and the recompiled application is competing with other high-priority tasks, the operating system 126 may choose to schedule it to the small core 264 to balance the load and maintain responsiveness. Conversely, if the system is idle and the recompiled application is the only active task, the operating system 126 may schedule it to the large core 262 to maximize its performance.

[0072] In addition, the operating system 126 can dynamically migrate recompiled applications between the large core 262 and the small core 264 based on runtime performance monitoring and power consumption considerations. If the performance of the application on the small core 264 is deemed insufficient, the operating system 126 can move it to the large core 262 to speed up execution. Similarly, if the application consumes too much power on the large core 262 and there is no significant performance improvement, the operating system 126 may move it back to the small core 264 to save energy.

[0073] Figure 3300 is a flow chart illustrating a method (process) for dispatching an application to an appropriate execution path based on its instruction set architecture (ISA) and computing requirements. In operation 302, the dispatch service 210 receives an application launch request. Then in operation 304, it is determined whether the application uses the old 32-bit ISA or the new 64-bit ISA.

[0074] If the application uses the new 64-bit ISA, the process continues to operation 308. In operation 308, the application is executed on the big core 262 or the small core 264, depending on the scheduling policy of the operating system. This execution path is suitable for applications that are natively compiled for 64-bit architecture and do not require binary recompilation.

[0075] If the application uses the old 32-bit ISA, the process moves to operation 306, where the dispatch service 210 evaluates whether the application is CPU-bound or non-CPU-bound. For non-CPU-bound applications, which are typically I / O-bound or lightweight and do not require significant computing power, the process continues to operation 312. In this case, the application executes directly on the small core 264 using the old 32-bit ISA. By avoiding the binary recompilation overhead of these applications, the system can maintain power efficiency and responsiveness.

[0076] On the other hand, if the application is CPU-limited and requires a lot of computing resources, the process moves to operation 310. Here, the application undergoes a binary recompilation from the old 32-bit ISA to the new 64-bit ISA. This recompilation process is performed by the execution service C 226, allowing the CPU-limited application to take advantage of the higher performance provided by the big core 262.

[0077] After binary recompilation, the recompiled application can be executed on the big core 262 or the small core 264, depending on the scheduling decision of the operating system. The selection between the big core and the small core for the recompiled application is based on factors such as the current system load, power consumption requirements, and performance characteristics of the application.

[0078] Dispatch service 210 and execution service 220 (A 222, B 224 and C 226) work together to implement this process. Dispatch service 210 makes the initial decision whether to use binary recompilation based on the ISA and computing requirements of the application. Execution service 220 then handles the actual execution of the application, whether directly or through binary recompilation.

[0079] There are several possible policies that the dispatch service 210 can use to address this challenge. One approach is to use static dispatching, coupled with a whitelist or blacklist of application signatures. This approach involves creating a table of application rows that are known to be CPU-bound or non-CPU-bound. The dispatch service 210 can consult this list when deciding whether to use binary recompilation for a given application 180.

[0080] For example, the whitelist may include applications that are known to benefit significantly from running on the big cores 262, such as games or other computationally intensive applications. Conversely, the blacklist may include applications that are known to perform well on the small cores 264 or are sensitive to binary recompilation overhead, such as simple utilities or I / O-bound applications.

[0081] Application signatures can include various identifiers, such as:

[0082] Application Name: The name of the application displayed to users.

[0083] App Category: A broader classification of an app, such as "Games," "Productivity," or "Communication."

[0084] Link library dependencies: The libraries or frameworks that an application depends on, which can dictate its functionality and computational requirements.

[0085] Another approach is to collect runtime profile results of the application and use this information to make dispatch decisions. This approach involves monitoring CPU usage, performance, and other relevant indicators when the application is running on the computing device 102.

[0086] For example, if the dispatch service 210 initially dispatches the application to run on the small core 264 without binary recompilation, and observes that the CPU of the small core continues to be fully utilized, this may indicate that the application is CPU-bound. In addition, if the application encounters performance issues, such as low frame rate or latency, it further indicates that the application may benefit from running on the large core 262. In this case, the dispatch service 210 may choose to route the application through binary recompilation and enable it to run on the large core 262 in subsequent executions.

[0087] In addition, runtime profile information collected from various applications can also be used as training data for AI models. This model can be trained to identify patterns and correlations between application characteristics and their computing needs. By analyzing features such as application category, link library dependencies, and historical performance data, the AI ​​model can predict whether an application is likely to be CPU-bound.

[0088] Once trained, the AI ​​model can assist the dispatch service 210 in making more intelligent and dynamic dispatch decisions.

[0089] Figure 4 4 is a diagram 400 showing a computing device 402 executing software on a processor 460 including large cores 462 - 1 and 462 - 2 and small cores 464 - 1 to 464 - 6 . The computing device uses a dispatch service 410 to run an application 430 on an asymmetric multi-core processor 460 .

[0090] Dispatch service 410 accepts application requests and determines the appropriate execution path based on the application's instruction set architecture (ISA) and computing requirements. When an application launch request is received, dispatch service 410 checks whether the application uses the new 64-bit ISA or the old 32-bit ISA.

[0091] For applications using the new 64-bit ISA, such as application 432, dispatch service 410 forks a new child process to execute the application directly on large cores 462-1 and 462-2 or small cores 464-1 to 464-6, depending on the scheduling policy of the operating system.

[0092] For applications using the old 32-bit ISA, dispatch service 410 determines whether the application is CPU-bound or non-CPU-bound. Non-CPU-bound applications, such as application 434, are typically I / O-bound or lightweight and do not require significant computing power. In this case, dispatch service 410 forks a new child process to execute the application directly on small cores 464-1 to 464-6 using the old 32-bit ISA. This approach avoids the overhead of binary recompiling for applications that do not require the performance advantages of running on large cores.

[0093] On the other hand, CPU-limited applications using the old 32-bit ISA, such as application 436, are dispatched to the binary recompiler. Dispatch service 410 forks a new child process to execute the binary recompiler, which loads and runs the CPU-limited application. The binary recompiler converts the 32-bit ISA of the application to the new 64-bit ISA, enabling it to run on the big cores 462-1 and 462-2 or the small cores 464-1 to 464-6. This enables the CPU-limited application 436 to take advantage of the higher performance provided by the big core even if it was originally written for the old 32-bit ISA.

[0094] Figure 2 and Figure 4 The main difference between Figure 4 Lack of execution services. In some configurations, all applications on a computing device run within a Java Virtual Machine (JVM). Figure 2 The execution service in represents a JVM that is pre-initialized and ready to execute applications, thus reducing startup time. In contrast, Figure 4 Depicts a scenario where the scheduler service directly forks child processes to execute applications or binary recompilers without an intermediate execution service. This approach may result in slightly longer startup times because each application needs to initialize the JVM, but the end result is the same.

[0095] It should be understood that the specific order or hierarchy of blocks in the process / flowchart is a depiction of an example method. Based on design preferences, it is understood that the specific order or hierarchy of blocks in the process / flowchart may be rearranged. In addition, some blocks may be combined or omitted. The accompanying method statements present the elements of the various blocks in an example order and are not meant to be limited to the specific order or hierarchy presented.

[0096] The foregoing description is intended to enable those skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects. Therefore, the purpose of the statement is not limited to the aspects shown here, but to be consistent with the full range consistent with the language statement, wherein the reference to the singular form of the element does not mean "only one" unless specifically stated, but "one or more". The word "example" is used here to refer to "as an example, instance or illustration". Any aspect described as an "example" is not necessarily interpreted as being more preferred or advantageous than other aspects. Unless otherwise stated, the term "some" refers to one or more. Combinations such as "at least one A, B or C", "one or more A, B or C", "at least one A, B and C", "one or more A, B and C" and "A, B, C or any combination" include any combination of A, B and / or C, and may include multiple A, multiple B or multiple C. Specifically, combinations such as "at least one A, B, or C," "one or more A, B, or C," "at least one A, B and C," "one or more A, B, and C," and "A, B, C, or any combination" may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, wherein any such combination may include one or more members of A, B, or C. All structural and functional equivalents of the various aspects described in this disclosure, which are later known or may be known in the future to a person having ordinary skill, are hereby incorporated by reference herein and are intended to be covered by the claims. In addition, whether or not explicitly stated in the claims, nothing disclosed herein is intended to be dedicated to the public. The words "module," "mechanism," "element," "device," and the like may not replace the word "means." Therefore, any declared element should not be interpreted as containing a means for function unless the element is explicitly stated using the phrase "means for."

Claims

1. A method for operating a computing device, comprising: receiving an application launch request received by a scheduling service; determining, by the scheduling service, whether the application uses a first instruction set architecture or a second instruction set architecture; After determining that the application uses the second instruction set architecture, determining whether the application is compute-bound or non-compute-bound; After determining that the application is compute-bound, performing binary translation to convert instructions based on the second instruction set architecture from the application to instructions based on the first instruction set architecture; And execute instructions based on the first instruction set architecture on one or more cores supporting the first instruction set architecture.

2. The method of claim 1, further comprising: After determining that the application uses the first instruction set architecture, the application is directly executed on one or more cores supporting the first instruction set architecture without binary translation.

3. The method of claim 1, further comprising: After determining that the application uses the first instruction set architecture, the application is directly executed on one or more cores supporting the first instruction set architecture without binary translation.

4. The method of claim 1, wherein the application is determined to be compute-bound or non-compute-bound according to a static scheduling policy based on an application signature, wherein the application signature includes at least one of an application name, an application category, and a link library dependency.

5. The method of claim 1, further comprising: A runtime profiling result of the application is collected, wherein the application is determined to be compute-bound or non-compute-bound according to the runtime profiling result.

6. The method of claim 1, wherein the application is determined to be compute-bound or non-compute-bound based on an artificial intelligence model pre-trained with runtime profiling results.

7. The method of claim 1, wherein performing binary translation comprises at least one of: translating instructions from the second instruction set architecture to the first instruction set architecture; Mapping registers of the second instruction set architecture to registers of the first instruction set architecture; And converting the system call from the format of the second instruction set architecture to the format of the first instruction set architecture.

8. The method of claim 1, wherein the first instruction set architecture is a 64-bit instruction set architecture and the second instruction set architecture is a 32-bit instruction set architecture.

9. The method of claim 1, wherein the one or more cores supporting the first instruction set architecture are one or more high-performance cores, and wherein the computing device further includes one or more low-performance cores supporting the second instruction set architecture.

10. The method of claim 1, further comprising: After determining that the application uses the second instruction set architecture and is compute-bound, the application information is passed to a first execution service that starts the binary translation.

11. A method as claimed in claim 10, wherein the first execution service provides a first forked process, wherein the binary translation is executed by the first forked process, and wherein the first forked process executes instructions based on the first instruction set architecture on one or more cores supporting the first instruction set architecture.

12. The method of claim 1, further comprising: After determining that the application uses the second instruction set architecture and is non-compute bound, the application information is passed to a second execution service that does not start the binary translation.

13. The method of claim 12, wherein the second execution service forks a second child process, the second child process executing the application on one or more cores supporting the second instruction set architecture.

14. The method of claim 1, further comprising: After determining that the application uses the first instruction set architecture, the application information is passed to a third execution service that does not start the binary translation.

15. The method of claim 14, wherein the third execution service forks a third child process, the third child process executing the application on one or more cores supporting the first instruction set architecture.

Images