Program execution methods, devices, storage media, and program products

Abstract

This application provides a program execution method, device, storage medium, and program product. In this application embodiment, in a heterogeneous computing scenario, for computing units with multiple hardware architectures, for one hardware architecture, executable code adapted to that hardware architecture and intermediate code independent of that hardware architecture are obtained. When the target program needs to be run on another hardware architecture, if the two hardware architectures are incompatible, the intermediate code is recompiled using a compiler adapted to that other hardware architecture to obtain executable code adapted to that other hardware architecture, so that the executable code can be run on the computing unit with that other hardware architecture. By using intermediate code, compatibility with computing units of different hardware architectures can be achieved, eliminating the need to write separate programs for each hardware architecture, greatly improving program reusability and cross-hardware architecture compatibility.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, and in particular to a program execution method, device, storage medium, and program product. Background Technology

[0002] With the rapid development of cloud computing technology, heterogeneous computing has become crucial for handling complex and data-intensive tasks. Heterogeneous computing refers to running program code on different computing units, leveraging the architectural advantages of different computing units to complete specific computing tasks. For example, program code for model training or inference tasks can be run simultaneously on a central processing unit (CPU) and a graphics processing unit (GPU), utilizing the multi-threaded parallel capabilities of the GPU to accelerate model training or inference.

[0003] However, since the same type of computing unit can have different hardware architectures—for example, different hardware architectures have different hardware characteristics and support different instruction sets—program code needs to be able to run across hardware architectures. However, enabling program code to run across hardware architectures is a significant technical challenge for heterogeneous computing. Summary of the Invention

[0004] This application provides a program running method, device, storage medium, and program product to improve program compatibility across hardware architectures.

[0005] This application provides a program execution method applicable to a second heterogeneous resource object, the second heterogeneous resource object including a second computing unit, the second computing unit being of the same type as the first computing unit in a first heterogeneous resource object. The method includes: loading a first executable code and its intermediate code corresponding to a target program into the second computing unit, the first executable code being adapted to the hardware architecture of the first computing unit, and the intermediate code being independent of the hardware architecture of the first computing unit; if the hardware architecture of the second computing unit is not compatible with that of the first computing unit, calling the compiler of the second computing unit to compile the intermediate code to obtain a second executable code adapted to the hardware architecture of the second computing unit; and running the second executable code on at least the second computing unit in the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

[0006] This application also provides a program execution method applicable to a second heterogeneous resource object, the second heterogeneous resource object including a second CPU and a second GPU, and a first heterogeneous resource object including a first CPU and a first GPU. The method includes: loading a third executable code, a first executable code, and intermediate code corresponding to a target program, wherein the first executable code is adapted to the hardware architecture of a first computing unit, the intermediate code is independent of the hardware architecture of the first computing unit, and the third executable code is adapted to the hardware architecture of the third computing unit; if the hardware architecture of the second GPU is not compatible with that of the first GPU, calling the compiler of the second computing unit to compile the intermediate code to obtain a second executable code adapted to the hardware architecture of the second GPU; running the third executable code on a fourth computing unit in the second heterogeneous resource object, and running the second executable code on a second computing unit in the second heterogeneous resource object, so as to run the target program on the second heterogeneous resource object.

[0007] This application also provides an electronic device, including: a memory and a processor; the memory for storing a computer program; and the processor, coupled to the memory, for executing the computer program to implement the steps in the program execution method provided in this application.

[0008] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the steps of the program execution method provided in this application.

[0009] This application also provides a computer program product, including a computer program / instructions, which, when executed by a processor, cause the processor to implement the steps in the program execution method provided in this application.

[0010] In this embodiment of the application, in a heterogeneous computing scenario, for computing units with multiple hardware architectures, for one of the hardware architectures, executable code adapted to that hardware architecture and intermediate code independent of that hardware architecture are obtained. When the target program needs to be run on another hardware architecture, if the two hardware architectures are incompatible, the intermediate code is recompiled using a compiler adapted to the other hardware architecture to obtain executable code adapted to that other hardware architecture, so that the executable code can be run on the computing unit of that other hardware architecture. By using intermediate code, compatibility with computing units of different hardware architectures can be achieved, eliminating the need to write separate programs for each hardware architecture, greatly improving program reusability and cross-hardware architecture compatibility. Attached Figure Description

[0011] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0012] Figure 1 A flowchart illustrating a program execution method provided for an exemplary embodiment of this application;

[0013] Figure 2 A schematic diagram of a calling hierarchy of a second computing unit provided for an exemplary embodiment of this application;

[0014] Figure 3 A schematic diagram illustrating a method for implementing program execution between a driver API and a hardware driver, provided as an exemplary embodiment of this application;

[0015] Figure 4 A schematic diagram illustrating the compilation of a first program fragment as an exemplary embodiment of this application;

[0016] Figure 5 A flowchart illustrating another program execution method provided for an exemplary embodiment of this application;

[0017] Figure 6 A schematic diagram illustrating the result of a program execution apparatus provided as an exemplary embodiment of this application;

[0018] Figure 7 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0021] In heterogeneous computing scenarios, CPUs and GPUs are common computing units. Taking GPUs as an example, the industry currently uses GPUs with various hardware architectures for computational acceleration. Hardware architecture refers to the internal organization and design of a computing unit (such as a GPU). Different manufacturers can produce GPUs with different hardware architectures, and of course, the same manufacturer can also produce GPUs with different hardware architectures. GPUs with different hardware architectures use different programming models and interfaces to write upper-layer applications. Through various interfaces in the programming model, such as space allocation, data transfer, and computation execution, data on the computer (e.g., data in memory space) is transferred to the GPU's video memory space to perform computational tasks, obtain computation results, and return the results to the computer. In the GPU's video memory space, the compiler provided by the GPU toolchain can convert the user-written source code (e.g., kernel functions) into executable code that the GPU can directly execute. This executable code is closely related to the hardware's instruction set and characteristics, making it difficult to achieve compatibility between different architectures.

[0022] Executable code refers to a series of instructions that have been compiled and can be directly executed by computing units (such as GPUs). For example, executable code can be machine code, which is a set of instructions that computing units can directly understand and execute, including a series of binary codes (such as 0s and 1s), each specific sequence representing a basic operation that the computing unit can recognize. In addition to binary code, it can also be hexadecimal code or octal code, etc.

[0023] In heterogeneous computing scenarios, applications can run on two or more computing units, such as CPUs and GPUs simultaneously. However, during development, applications can only be developed for a single hardware architecture computing unit. In other words, applications in heterogeneous computing scenarios are currently incompatible with computing units of different hardware architectures, resulting in poor flexibility.

[0024] In this embodiment of the application, in a heterogeneous computing scenario, for computing units with multiple hardware architectures, for one of the hardware architectures, executable code adapted to that hardware architecture and intermediate code independent of that hardware architecture are obtained. When the target program needs to be run on another hardware architecture, if the two hardware architectures are incompatible, the intermediate code is recompiled using a compiler adapted to the other hardware architecture to obtain executable code adapted to that other hardware architecture, so that the executable code can be run on the computing unit of that other hardware architecture. By using intermediate code, compatibility with computing units of different hardware architectures can be achieved, eliminating the need to write separate programs for each hardware architecture, greatly improving program reusability and cross-hardware architecture compatibility.

[0025] Furthermore, as computing unit hardware architectures are continuously updated, intermediate code can be recompiled to adapt to the ever-evolving hardware architecture without rewriting the entire program. This provides developers with greater flexibility, especially in the face of rapidly changing hardware environments, and can significantly reduce development costs.

[0026] The following describes in detail a solution provided by an embodiment of this application, with reference to the accompanying drawings.

[0027] Figure 1 A flowchart illustrating a program execution method provided as an exemplary embodiment of this application is applicable to a second heterogeneous resource object. The second heterogeneous resource object includes a second computing unit, which is of the same type as the first computing unit in the first heterogeneous resource object, such as... Figure 1 As shown, the method includes:

[0028] 101. Load the first executable code and its intermediate code corresponding to the target program into the second computing unit. The first executable code is adapted to the hardware architecture of the first computing unit, and the intermediate code is independent of the hardware architecture of the first computing unit.

[0029] 102. If the hardware architecture of the second computing unit is not compatible with that of the first computing unit, the compiler of the second computing unit is called to compile the intermediate code to obtain the second executable code that is compatible with the hardware architecture of the second computing unit.

[0030] 103. Run the second executable code on at least the second computing unit in the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

[0031] In this embodiment, a heterogeneous resource object refers to a resource object comprising two or more different types of computing units. In a heterogeneous computing scenario, different types of computing units can work together to improve the overall performance, efficiency, and flexibility of the computing system. The types of computing units may include, but are not limited to: CPU, GPU, DPU (Data Processing Unit), TPU (Tensor Processing Unit), ASIC (Application Specific Integrated Circuit), and FPGA (Field Programmable Gate Array). Correspondingly, computing units may include, but are not limited to: CPU, GPU, DPU, TPU, ASIC, or FPGA. Heterogeneous resource objects may include two or more computing units provided by physical devices, or they may include two or more virtual computing units from a cloud computing instance. Cloud computing instances may include, but are not limited to: Virtual Machines (VMs) or containers (Docker). Virtual computing units can include, but are not limited to, virtual CPUs (vCPUs), virtual GPUs (vGPUs), virtual DPUs (vDPUs), virtual TPUs (vTPUs), or virtual ASICs (vASICs). It should be noted that cloud computing instances may also include virtual network interface cards (NICs), virtual memory, and other resources in addition to virtual computing units.

[0032] Furthermore, the type of computing unit included in heterogeneous resource objects is not limited. For example, a heterogeneous resource object may include both CPU and GPU types, or both CPU and DPU types, or both CPU, DPU, and GPU types, or both CPU, GPU, DPU, and FPGA types. Optionally, in addition to CPU types, heterogeneous resource objects may also include one or more of GPU, DPU, TPU, ASIC, and FPGA types.

[0033] In this embodiment, the target program may include program fragments corresponding to different types of computing units. For example, the target program may include program fragments corresponding to two or more types of computing units. For example, the target program may include CPU program fragments and GPU program fragments. As another example, the target program may include CPU program fragments and DPU program fragments. Yet another example, the target program may include CPU program fragments, DPU program fragments, and GPU program fragments.

[0034] For example, GPU program snippets can be implemented as kernel functions. Kernel functions are code snippets specifically designed for parallel processing units (such as GPUs or FPGAs) to leverage the massive parallelism of these units to accelerate computational tasks. A key characteristic of kernel functions is that they can be executed concurrently by multiple threads, each potentially processing different data objects.

[0035] In this embodiment, the target program can run on a heterogeneous resource object that is compatible with it. Compatibility means that the heterogeneous resource object includes computing units of the types required to run the target program, enabling the target program to run on the heterogeneous resource object. The heterogeneous resource object compiles the target program using its compiler to obtain a code file. The code file includes executable code and intermediate code adapted to the computing units. Running the executable code achieves the goal of running the target program on the heterogeneous resource object. A code file is a file that includes information required for program execution. For example, an example of a code file could be an Executable and Linkable Format (ELF) file.

[0036] Executable code refers to code that has been compiled and can be directly executed by the computing unit. For example, executable code can be machine code; for an introduction to machine code, please refer to the aforementioned embodiments, which will not be repeated here. The heterogeneous resource object uses the compilers corresponding to the various types of computing units it includes to compile the program fragments included in the target program, obtaining the executable code corresponding to each program fragment.

[0037] Intermediate code, or IR, is an abstract representation of code generated by the compiler during the compilation process. It sits between the source code and the executable code, describing the structure and behavior of the program segment to which the executable code belongs. Intermediate code is a general, hardware-architecture-independent representation that can be easily optimized and transformed. Because it does not directly depend on a specific hardware architecture, the same intermediate code can be used to generate executable code for different hardware architectures, improving cross-hardware architecture compatibility.

[0038] For ease of distinction and description, the heterogeneous resource object of the currently running target program is referred to as the first heterogeneous resource object. The first heterogeneous resource object includes a first type of first computing unit, where the first type refers to a computing unit type with multiple dedicated hardware architectures. For example, the first type could be a GPU, DPU, TPU, ASIC, or FPGA. Correspondingly, the first computing unit can be implemented as a GPU, DPU, TPU, ASIC, or FPGA. For ease of distinction and description, the program segment in the target program adapted to this first computing unit is referred to as the first program segment, and the executable code generated by the compiler of the first computing unit from the first program segment is referred to as the first executable code. In addition, during the compilation process of the first program segment, the compiler of the first computing unit can also generate intermediate code corresponding to the first program segment.

[0039] In this embodiment, there may be some application scenarios where it is necessary to migrate a target program running on a first heterogeneous resource object to a second heterogeneous resource object and run the target program on the second heterogeneous resource object. For example, the usage prices of different heterogeneous resource objects are different, the usage price of the first heterogeneous resource object is higher than that of the second heterogeneous resource object, and the performance of the first heterogeneous resource object is better than that of the second heterogeneous resource object. Here, performance can be reflected in dimensions such as memory capacity, number and frequency of computing units, and network bandwidth.

[0040] The second heterogeneous resource object includes a second computing unit, which is of the same type as the first computing unit. The hardware architectures of the first and second computing units may or may not be compatible. Hardware architecture compatibility between the first and second computing units means that the difference between their hardware architectures is less than or equal to a set difference threshold. Hardware architecture incompatibility means that the difference between their hardware architectures is greater than the set difference threshold. The difference can be calculated by considering multiple dimensions of the hardware architecture. These dimensions may include, but are not limited to, deterministic programs, application programming interfaces (APIs), programming models, and instruction sets. When calculating the difference, a difference value can be calculated for each dimension, and different weights can be assigned to different dimensions. The difference value calculated for each dimension and its corresponding weight are then combined to calculate the difference.

[0041] Alternatively, hardware architecture compatibility between the first computing unit and the second computing unit means that the hardware architectures of the first computing unit and the second computing unit are the same. Conversely, hardware architecture mismatch between the first computing unit and the second computing unit can mean that the hardware architectures of the first computing unit and the second computing unit are different. In this process, hardware architecture identification information can be compared to determine whether the hardware architectures of the first computing unit and the second computing unit are the same. Hardware architecture identification information may include, but is not limited to, manufacturer name, product line series, model name, and architecture version.

[0042] In this embodiment, if the hardware architectures of the first computing unit and the second computing unit are incompatible, the second computing unit cannot directly run the first executable code that is compatible with the hardware architecture of the first computing unit. Therefore, the compiler of the second computing unit can be invoked to compile the intermediate code to obtain the second executable code that is compatible with the hardware architecture of the second computing unit. At least the second computing unit in the second heterogeneous resource object is controlled to run the second executable code to run the target program on the second heterogeneous resource object and complete the heterogeneous computing task.

[0043] The compilation process includes just-in-time (JIT) compilation and ahead-of-time (AOT) compilation. JIT compilation is a technique that compiles code during the actual runtime of the target program, dynamically converting intermediate code into executable code, significantly improving the compatibility of the target program. AOT compilation refers to the process of converting intermediate code into executable code before the target program actually runs. Regardless of the compilation method, the compilation process is typically performed by the compiler of the second computational unit, and the generated executable code can be directly loaded into the second computational unit for execution.

[0044] In this embodiment of the application, in a heterogeneous computing scenario, for computing units with multiple hardware architectures, for one of the hardware architectures, executable code adapted to that hardware architecture and intermediate code independent of that hardware architecture are obtained. When the target program needs to be run on another hardware architecture, if the two hardware architectures are incompatible, the intermediate code is recompiled using a compiler adapted to the other hardware architecture to obtain executable code adapted to that other hardware architecture, so that the executable code can be run on the computing unit of that other hardware architecture. By using intermediate code, compatibility with computing units of different hardware architectures can be achieved, eliminating the need to write separate programs for each hardware architecture, greatly improving program reusability and cross-hardware architecture compatibility.

[0045] In an optional embodiment, if the hardware architecture of the second computing unit is compatible with that of the first computing unit, then at least the second computing unit in the second heterogeneous resource object runs the first executable code to run the target program on the second heterogeneous resource object. This eliminates the need to obtain the source code of the target program or to recompile and build the entire target program, thereby greatly improving the running efficiency of the target program.

[0046] In an optional embodiment, the first heterogeneous resource object further includes a third computing unit of a different type from the first computing unit. For ease of distinction and description, the type of the third computing unit is referred to as the second type. The second type refers to a computing unit type with a general-purpose hardware architecture. A general-purpose hardware architecture computing unit can run various programs and algorithms without requiring modification to the computing unit hardware itself. Typically, second-type computing units have rich instruction sets, programming models, and API interfaces. Computing units of this second type can run executable code adapted to different hardware architectures, where different hardware architectures refer to the different hardware architectures corresponding to the computing units of the second type. For example, a CPU type or a TPU type can be a specific example of the second type, and the third computing unit can be implemented as a CPU or a TPU, etc.

[0047] Accordingly, the second heterogeneous resource object includes a fourth computing unit, which is of the same type as the third computing unit, and the hardware architectures of the third and fourth computing units are compatible. The target program corresponds to a third executable code, which is compatible with the hardware architecture of the third computing unit, and consequently, also compatible with the hardware architecture of the fourth computing unit. Therefore, the fourth computing unit can run the third executable code. Based on this, the method provided in this optional embodiment further includes: loading the third executable code corresponding to the target program into the fourth computing unit, so that the fourth computing unit can run the third executable code.

[0048] Accordingly, the implementation of running the second executable code on at least the second computing unit in the second heterogeneous resource object to run the target program on the second heterogeneous resource object is not limited. A specific implementation is provided below: running the third executable code on the fourth computing unit in the second heterogeneous resource object, and running the second executable code on the second computing unit in the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

[0049] In the case of heterogeneous resources, the third executable code, which originally ran on the third computing unit of the first heterogeneous computing resource object, is run on the fourth computing unit of the second heterogeneous resource object. For the first executable code that originally ran on the first computing unit of the first heterogeneous computing resource object, a second executable code adapted to the hardware architecture of the second computing unit is generated based on the intermediate code. The second executable code is executed by the second computing unit, which ensures that the target program can be seamlessly migrated and run efficiently between the first heterogeneous resource object and the second heterogeneous resource object with different hardware architectures, greatly improving the portability and flexibility of the target program.

[0050] Optionally, the implementation method for loading the third executable code corresponding to the target program is not limited. One specific implementation method for loading the third executable code corresponding to the target program includes: parsing first metadata information from the target code file corresponding to the target program; the first metadata information includes the identifiers and offset addresses of each code segment in the target code file, where each code segment corresponds to a computing unit in a first heterogeneous resource object; parsing the first code segment from the target code file based on the identifier and offset address of the first code segment corresponding to the third computing unit; and parsing the third executable code from the first code segment.

[0051] The target code file is responsible for the structure and layout of the entire target program, including the organization of third-party executable code (e.g., CPU code) and first-party executable code (e.g., GPU code). First metadata information describes the basic attributes of the entire code file. These attributes may include, but are not limited to: file type, entry point address, names of each code segment, and offset addresses of each segment within the code file. The offset addresses of each code segment can be represented by an initial offset address and a length. The first code segment focuses on the storage and management of the second type of third-party executable code, providing support for multiple hardware architectures. For example, the first code segment storing the third-party executable code can be implemented as a text segment (.text).

[0052] In this process, by performing structured parsing on the target code file to obtain the first metadata information, and then parsing the first code segment containing the third executable code based on the metadata information, it is possible to more accurately identify and locate different types of code, ensuring the correctness of subsequent processing steps.

[0053] In one optional embodiment, a schematic diagram of the calling hierarchy of a second computing unit is provided, such as... Figure 2 As shown. In Figure 2 In this structure, from top to bottom, are the target program, runtime API, driver API, hardware driver, and second computing unit. The runtime API provides a set of high-level interfaces, allowing the target program developer to interact directly with the second computing unit. These interfaces are typically used for launching kernel functions, managing memory allocation and transfer, and synchronization operations. The driver API provides lower-level interfaces, usually implemented by the second computing unit's driver program, which can schedule tasks and manage hardware resources. The hardware driver acts as a bridge between the operating system and the second computing unit, responsible for translating instructions from the driver API into specific hardware operations. This layered structure allows developers to focus on writing efficient algorithms and application logic without needing to delve into the low-level hardware details, while also fully utilizing the powerful computing capabilities of the first type of second computing unit.

[0054] In one alternative embodiment, the process of the driver API loading the first executable code and intermediate code is described below, such as... Figure 3 As shown. In Figure 3In this process, the operations sent from the driver API to the hardware driver include various types, such as memory allocation, data copying, and loading the executable code corresponding to the first program fragment (e.g., kernel function) into the hardware driver. The driver API determines whether the hardware architectures of the first and second computing units are compatible. If the hardware architectures of the first and second computing units are not compatible, intermediate code is loaded from the object code file, compiled into second executable code compatible with the second computing unit, and provided to the hardware driver. The hardware driver then provides the second executable code to the second computing unit, where it runs.

[0055] Furthermore, if the hardware architectures of the first computing unit and the second computing unit are compatible, the first executable code is directly loaded and provided to the hardware driver, which then provides the first executable code to the second computing unit for execution.

[0056] Specifically, it can be detected at the kernel level that the second executable code of a kernel function is inconsistent with the first executable code in the object code file.

[0057] In this configuration, when compiling the target program is required, selecting the option to generate intermediate code eliminates the need for further modifications. This process generates both the first executable code and intermediate code during compilation. The compilation of the target program is performed on the first heterogeneous resource object, while no compilation is required on the second heterogeneous resource object. For the second heterogeneous resource object, if the hardware architectures of the first and second computing units are compatible, the first executable code is loaded into the hardware driver via the driver API. The hardware driver then provides the first executable code to the hardware (i.e., the second computing unit), which executes it. If the hardware architectures of the first and second computing units are incompatible, intermediate code is loaded at the driver API level, automating the conversion from intermediate code to second executable code. The second executable code is then loaded through the hardware driver, enabling subsequent computing tasks to call the second computing unit under the current hardware architecture to run the second executable code, thus achieving compatible operation of the target program across multiple hardware architectures.

[0058] Optionally, the implementation method of loading the first executable code and its intermediate code corresponding to the target program into the second computing unit is not limited. The following provides an implementation method for loading the first executable code and its intermediate code corresponding to the target program into the second computing unit via a driver API. The target application programming interface (API) of the driver program for the second computing unit (e.g., ...) is called. Figure 2The driver API in the target program performs the following loading operations: parsing the first metadata information from the target code file corresponding to the target program, the first metadata information including the identifier and offset address of each code segment in the target code file, and one code segment corresponding to a computing unit in the first heterogeneous resource object; parsing the first executable code and intermediate code from the second code segment according to the identifier and offset address of the second code segment, the first executable code and the intermediate code corresponding to the first computing unit.

[0059] The implementation method for parsing the first executable code and intermediate code from the second code segment based on the respective identifiers and offset addresses of the second code segment, the first executable code, and the intermediate code corresponding to the first computing unit is not limited. An example is provided below: the second code segment is parsed from the object code file based on the identifier and offset address of the second code segment corresponding to the first computing unit. The second code segment includes second metadata information, which includes the respective identifiers and offset addresses of the first executable code and the intermediate code; the first executable code and the intermediate code are then parsed from the second code segment based on the respective identifiers and offset addresses of the first executable code and the intermediate code.

[0060] For example, the second code segment storing the first executable code and intermediate code can be implemented as a fat binary section, also known as a universal binary section. It should be noted that the offset addresses of each code segment included in the first metadata information refer to the offset addresses of each code segment within the code file, while the offset addresses in the second metadata information refer to the offset addresses of the first executable code and intermediate code respectively within the second code segment. Figure 3 The second code segment is implemented as the kernel function fatbinary for example illustration.

[0061] By introducing identifiers from metadata, different types of code segments can be clearly distinguished and located, avoiding line-by-line scanning or complex parsing of the entire code file, thus improving parsing speed and accuracy.

[0062] In an optional embodiment, the method provided in this application further includes generating a target code file corresponding to the target program. The source code of the target program includes at least two types of program fragments, and the number of each type of program fragment is not limited; for example, there may be one or more. One type of program fragment corresponds to one type of computing unit. For example, if the target program includes a CPU and a GPU, then the target program includes CPU program fragments and GPU program fragments. As another example, if the target program includes a CPU and a TPU, then the target program includes CPU program fragments and TPU program fragments. Based on this, the target code file can be obtained by heterogeneously compiling the at least two types of program fragments according to the compilers of the computing units corresponding to the at least two types of program fragments in the first heterogeneous resource object. Specifically, different computing units have different compilers, and the program fragments corresponding to each computing unit can be compiled using the compilers of each computing unit to obtain executable code and intermediate code adapted to each computing unit; based on the executable code and intermediate code adapted to each computing unit, a target code file corresponding to the target program is generated. The target code file may include executable code and intermediate code adapted to each computing unit. For example, the target code file includes executable code for the CPU, executable code for the GPU, and intermediate code for the GPU. Furthermore, the target code file also includes intermediate code for the CPU. The target code file is obtained by compiling program fragments from the target program using the first heterogeneous resource object, laying the foundation for supporting different hardware architectures. This allows the target program to be run subsequently using the second heterogeneous resource object without requiring the source code of the target program, or recompiling and rebuilding it. This reduces the preconditions for compatibility with different hardware architectures and requires fewer additional operations, thus having broader application prospects.

[0063] like Figure 4 As shown, the process of compiling the first program segment corresponding to the first type of computational unit in the target program is explained. Figure 4 Taking a GPU program fragment as an example, a second code segment is extracted from the target code file corresponding to the target program. An exemplary target code file could be an ELF file, and the second code segment could be a fat binary code segment containing kernel functions. The second code segment is then parsed to obtain the first executable code, where different kernel functions can correspond to different first executable codes. The target program may include one or more kernel functions, and correspondingly, the second code segment includes one or more second executable codes. Figure 4The illustration uses two executable code segments as an example, but this is not a limitation. Furthermore, the second code segment also includes intermediate code corresponding to the first program segment. Automated inlining of this intermediate code yields the source file supported by the compiler of the second computing unit; the source file is then input into the compiler for compilation to obtain the second executable code. The illustration exemplifies this by showing the second executable code as machine code, but it is not limited to this.

[0064] Optionally, the target program includes a control program segment and an acceleration program segment. For example, the control program segment may be a CPU program segment, and the acceleration program segment may be a GPU program segment. During the execution of the target program on the second heterogeneous resource object, the control program segment can be executed by the fourth computing unit. During the execution of the control program segment, the second computing unit is invoked to execute the acceleration program segment. The implementation of invoking the second computing unit to execute the acceleration program segment can refer to the foregoing embodiments, namely, invoking the driver API of the second computing unit to load the first executable code and its intermediate code corresponding to the target program into the second computing unit. If the hardware architecture of the second computing unit is incompatible with that of the first computing unit, the compiler of the second computing unit is invoked to compile the intermediate code to obtain a second executable code compatible with the hardware architecture of the second computing unit. The second executable code is executed on at least the second computing unit within the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

[0065] In one alternative embodiment, the implementation of determining that the hardware architecture of the second computing unit is incompatible with that of the first computing unit is not limited. An exemplary description follows.

[0066] For example, the target application programming interface (API) of the second computing unit's driver is called to send the first executable code to the second computing unit's driver, so that the second computing unit's driver can control the second computing unit to execute the first executable code. If the second computing unit fails to execute, it is determined that the hardware architecture of the second computing unit is incompatible with that of the first computing unit. Upon detecting an execution failure, a rapid response can be initiated, attempting to convert the intermediate code into second executable code compatible with the hardware architecture of the second computing unit, reducing user waiting time and enhancing the user experience.

[0067] For example, the hardware architecture description information of the first computing unit and the second computing unit are obtained; the hardware architecture description information of the first computing unit and the second computing unit are compared; if they are different, it is determined that the hardware architectures of the second computing unit and the first computing unit are incompatible. The implementation method for obtaining the hardware architecture description information of the first computing unit is not limited. For example, the hardware architecture description information of the first computing unit can be parsed from the first metadata information of the target code file. The implementation method for obtaining the hardware architecture description information of the second computing unit is not limited. For example, the hardware architecture description information of the second computing unit can be obtained from the resource file of the device to which the second heterogeneous resource object belongs. The hardware architecture description information includes, but is not limited to: manufacturer name, product line series, model name, and architecture version. During the comparison of the hardware architecture description information of the first computing unit and the second computing unit, one or more target description information can be selected from the manufacturer name, product line series, model name, and architecture version. If the target information of the first computing unit is different from the target information of the second computing unit, it can be determined that the hardware architecture description information of the first computing unit and the second computing unit are different. By comparing hardware architecture description information during the compilation or deployment phase, potential incompatibility issues can be identified before runtime, thereby improving system stability and reliability.

[0068] In one optional embodiment, the implementation of calling the compiler of the second computing unit to compile the intermediate code to obtain second executable code adapted to the hardware architecture of the second computing unit is not limited. An example is provided below, considering that the compiler of the second computing unit may not support directly using intermediate code as input; therefore, it is necessary to convert the intermediate code into an input format acceptable to the compiler. Based on this, the target application interface of the driver of the second computing unit is called to perform the following compilation operations: performing code inlining to generate a source file of inline intermediate code, the source file being implemented in a programming language supported by the compiler of the second computing unit; and compiling the source file using the compiler of the second computing unit to obtain the second executable code. By converting the intermediate code into a format supported by the compiler of the second computing unit and generating second executable code adapted to the hardware architecture of the second computing unit through the compiler, the target program can run on multiple hardware architectures. This greatly improves code portability and flexibility, reducing the need to rewrite or significantly modify the code for each new hardware architecture.

[0069] Optionally, the implementation of performing code inlining to generate a source file of inline intermediate code is not limited. One specific implementation of performing code inlining includes: parsing parameter information, function code, and variables of the kernel function from the intermediate code; creating a source file according to the programming language supported by the compiler of the second computing unit, the source file including a parameter list and an empty function body; adding parameter information to the parameter list, and inlining the function code and variables into the empty function body, establishing an association between the variables and parameter information, thereby inlining the source file of the intermediate code.

[0070] In this context, a kernel function is a program segment in the target program corresponding to a computational unit of the first type. The parameters of the kernel function define the data exchange method between the computational units of the first and second types. Kernel function parameters typically use specific modifiers to specify their memory location and access mode, and the actual parameter values ​​are provided by third-party executable code when the kernel function is called. The parameter information of a kernel function includes, but is not limited to: global memory pointers, shared memory, constant memory, and local variables.

[0071] In this context, functional code refers to the code logic corresponding to the kernel function. The programming language of this functional code is the same as that of the intermediate code, but different from the programming language of the target program. For example, functional code can use assembly language. Functional code defines the program's execution path, such as conditional branches, loops, and function calls.

[0072] In intermediate code, variables refer to abstract concepts used by the compiler to optimize and generate executable code. Variables can include, but are not limited to, register variables, memory locations, and temporary variables.

[0073] Kernel function parameters are mapped to different variables in intermediate code, such as registers, stack slots, or specific memory segments, based on their type and purpose, so that the compiler can generate executable code.

[0074] The above method involves meticulously analyzing the intermediate code to extract key components of the kernel function (such as parameter information, functional code, and variables). By creating a source file containing a parameter list and an empty function body, and inlining the parsed content into the source file, the functional logic of the original intermediate code remains unchanged. At the same time, the intermediate code is converted into an input form that the compiler can recognize, ensuring the accuracy and completeness of subsequent conversion steps.

[0075] Regarding the embodiments provided in this application Figure 1 The detailed implementation methods and beneficial effects of each step in the method shown have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0076] This application also provides a program execution method, which can be implemented as follows: Figure 1 A scenario-based embodiment of the method shown. Exemplarily, using... Figure 1 The first computing unit is implemented as a first graphics processing unit (referred to as a first GPU), the second computing unit is implemented as a second graphics processing unit (referred to as a second GPU), the third computing unit is implemented as a first central processing unit (referred to as a first CPU), and the fourth computing unit is implemented as a second central processing unit (referred to as a second CPU). This method is used to run a target program on a second heterogeneous resource object. The first heterogeneous resource object includes a first CPU and a first GPU, and the second heterogeneous resource object includes a second CPU and a second GPU. The hardware architectures of the first CPU and the second CPU are adapted, such as... Figure 5 As shown, the method includes:

[0077] 501. Load the first executable code and its intermediate code corresponding to the target program, as well as the third executable code. The first executable code is adapted to the hardware architecture of the first GPU, the intermediate code is independent of the hardware architecture of the first GPU, and the third executable code is adapted to the hardware architecture of the first CPU.

[0078] 502. If the hardware architecture of the second GPU is not compatible with that of the first GPU, the compiler of the second GPU is called to compile the intermediate code to obtain the second executable code that is compatible with the hardware architecture of the second GPU.

[0079] 503. Run a third executable code on a second CPU in a second heterogeneous resource object, and run a second executable code on a second GPU in a second heterogeneous resource object, so as to run the target program on the second heterogeneous resource object.

[0080] For example, the first executable can be implemented as first GPU machine code, the second executable can be implemented as second GPU machine code, and the third executable can be implemented as first CPU machine code, but is not limited to these.

[0081] In this embodiment, when the second computing unit is implemented as a GPU, Figure 2 The demonstrated call hierarchy has a specific implementation. For example, the runtime API can be implemented as the GPU runtime API, the driver API can be implemented as the GPU driver API, and the hardware driver can be implemented as the GPU driver. Generally, the target program (such as a heterogeneous computing program) can call the GPU runtime API and the GPU driver API. The GPU driver API can call the GPU's execution instructions encapsulated within the GPU driver, thereby distributing the second executable code to the GPU hardware.

[0082] In this embodiment, a series of operations are performed on the GPU driver API layer. The operations issued by the GPU driver API to the GPU driver include various types, such as memory allocation and data copying. When the driver API loads the kernel function (specifically, the target code file), if the hardware architectures of the first and second GPUs are incompatible, the fat binary of the currently loaded kernel function is extracted from the target code file (ELF file), and the intermediate code of the current kernel function is extracted from it. This intermediate code is independent of the GPU's hardware architecture; therefore, the compiler in the toolchain provided by the actually running second GPU can be used for just-in-time compilation to generate second GPU machine code adapted to the second GPU. The GPU driver API provides the second GPU machine code to the GPU driver, which loads the second GPU machine code into the second GPU. The second GPU then runs the second GPU machine code to complete the kernel function execution.

[0083] The detailed process of just-in-time compilation for kernel functions includes:

[0084] 1. When the driver API calls the API that loads the kernel function, the first GPU machine code of the kernel function is intercepted. The executable file compiled by the heterogeneous computing program (i.e., the aforementioned target code file) is organized in an ELF file structure. The structure of the ELF file contains first metadata information (e.g., header structure) describing the file attributes. From this first metadata information (e.g., header structure), the meaning, attributes, and offset addresses of each code segment in the current ELF file can be obtained. By parsing the ELF file, the fat binary section can be extracted. Typically, the fat binary section exists as a separate complete data part in the ELF file, and its size and the number of first GPU machine codes and intermediate codes it contains are determined by the compilation options when compiling the target program. It should be noted that by parsing the ELF file, a text section with the ".text" extension can also be extracted, and the first CPU machine code can be obtained from this text section.

[0085] 2. Similar to ELF files, the fat binary includes second metadata information (such as header structure). By parsing the header structure of the fat binary, the number of first GPU machine code and intermediate code can be obtained, as well as the offset addresses of the intermediate code and machine code in the fat binary. Based on the offset addresses, the first GPU machine code and intermediate code can be extracted from the fat binary.

[0086] 3. The intermediate code can be just-in-time (JIT) compiled using the compiler provided by the current second GPU toolchain to generate second GPU machine code. It's important to note that some GPU toolchain compilers may not accept intermediate code directly as compilation input; therefore, the intermediate code must be converted into a compiler-acceptable input format. This can be achieved through code inlining, generating a source file containing inlined intermediate code, which can then be used as input to the compiler. An automatic inlining script can generate a source file containing the kernel function signature (e.g., a C++ programming language source file), inline the kernel function's intermediate code within the function body, and establish the correspondence between the kernel function's parameters and return value and the variables in the inlined intermediate code at the end of the inline. Upon receiving the input, the second GPU compiler can generate second GPU machine code adapted to the second GPU's hardware architecture.

[0087] 4. Provide the generated machine code of the second GPU to the GPU driver for loading. After the driver is loaded, when subsequent computing operation instructions are issued, the driver can load the second GPU machine code and run it on the current second GPU. This allows the program to run on the current second GPU without modifying the heterogeneous computing program.

[0088] Detectability: Kernel-level detection revealed that the second GPU machine code of the kernel function was inconsistent with the original first GPU machine code.

[0089] In this application embodiment, a multi-architecture graphics processor running method based on just-in-time compilation is provided. The method intercepts the API of the GPU driver loading kernel functions, extracts the intermediate code in the fat binary section of the kernel function, compiles it with a compiler that conforms to the current GPU hardware architecture to generate the corresponding machine code, and hands the generated machine code over to the GPU driver for loading. The compiled machine code is then run on the current GPU to achieve the purpose of running kernel functions on the current GPU architecture, thereby realizing the compatible running of heterogeneous programs on GPUs with different architectures.

[0090] This method intercepts kernel function APIs at the GPU driver API level and compiles intermediate code in real-time to achieve the purpose of compiling kernel functions. It requires no source code and eliminates the need for recompiling or rebuilding the source code. This lowers compatibility requirements and necessitates fewer additional operations, significantly improving the compatibility of heterogeneous computing programs across different GPU architectures. This frees them from hardware limitations, enabling them to run on multiple hardware platforms. In practical applications, source code is often difficult to obtain; therefore, this embodiment achieves compatibility with multiple GPU architectures without requiring source code, thus having broad application potential.

[0091] In this context, heterogeneous computing programs can select the option to generate intermediate code during a single compilation (e.g., the first time). No further modifications are required. The conversion of kernel function intermediate code to machine code can be automatically completed at the driver API level, and the converted machine code is provided to the GPU driver for loading. This machine code can then be called in subsequent computing tasks and run on the GPU under the current hardware architecture, thus achieving multi-architecture GPU compatibility for heterogeneous computing programs.

[0092] Among them, regarding Figure 5 For a detailed description of the method shown, please refer to the foregoing embodiments, which will not be repeated here.

[0093] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 101 to 103 can be device A; or the execution subject of steps 101 and 102 can be device A, and the execution subject of step 103 can be device B; and so on.

[0094] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations appearing in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 101, 102, etc., are merely used to distinguish different operations and do not represent any execution order. Additionally, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the descriptions such as "first" and "second" in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to different types.

[0095] Figure 6 A schematic diagram of a program execution device provided for an exemplary embodiment of this application is applicable to a second heterogeneous resource object. The second heterogeneous resource object includes a second computing unit, which is of the same type as the first computing unit in the first heterogeneous resource object, such as... Figure 6 As shown, the device includes a loading module 61, a calling module 62, and a running module 63.

[0096] Loading module 61 is used to load the first executable code and its intermediate code corresponding to the target program into the second computing unit. The first executable code is adapted to the hardware architecture of the first computing unit, and the intermediate code is independent of the hardware architecture of the first computing unit.

[0097] Module 62 is called to compile the intermediate code of the second computing unit if the hardware architecture of the second computing unit is not compatible with that of the first computing unit, so as to obtain the second executable code that is compatible with the hardware architecture of the second computing unit.

[0098] Run module 63 is configured to run second executable code on at least a second computing unit in the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

[0099] In an optional embodiment, the running module is further configured to: if the hardware architecture of the second computing unit is compatible with that of the first computing unit, run the first executable code on at least the second computing unit in the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

[0100] In an optional embodiment, the first heterogeneous resource object further includes a third computing unit of a different type from the first computing unit, and the second heterogeneous resource object further includes a fourth computing unit of the same type as the third computing unit, wherein the hardware architectures of the third computing unit and the fourth computing unit are adapted. The loading module is further configured to load the third executable code corresponding to the target program into the fourth computing unit, wherein the third executable code is adapted to the hardware architecture of the third computing unit. The running module is specifically configured to run the third executable code on the fourth computing unit in the second heterogeneous resource object, and run the second executable code on the second computing unit in the second heterogeneous resource object, so as to run the target program on the second heterogeneous resource object.

[0101] Optionally, the loading module is specifically used to: parse first metadata information from the target code file corresponding to the target program, the first metadata information including the identifier and offset address of each code segment in the target code file, and one code segment corresponding to a computing unit in the first heterogeneous resource object; parse the first code segment from the target code file according to the identifier and offset address of the first code segment corresponding to the third computing unit, and parse the third executable code from the first code segment.

[0102] In an optional embodiment, the loading module is specifically configured to: call the target application interface of the driver of the second computing unit and perform the following loading operations: parse the first metadata information from the target code file corresponding to the target program, the first metadata information including the identifier and offset address of each code segment in the target code file, and one code segment corresponding to a computing unit in the first heterogeneous resource object; parse the first executable code and intermediate code from the second code segment according to the identifier and offset address of the second code segment, the first executable code and the intermediate code corresponding to the first computing unit.

[0103] Optionally, the loading module is specifically used to: parse the second code segment from the target code file according to the identifier and offset address of the second code segment corresponding to the first computing unit, the second code segment including second metadata information, the second metadata information including the identifier and offset address of the first executable code and the intermediate code respectively; and parse the first executable code and the intermediate code from the second code segment according to the identifier and offset address of the first executable code and the intermediate code respectively.

[0104] Optionally, the source code of the target program includes at least two types of program fragments, each type of program fragment corresponding to a type of computing unit. The device also includes a compilation module; the compilation module is used to heterogeneously compile the at least two types of program fragments into target code files based on the compiler of the computing units corresponding to the at least two types of program fragments in the first heterogeneous resource object.

[0105] In an optional embodiment, the device further includes a calling module and a comparison module. The calling module is used to call the target application programming interface of the driver of the second computing unit to send the first executable code to the driver of the second computing unit, so as to control the second computing unit to execute the first executable code through the driver of the second computing unit; if the second computing unit fails to execute, it is determined that the hardware architecture of the second computing unit is incompatible with that of the first computing unit; or the comparison module is used to compare the hardware architecture description information of the first computing unit and the hardware architecture description information of the second computing unit, and if the two are different, it is determined that the hardware architecture of the second computing unit is incompatible with that of the first computing unit.

[0106] In an optional embodiment, the calling module is further configured to: call the target application interface of the driver of the second computing unit to perform the following compilation operations: perform code inlining to generate a source file of inline intermediate code, the source file being implemented in a programming language supported by the compiler of the second computing unit; and compile the source file using the compiler of the second computing unit to obtain second executable code.

[0107] Optionally, the calling module is specifically used to: parse the parameter information, function code, and variables of the kernel function from the intermediate code; create a source file, which includes a parameter list and an empty function body, according to the programming language supported by the compiler of the second computing unit; add the parameter information to the parameter list, and inline the function code and variables into the empty function body to establish the association between the variables and the parameter information, so as to inline the source file of the intermediate code.

[0108] This application embodiment also provides a program running device for running a target program on a second heterogeneous resource object, the second heterogeneous resource object including a second CPU and a second GPU, and the first heterogeneous resource object including a first CPU and a first GPU. The device includes a loading module, a calling module, and a running module.

[0109] The loading module is used to load the third executable code, the first executable code and their intermediate code corresponding to the target program. The first executable code is adapted to the hardware architecture of the first computing unit, the intermediate code is independent of the hardware architecture of the first computing unit, and the third executable code is adapted to the hardware architecture of the third computing unit.

[0110] The calling module is used to call the compiler of the second computing unit to compile the intermediate code if the hardware architecture of the second GPU is not compatible with that of the first GPU, so as to obtain the second executable code that is compatible with the hardware architecture of the second GPU.

[0111] The runtime module is used to run third executable code on a fourth computing unit in the second heterogeneous resource object and run second executable code on a second computing unit in the second heterogeneous resource object, so as to run the target program on the second heterogeneous resource object.

[0112] Regarding the embodiments provided in this application Figure 6 The detailed implementation methods and beneficial effects of each step in the apparatus shown have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0113] Figure 7 A schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application, such as... Figure 7 As shown, the device includes a memory 74 and a processor 75.

[0114] Memory 74 is used to store computer programs and can be configured to store various other data to support operation on the electronic device. Examples of this data include instructions for any application or method used to operate on the electronic device.

[0115] The processor 75, coupled to the memory 74, is used to execute the computer program in the memory 74 for: executing the program running methods described in the foregoing embodiments, for details of which will not be repeated here.

[0116] Regarding the embodiments provided in this application Figure 7 The detailed implementation methods and beneficial effects of each step in the device shown have been described in detail in the foregoing embodiments, and will not be elaborated here.

[0117] Furthermore, such as Figure 7 As shown, the electronic device also includes other components such as a communication component 76, a display 77, a power supply component 78, and an audio component 79. Figure 7 The diagram only shows some components and does not mean that the electronic device includes only these components. Figure 7 The components shown. Additionally... Figure 7The components within the dashed box are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, smartphone, IoT (Internet of Things) device, or smart wearable device (such as a smartwatch or smart bracelet), or a server-side device such as a conventional server, cloud server, or server array. If the electronic device in this embodiment is a desktop computer, laptop computer, smartphone, or other terminal device, it may include... Figure 7 The components within the dashed box; if the electronic device in this embodiment is implemented as a conventional server, cloud server, or server array, etc., it may be omitted. Figure 7 The component within the dashed box.

[0118] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can perform the above-described functions. Figure 1 and Figure 5 The steps in the method embodiment shown can be performed by an electronic device.

[0119] Accordingly, embodiments of this application also provide a computer program product, including a computer program / instructions, which, when executed by a processor, cause the processor to perform the above-described... Figure 1 and Figure 5 The steps in the method embodiment shown can be performed by an electronic device.

[0120] The aforementioned memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0121] The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access wireless networks based on communication standards, such as WiFi, 2G, 3G, 4G / LTE, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a Near Field Communication (NFC) module to facilitate short-range communication.

[0122] The aforementioned display includes a screen, which may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen can be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors can sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0123] The aforementioned power supply components provide power to various components within the device in which they reside. These power supply components may include a power management system, one or more power sources, and other components associated with generating, managing, and distributing power to the device in which they reside.

[0124] The aforementioned audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals.

[0125] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0126] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0127] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0128] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0129] In a typical configuration, a computing device includes one or more processors (Central Processing Unit, CPU), input / output interfaces, network interfaces, and memory.

[0130] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0131] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0132] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0133] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for running a program, characterized in that, Applicable to a second heterogeneous resource object, the second heterogeneous resource object including a second computing unit, the second computing unit being of the same type as the first computing unit in the first heterogeneous resource object, the method includes: The first executable code and its intermediate code corresponding to the target program are loaded into the second computing unit. The first executable code is adapted to the hardware architecture of the first computing unit, and the intermediate code is independent of the hardware architecture of the first computing unit. If the hardware architecture of the second computing unit is not compatible with that of the first computing unit, the compiler of the second computing unit is called to compile the intermediate code to obtain a second executable code that is compatible with the hardware architecture of the second computing unit. The second executable code is run on at least the second computing unit in the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

2. The method according to claim 1, characterized in that, The compiler of the second computing unit is invoked to compile the intermediate code to obtain second executable code adapted to the hardware architecture of the second computing unit, including: Call the target application interface of the driver for the second computing unit and perform the following compilation operations: Perform code inlining to generate a source file that inlines the intermediate code, the source file being implemented in a programming language supported by the compiler of the second computing unit; The source file is compiled using the compiler of the second computing unit to obtain the second executable code.

3. The method according to claim 2, characterized in that, Perform code inlining to generate a source file that inlines the intermediate code, including: Parse the kernel function's parameter information, function code, and variables from the intermediate code; According to the programming language supported by the compiler of the second computing unit, a source file is created, the source file including a parameter list and an empty function body; The parameter information is added to the parameter list, and the function code and variables are inlined into the empty function body to establish the association between the variables and the parameter information, so as to inline the source file of the intermediate code.

4. The method according to claim 1, characterized in that, The first heterogeneous resource object further includes a third computing unit of a different type than the first computing unit, and the second heterogeneous resource object further includes a fourth computing unit of the same type as the third computing unit, and the hardware architecture of the third computing unit is adapted to the fourth computing unit. The method further includes: loading the third executable code corresponding to the target program into the fourth computing unit, wherein the third executable code is adapted to the hardware architecture of the third computing unit; Running the second executable code on at least a second computing unit within the second heterogeneous resource object to run the target program on the second heterogeneous resource object includes: The third executable code is run on the fourth computing unit in the second heterogeneous resource object, and the second executable code is run on the second computing unit in the second heterogeneous resource object, so as to run the target program on the second heterogeneous resource object.

5. The method according to claim 4, characterized in that, Loading the third executable code corresponding to the target program includes: First metadata information is parsed from the target code file corresponding to the target program. The first metadata information includes the identifier and offset address of each code segment in the target code file. One code segment corresponds to a computing unit in the first heterogeneous resource object. Based on the identifier and offset address of the first code segment corresponding to the third computing unit, the first code segment is parsed from the target code file, and the third executable code is parsed from the first code segment.

6. The method according to claim 1, characterized in that, Loading the first executable code and its intermediate code corresponding to the target program into the second computing unit includes: The target application interface of the driver for the second computing unit is invoked to perform the following loading operation: First metadata information is parsed from the target code file corresponding to the target program. The first metadata information includes the identifier and offset address of each code segment in the target code file. One code segment corresponds to a computing unit in the first heterogeneous resource object. Based on the identifiers and offset addresses of the second code segment corresponding to the first computing unit, the first executable code, and the intermediate code, the first executable code and the intermediate code are parsed from the second code segment.

7. The method according to claim 1, characterized in that, Based on the identifiers and offset addresses of the second code segment corresponding to the first computing unit, the first executable code, and the intermediate code, the first executable code and the intermediate code are parsed from the second code segment, including: The second code segment is parsed from the target code file based on the identifier and offset address of the second code segment corresponding to the first computing unit. The second code segment includes second metadata information, which includes the identifier and offset address of the first executable code and the intermediate code, respectively. Based on the respective identifiers and offset addresses of the first executable code and the intermediate code, the first executable code and the intermediate code are parsed from the second code segment.

8. The method according to any one of claims 5-7, characterized in that, The source code of the target program includes at least two types of program fragments, each type of program fragment corresponding to a type of computing unit. The method further includes: The target code file is obtained by heterogeneously compiling the at least two types of program fragments according to the compiler of the computing unit corresponding to the at least two types of program fragments in the first heterogeneous resource object.

9. The method according to claim 1, characterized in that, Also includes: The target application interface of the driver of the second computing unit is invoked to send the first executable code to the driver of the second computing unit, so as to control the second computing unit to execute the first executable code through the driver of the second computing unit; If the second computing unit fails to execute, it is determined that the hardware architecture of the second computing unit is incompatible with that of the first computing unit. or The hardware architecture description information of the first computing unit and the hardware architecture description information of the second computing unit are compared. If they are different, it is determined that the hardware architecture of the second computing unit is not compatible with that of the first computing unit.

10. The method according to claim 1, characterized in that, Also includes: If the second computing unit is compatible with the hardware architecture of the first computing unit, the first executable code is executed at least in the second computing unit of the second heterogeneous resource object to run the target program on the second heterogeneous resource object.

11. A method for running a program, characterized in that, The method is applicable to a second heterogeneous resource object, wherein the target program currently resides in a first heterogeneous resource object including a first central processing unit (CPU) and a first graphics processing unit (GPU), and the second heterogeneous resource object including a second CPU and a second GPU, wherein the hardware architectures of the first CPU and the second CPU are adapted. The method includes: Load the first executable code and its intermediate code, as well as the third executable code, corresponding to the target program. The first executable code is adapted to the hardware architecture of the first graphics processor, the intermediate code is independent of the hardware architecture of the first graphics processor, and the third executable code is adapted to the hardware architecture of the first central processing unit. If the hardware architecture of the second graphics processor is not compatible with that of the first graphics processor, the compiler of the second graphics processor is called to compile the intermediate code to obtain a second executable code that is compatible with the hardware architecture of the second graphics processor. The third executable code is run on a second central processing unit in the second heterogeneous resource object, and the second executable code is run on a second graphics processing unit in the second heterogeneous resource object, so as to run the target program on the second heterogeneous resource object.

12. An electronic device, characterized in that, include: Memory and processor; The memory is used to store a computer program; the processor, coupled to the memory, is used to execute the computer program to implement the steps of the method according to any one of claims 1-10 and 11.

13. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method according to any one of claims 1-10 and 11.

14. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the processor is caused to perform the steps in the method of any one of claims 1-10 and 11.

Images