Data processing method and device, equipment and storage medium

Abstract

The application discloses a data processing method and device, equipment and a storage medium, relates to the technical field of data processing, and is used for developing a custom operator, thereby solving the problems that an operator development framework is too large and framework maintenance is very complex. The method is used for an operator development framework, and the method comprises the following steps: acquiring source code of a custom operator, wherein the custom operator comprises at least two basic operators; wherein an operator library of a target hardware platform to be executed by the custom operator pre-stores the at least two basic operators, the basic operators are basic operators that are common to multiple hardware platforms, and the multiple hardware platforms comprise the target hardware platform; and analyzing the source code to obtain a topology structure file of the custom operator, wherein the topology structure file is used for indicating that the target hardware platform executes the custom operator to call the at least two basic operators from the operator library and the calculation logic of the at least two basic operators.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a data processing method, apparatus, device and storage medium. Background Technology

[0002] In related technologies, deep learning operators are typically written into platform-executable code using hardware instructions. However, because different hardware platforms require dedicated code generation backends for writing executable code, the platform versatility of deep learning operators is poor. Furthermore, since each new hardware platform requires an additional code generation backend to write executable code for that new hardware platform, the entire operator development framework becomes excessively large and its maintenance extremely complex. Summary of the Invention

[0003] This application provides a data processing method, apparatus, device, and storage medium for custom operator development, thereby solving the problem of excessively large operator development frameworks and highly complex framework maintenance.

[0004] To achieve the above objectives, the embodiments of this application provide the following technical solutions:

[0005] Firstly, a data processing method is provided, comprising: obtaining the source code of a custom operator, wherein the custom operator includes at least two basic operators; wherein at least two basic operators are pre-stored in the operator library of the target hardware platform to be executed, the basic operators being common to multiple hardware platforms, including the target hardware platform; parsing the source code to obtain a topology structure file of the custom operator, the topology structure file being used to instruct the target hardware platform to call at least two basic operators from the operator library when executing the custom operator, and the computational logic of at least two basic operators.

[0006] Because the source code of custom operators is composed of basic operators common to various hardware platforms, it is independent of the characteristics of each hardware platform, thus enabling the source code of custom operators to be applied to different hardware platforms. Furthermore, by parsing the source code, a topology file for the custom operator is obtained. This topology file instructs the target hardware platform to retrieve at least two basic operators from the operator library and execute these operators according to the computational logic indicated in the topology file. In other words, different hardware platforms can all implement the operation of custom operators through this topology file, thereby achieving multi-platform universality for custom operators. Moreover, since a hardware platform can execute custom operators based on the topology file and its own operator library, it is unnecessary to add a code generation backend for each hardware platform, greatly reducing the amount of code in the operator development framework and simplifying code maintenance.

[0007] In one possible implementation, the topology file includes parameter information for each basic operator, which is used to determine the parameters of at least two basic operators invoked by the target hardware platform.

[0008] This possible implementation helps to ensure that, when at least two basic operators are configured with parameters, the parameters of at least two basic operators are not missing, thereby ensuring the accuracy of each basic operator and thus ensuring the accuracy of the custom operator.

[0009] In one possible implementation, the method further includes: issuing a prompt message when it is determined that the custom operator includes a target operator that does not belong to the operator library; wherein the prompt message is used to instruct the user to modify the target operator.

[0010] This possible implementation, by issuing a prompt message when the hardware platform's operator library does not include basic operators, reminds operator developers to rewrite them, which helps prevent the hardware platform from being unable to execute custom operators.

[0011] In one possible implementation, the operator development framework includes a pre-configured basic operator call interface library, which includes call interfaces for basic operators common to multiple hardware platforms; obtaining the source code of a custom operator, including: obtaining the source code of a custom operator generated based on the operator call interface library, the source code including call interfaces for at least two basic operators; parsing the source code to obtain a topology structure file of the custom operator, including: parsing the source code to obtain the topological relationship between the call interfaces of at least two basic operators; and at least two call interfaces for basic operators, used by the target hardware platform to call at least two basic operators from the operator library when executing the custom operator.

[0012] This possible implementation provides users with a basic operator call interface library, allowing users to write source code for custom operators without needing to understand the characteristics of the hardware platform or be familiar with operator development programming languages. This results in low operator development difficulty and high development efficiency.

[0013] In one possible implementation, the source code also includes a platform identifier for the target hardware platform; the topology file also includes a platform identifier to instruct the target hardware platform to obtain the topology file before running the custom operator.

[0014] This possible implementation involves configuring a platform identifier in the topology file. When the hardware platform device obtains the topology file, it can use the platform identifier to retrieve the corresponding topology file, thus ensuring the accuracy of the topology file retrieval by the hardware platform.

[0015] In one possible implementation, after parsing the source code and obtaining the topology file of the custom operator, the method further includes: determining the custom operator in the neural network; obtaining the pre-stored topology file of the custom operator; calling at least two basic operators from the operator library of the target hardware platform based on the topology file, and running at least two basic operators based on the computational logic of the at least two basic operators indicated by the topology file.

[0016] This possible implementation enables secondary utilization of the underlying driver acceleration library (i.e., operator library) of the hardware platform, thereby maximizing the performance of the hardware platform and helping to improve the performance of custom operators.

[0017] Secondly, a data processing apparatus is provided for an operator development framework. The apparatus includes functional units for executing any of the methods provided in the first aspect. The actions performed by each functional unit are implemented in hardware or by executing corresponding software through hardware. For example, the data processing apparatus may include: an operator programming unit and a code parsing unit; the operator programming unit is used to obtain the source code of a custom operator, which includes at least two basic operators; wherein at least two basic operators are pre-stored in the operator library of the target hardware platform to be executed, and the basic operators are common to multiple hardware platforms, including the target hardware platform; the code parsing unit is used to parse the source code to obtain a topology structure file of the custom operator, which instructs the target hardware platform to call at least two basic operators from the operator library and the computational logic of the at least two basic operators when executing the custom operator.

[0018] Thirdly, a computer device is provided, comprising: a processor and a memory. The processor is connected to the memory, the memory being used to store computer execution instructions, and the processor executing the computer execution instructions stored in the memory, thereby implementing any of the methods provided in the first aspect.

[0019] Fourthly, a chip is provided, comprising: a processor and an interface circuit; the interface circuit for receiving code instructions and transmitting them to the processor; and the processor for executing the code instructions to perform any of the methods provided in the first aspect.

[0020] Fifthly, a computer-readable storage medium is provided, including computer-executable instructions that, when executed on a computer, cause the computer to perform any of the methods provided in the first aspect.

[0021] In a sixth aspect, a computer program product is provided, including computer execution instructions that, when executed on a computer, cause the computer to perform any of the methods provided in the first aspect.

[0022] The technical effects of any of the implementation methods in aspects two through six can be found in the technical effects of the corresponding implementation methods in aspect one, and will not be repeated here. Attached Figure Description

[0023] Figure 1 A schematic diagram illustrating an operator development scheme in a related art provided in an embodiment of this application;

[0024] Figure 2 A schematic diagram of an operator development scheme in another related technology provided for an embodiment of this application;

[0025] Figure 3 A schematic diagram of an operator development scheme in another related technology provided for an embodiment of this application;

[0026] Figure 4 A schematic diagram of a computer device provided in an embodiment of this application;

[0027] Figure 5 A schematic diagram of another computer device provided in the embodiments of this application;

[0028] Figure 6 A flowchart illustrating a data processing method provided in an embodiment of this application;

[0029] Figure 7 A schematic diagram of a data processing method provided in an embodiment of this application;

[0030] Figure 8 A schematic diagram illustrating a data processing method provided in an embodiment of this application;

[0031] Figure 9 A schematic diagram of a data processing method provided in an embodiment of this application;

[0032] Figure 10 This is a schematic diagram of an operator function image provided in an embodiment of this application;

[0033] Figure 11 A schematic diagram of a topological relationship provided for an embodiment of this application;

[0034] Figure 12 A flowchart illustrating another data processing method provided in an embodiment of this application;

[0035] Figure 13 A schematic diagram illustrating another data processing method provided in an embodiment of this application;

[0036] Figure 14 A schematic diagram illustrating another data processing method provided in an embodiment of this application;

[0037] Figure 15 This is a schematic diagram of the composition of a data processing device provided in an embodiment of this application. Detailed Implementation

[0038] In the description of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B. The "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Furthermore, "at least one" means one or more, and "multiple" means two or more. The terms "first," "second," etc., do not limit the quantity or order of execution, and "first," "second," etc., do not necessarily imply differences.

[0039] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0040] First, a brief introduction to the application scenarios involved in this application will be given.

[0041] An operator is a mapping from one function space to another. In a general sense, any operation performed on any function can be considered an operator; for example, addition, subtraction, multiplication, division, or square root are all operators. Based on this, in the field of deep learning, computational layers can be viewed as deep learning operators within a deep learning network, such as convolutional layers and pooling layers.

[0042] In related technologies, deep learning operators are typically written into platform-executable code using hardware instructions. However, because different hardware platforms require dedicated code generation backends for writing executable code, the platform versatility of deep learning operators is poor. Furthermore, since each new hardware platform requires an additional code generation backend to write executable code for that new hardware platform, the entire operator development framework becomes excessively large and its maintenance extremely complex.

[0043] For example, such as Figure 1 As shown, in the first related operator development scheme, such as Figure 1 As shown in (A), this scheme uses the operator instruction set provided by the operator development framework to develop custom operators. Since developing custom operators using the operator instruction set outputs the hardware platform's operator instruction set implementation code, different hardware platforms require different operator implementation code to run in order to achieve the functionality of the custom operator. Specifically, as... Figure 1 As shown in (B), to implement this operator development scheme, operator development is divided into three independent steps: computational expression, computational scheduling, and code generation. Since code generation requires a separate module, a code generation module needs to be developed in advance for each new hardware platform. Furthermore, as... Figure 1 As shown in (C), this scheme also designs an intermediate representation (i.e., Tensor Expression Language, also known as TVM IR) to express the computational logic of the operator. Further, the operator development framework used to implement this operator development scheme includes a computational representation module, a scheduling optimization module, and a code generation module. The computational representation module is used to describe the basic computational logic of the operator (such as the computational logic of the convolution operator) using the intermediate representation, that is, to accurately describe what tasks the operator needs to complete, what the input is, and what the output is. The scheduling optimization module is used to optimize the intermediate representation according to the characteristics of different hardware platforms, explicitly giving the specific computation or execution process of the operator so that the operator can achieve optimal running efficiency on such hardware platforms, for example, as... Figure 2 The scheduling optimization module is shown. The code generation module converts the optimized intermediate representation into executable code for a specific hardware platform.

[0044] Below, on Figure 2 The following explains LLVM, GPU, OpenCL, Caffe2, CNTK, and Core ML:

[0045] LLVM (Low Level Virtual Machine) is a framework system for building compilers. It is written in C++ and is used to optimize the compile-time, link-time, run-time, and idle-time of programs written in any programming language. It remains open to developers and is compatible with existing scripts.

[0046] GPU (Graphics Processing Unit): Also known as a graphics core, visual processor, or display chip, it is a microprocessor specifically designed for performing image and graphics-related calculations on personal computers, workstations, game consoles, and some mobile devices (such as tablets and smartphones).

[0047] OpenCL (Open Computing Language) is the first open and free standard for general-purpose parallel programming of heterogeneous systems. It is also a unified programming environment that makes it easy for software developers to write efficient and lightweight code for high-performance computing servers, desktop computing systems, and handheld devices. It is also widely applicable to multi-core processors (CPUs), graphics processing units (GPUs), Cell-type architectures, and other parallel processors such as digital signal processors (DSPs). It has broad development prospects in various fields such as games, entertainment, scientific research, and medicine.

[0048] Caffe2 (Convolutional Architecture for Fast Feature Embedding) is a framework for computing algorithms related to CNNs (Convolutional Neural Networks), implemented in C++ and Python.

[0049] CNTK (Computational Network Toolkit): An open-source deep learning toolkit from Microsoft that supports both CPU and GPU modes.

[0050] Core ML is a machine learning framework provided by Apple. Core ML supports a variety of machine learning models, including Neural Networks, Tree Ensembles, Support Vector Machines, and Generalized Linear Models.

[0051] This operator development approach presents several challenges for users. Because it involves developing custom operators using the operator instruction set provided by the operator development framework, and requires different scheduling optimization strategies for different hardware platforms, users need a deep understanding of hardware characteristics and familiarity with operator development programming syntax. This is necessary to use the specified syntax to develop the operator's computational and scheduling logic based on the hardware characteristics. Furthermore, the reliance on the operator instruction set provided by the framework makes it overly dependent on third-party libraries, and the process is cumbersome. In addition to developing the operator instruction set, users also need to implement the operator's computational logic (i.e., intermediate representation) and necessary scheduling optimizations, resulting in a large workload and low operator development efficiency.

[0052] This operator development scheme presents several challenges for technical personnel. The deep coupling between the scheduling optimization phase and specific hardware platforms makes it difficult to reuse the scheduling optimization code across multiple platforms. In other words, when the same operator is used for scheduling optimization on multiple hardware platforms, scheduling optimization code needs to be developed for each platform, resulting in low development efficiency for the operator development framework. Furthermore, each new hardware platform requires a manually written code generation module, leading to a large amount of code development work. Multiple scheduling optimization templates need to be set for different hardware characteristics, making the process cumbersome, and the code generation module itself is large and inconvenient to maintain.

[0053] Furthermore, due to the different structures of different hardware platforms, the executable code for different hardware platforms is also different. Therefore, the operator development framework of this operator development scheme needs to be configured with different code generation modules for different hardware platforms. This results in poor universality of the operator development framework, and the entire operator development framework is very large, occupying hundreds of megabytes of storage space, making code maintenance very difficult.

[0054] For example, such as Figure 3 As shown, in the second related operator development scheme, multiple hardware platforms are abstracted, and the hardware functions of the hardware platforms are abstracted into computing core interfaces, so that scheduling optimization code can be reused on multiple hardware platforms. However, different code generation modules still need to be configured for different hardware platforms, resulting in poor versatility of the operator development framework. Moreover, the entire operator development framework is very large, occupying hundreds of megabytes of storage space, and the code is very difficult to maintain.

[0055] Furthermore, since the two operator development schemes mentioned above generate executable code for the hardware platform through a custom intermediate representation and optimize the custom intermediate representation through the scheduling optimization code of the scheduling optimization module to improve the performance of the operator on the hardware platform, it is necessary to continuously design optimization templates and perform a large number of scheduling optimization calculations, which not only involves a huge workload but also has very low efficiency.

[0056] To address the aforementioned issues, this application provides a data processing method that uses common basic operators across multiple hardware platforms to compose custom operators. This makes the custom operators independent of the characteristics of each hardware platform, thus enabling them to be applied to different hardware platforms. Furthermore, by parsing the source code, a topology file for the custom operators is obtained. This topology file instructs the target hardware platform to retrieve at least two basic operators from its built-in operator library and execute these two basic operators according to the computational logic indicated by the topology file, thereby enabling the operation of the custom operators and achieving multi-hardware platform universality. Moreover, since the hardware platform can execute the custom operators based on the topology file and its own operator library, it is unnecessary to add a code generation backend for each hardware platform, significantly reducing the amount of code in the operator development framework and simplifying framework maintenance.

[0057] Furthermore, since the hardware platform uses basic operators from its own operator library to execute custom operators, and the basic operators in its own operator library are necessarily the most compatible with the platform, there is no longer a need to set scheduling optimization templates for custom operators based on the characteristics of each hardware platform, which greatly reduces the workload.

[0058] Finally, a brief introduction to the implementation environment (implementation architecture) involved in this application is given.

[0059] This application provides a data processing method applicable to computer equipment. This application does not limit the specific form of the computer equipment. For example, the computer equipment can be a terminal device or a network device. The terminal device can be referred to as: terminal, user equipment (UE), terminal device, access terminal, user unit, user station, mobile station, remote station, remote terminal, mobile device, user terminal, wireless communication equipment, user agent, or user equipment, etc. Specifically, the terminal device can be a mobile phone, augmented reality (AR) device, virtual reality (VR) device, tablet computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc. The network device can be a server, etc. The server can be a single physical or logical server, or two or more physical or logical servers sharing different responsibilities and cooperating to achieve the various functions of the server.

[0060] In terms of hardware implementation, the aforementioned computer equipment can be implemented through, for example... Figure 4 The computer device shown is implemented as follows. Figure 4 The diagram shown is a hardware structure schematic of a computer device 400 provided in an embodiment of this application. The computer device 400 can be used to implement the functions of the aforementioned computer device.

[0061] Figure 4 The computer device 400 shown may include a processor 401, a memory 402, a communication interface 403, and a bus 404. The processor 401, the memory 402, and the communication interface 403 can be connected via the bus 404.

[0062] The processor 401 is the control center of the computer device 400. It can be a general-purpose central processing unit (CPU) or other general-purpose processors. The general-purpose processor can be a microprocessor or any conventional processor.

[0063] As an example, processor 401 may include one or more CPUs, for example Figure 4 CPU 0 and CPU 1 are shown in the diagram.

[0064] The memory 402 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0065] In one possible implementation, the memory 402 may exist independently of the processor 401. The memory 402 can be connected to the processor 401 via a bus 404 and is used to store data, instructions, or program code. When the processor 401 calls and executes the instructions or program code stored in the memory 402, it can implement the data processing method provided in the embodiments of this application.

[0066] In another possible implementation, the memory 402 can also be integrated with the processor 401.

[0067] Communication interface 403 is used for connecting computer device 400 to other devices via a communication network, which may be Ethernet, radio access network (RAN), wireless local area network (WLAN), etc. Communication interface 403 may include a receiving unit for receiving data and a transmitting unit for transmitting data.

[0068] Bus 404 can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0069] It should be pointed out that, Figure 4 The structure shown does not constitute a limitation on the computer device 400, except... Figure 4 In addition to the components shown, computer device 400 may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0070] In one possible implementation, such as Figure 5 As shown, the operator development framework includes an operator programming layer, a code parsing layer, a topology storage layer, and an operator execution layer.

[0071] The operator programming layer is used to interact directly with users (i.e., operator developers) and obtain the source code of user-written custom operators. This source code is written by the user based on the basic operator call interfaces obtained from the operator programming layer's basic operator call interface library, and the computational logic of the custom operators.

[0072] The code parsing layer is used to parse the source code of user-written custom operators, thereby obtaining the topological relationship between the calling interfaces of multiple basic operators in the source code and the parameter information of each basic operator.

[0073] The topology storage layer is used to save the topological relationships between the calling interfaces of multiple basic operators and the parameter information of each basic operator into the topology structure file, and then pass the topology structure file to the operator execution layer.

[0074] The operator execution layer is used to call the basic operators in the operator library of the hardware platform according to the information in the topology structure file, and at the same time fill in the parameters of the basic operators according to the parameter information in the topology structure file, so as to run the custom operators and realize the functions of the custom operators.

[0075] like Figure 6 The diagram shown is a flowchart of a data processing method provided in this application, which is used in an operator development framework. The method includes:

[0076] S601: Obtain the source code of the custom operator, which includes at least two basic operators; the target hardware platform to execute the custom operator has at least two basic operators pre-stored in its operator library.

[0077] Among them, basic operators are common to multiple hardware platforms, including the target hardware platform. For example, basic operators can be addition, subtraction, multiplication, division, and activation operators (ReLU).

[0078] Optionally, the hardware platform includes at least a graphics processing unit (GPU) platform, a digital signal processing (DSP) platform, and an advanced RISC processor (ARM) or application-specific integrated circuit (ASIC) dedicated accelerator platform.

[0079] In one implementation, the neural network model includes multiple operators. Before running the neural network model on the target hardware platform, these operators need to be analyzed to identify those that the target hardware platform does not support. This analysis can be performed manually by the user or automatically by a computer. Operators not supported by the target hardware platform are the custom operators that the user needs to develop.

[0080] Optionally, the operator development framework includes a pre-configured basic operator calling interface library, which includes calling interfaces for basic operators that are common to multiple hardware platforms.

[0081] In one implementation, such as Figure 7As shown, computer equipment pre-encapsulates the calling interfaces of basic operators for multiple hardware platforms, resulting in a basic operator calling interface library, thus providing users with a large number of basic operator calling interfaces. This basic operator calling interface library is pre-stored in the operator programming layer of the operator development framework, allowing users to directly call the calling interfaces of basic operators from the library for programming. Because the calling interfaces of basic operators in the basic operator calling interface library are not affected by the characteristics of the hardware platform, the source code written using the calling interfaces of basic operators in the library is universal across multiple hardware platforms.

[0082] Furthermore, the API interfaces in the basic operator API library can be invoked using a unified programming language, such as Python, C, or C++. Users can program using this common programming language, calling the API interfaces of the basic operators in the library, and writing source code for their custom operators.

[0083] It should be noted that since different hardware platforms have basically the same requirements for the number of parameters of basic operators, for example, the input of the addition operator on different hardware platforms is two parameters. Therefore, by uniformly encapsulating the basic operator calling interface of the hardware platform, the resulting basic operator calling interface library is applicable to multiple hardware platforms.

[0084] Optionally, obtaining the source code of the custom operator includes: obtaining the source code of the custom operator generated based on the operator call interface library, wherein the source code includes call interfaces for at least two basic operators. Since the call interfaces for at least two basic operators are common to various hardware platforms, it is possible to obtain a custom operator by combining the call interfaces of basic operators common to multiple hardware platforms, thereby enabling the custom operator to be universal across platforms. In other words, it achieves the "white-box" nature of the custom operator, improves the development efficiency of the custom operator, and reduces the development difficulty of the custom operator.

[0085] In one implementation, the user programs by calling the API interfaces of basic operators in the basic operator API library to obtain the source code of a custom operator. For example, the user can write the source code of a custom operator by calling the API interfaces of basic operator 1, basic operator 2, basic operator 3, and basic operator 4. This custom operator includes basic operator 1, basic operator 2, basic operator 3, and basic operator 4. Furthermore, after the user completes the writing of the source code of the custom operator, the operator programming layer of the operator development framework obtains the source code of the custom operator.

[0086] It should be noted that when using the data processing method of this application to develop custom operators, users only need to write the source code of the custom operators, and all other subsequent steps are completed by the operator development framework.

[0087] In this scheme, since the source code of the custom operator is written by calling the calling interface of the basic operator, the custom operator can be obtained by combining the basic operators. Furthermore, since the calling interface of the basic operator is common to multiple hardware platforms, the source code of the custom operator is applicable to multiple hardware platforms, thus providing users with the source code of a custom operator that is common to multiple hardware platforms.

[0088] Optionally, the source code also includes a platform identifier for the target hardware platform. The data processing method further includes: obtaining the platform identifier of the target hardware platform.

[0089] In one implementation, after the user has written the source code for the custom operator, they specify the target hardware platform to run the custom operator. For example, the platform identifier of the target hardware platform can be written into the source code. That is, the source code also includes the platform identifier of the target hardware platform, so that the operator development framework can obtain the platform identifier of the target hardware platform.

[0090] For example, if the target hardware platform A needs to use a custom operator, the user writes the platform identifier A of the target hardware platform A into the source code when writing the source code of the custom operator.

[0091] It should be noted that since the source code of the custom operator is universal across multiple hardware platforms, after adding platform identifier A to the source code, when the target hardware platform B needs to use the source code of the custom operator, the user only needs to modify platform identifier A in the source code to platform identifier B of the target hardware platform B; no other parts need to be modified. Therefore, adding the platform identifier of the target hardware platform to the source code of the custom operator does not affect the universality of the custom operator's source code.

[0092] By configuring the platform identifier in the source code, the target hardware platform for running the custom operator can be specified, which helps to ensure that the topology file of the custom operator is accurately transmitted to the target hardware platform, thereby ensuring that the target hardware platform can run the custom operator smoothly.

[0093] S602: Parse the source code to obtain the topology structure file of the custom operator. The topology structure file is used to instruct the target hardware platform to call at least two basic operators from the operator library and the computational logic of at least two basic operators when executing the custom operator.

[0094] Optionally, the source code is parsed to obtain a topology file for the custom operator, including: parsing the source code to obtain the topology relationship between the calling interfaces of at least two basic operators. The calling interfaces of at least two basic operators are used by the target hardware platform to call at least two basic operators from the operator library when executing the custom operator.

[0095] Optionally, the topology is used to characterize the computational logic or execution order between at least two basic operators corresponding to the calling interfaces of at least two basic operators. For example, the topology could be basic operator 1 → basic operator 3 → basic operator 2 → basic operator 4, that is, basic operator 1 is executed first, basic operator 3 next, basic operator 2 next, and basic operator 4 is executed last.

[0096] In one implementation, the topology file includes the topological relationships between the calling interfaces of at least two basic operators. Users write source code for custom operators based on the calling interfaces of at least two basic operators in the basic operator calling interface library. When the operator development framework parses the source code, it obtains the topology file of the custom operator, that is, the topological relationships between the calling interfaces of at least two basic operators. The calling interfaces of the at least two basic operators instruct the target hardware platform to call at least two basic operators from the operator library and specify the calling paths for those basic operators. The topological relationships indicate the computational logic of the at least two basic operators, thus enabling the topology file to instruct the target hardware platform to call at least two basic operators from the operator library and specify the computational logic of those basic operators when executing the custom operator.

[0097] In this application, the basic operator call interface library includes call interfaces for basic operators that are common to multiple hardware platforms. Users generate source code for custom operators based on the call interfaces of the basic operators in the basic operator call interface library. The operator development framework parses the source code to obtain the topological relationship between the call interfaces of at least two basic operators, thereby obtaining the call interfaces and topological relationship of at least two basic operators that can be used by multiple hardware platforms, that is, obtaining a topology structure file that can be used by multiple hardware platforms.

[0098] Optionally, the topology file also includes parameter information for each basic operator. That is, the operator development framework obtains the parameter information for each basic operator when parsing the meta-database. This parameter information is used to determine the parameters of at least two basic operators called by the target hardware platform. By including parameter information in the topology file, it is possible to ensure that parameters for at least two basic operators are not missing, even when those operators are configured with parameters. This guarantees the accuracy of each basic operator and, consequently, the accuracy of custom operators.

[0099] In one implementation, when the target hardware platform executes a custom operator based on a topology structure file, it first calls at least two basic operators from its built-in operator library based on the calling interface of at least two basic operators in the topology relationship, and fills the parameters of at least two basic operators based on the parameter information of each basic operator. Then, based on the calculation logic or execution order between at least two basic operators indicated by the topology relationship, it executes at least two basic operators, thereby realizing the execution of the custom operator.

[0100] In one implementation, such as Figure 8 As shown, the operator programming layer of the operator development framework obtains the source code, and the topology parsing layer of the operator development framework performs topology parsing on the source code to obtain the topology relationship between the calling interfaces of at least two basic operators and the parameter information of each basic operator.

[0101] In one example, after the operator programming layer of the operator development framework obtains the source code of the custom operator, the code parsing layer of the operator development framework automatically parses the source code to obtain the topological relationship between the calling interfaces of at least two basic operators and the parameter information of each basic operator.

[0102] In another example, after the operator programming layer obtains the source code of the custom operator, the user needs to call the operator compilation instruction to start the code parsing layer, so that the code parsing layer can start parsing the source code and obtain the topological relationship between the calling interfaces of at least two basic operators and the parameter information of each basic operator.

[0103] In one implementation, such as Figure 9 As shown in (A), the user calls the basic operator call interfaces op1, op2, op3, op4, op5, and op6 in the basic operator call interface library to program and obtain the source code of the custom operator. The operator development framework performs topological parsing on the source code to obtain the following... Figure 9 The topological relationships between the aforementioned basic operator call interfaces, as well as the parameter information of each basic operator, are shown in (B). In this process, because general-purpose programming languages ​​such as Python, C, or C++ are used, users do not need to be familiar with other operator development programming syntax. Furthermore, since programming is done by calling the basic operator call interfaces in the basic operator call interface library, users do not need to master the characteristics of any hardware platform; they only need to understand the computational logic of each basic operator that makes up the custom operator. This results in low development difficulty, minimal workload, and high development efficiency.

[0104] In one implementation, when a new hardware platform needs to use a custom operator that has already been developed, it is only necessary to match the basic operator calling interface of the new hardware platform with the basic operator calling interface library. There is no need to develop a code generation backend for the new hardware platform, nor is there any need to modify the generation logic of the custom operator. The original source code of the custom operator is still useful, truly realizing the beneficial effect of reusing a set of source code across multiple hardware platforms.

[0105] In one implementation, the development of the GELU (Gaussian Error Linear Unit) operator is used as an example. GELU is a non-elementary activation function, a variant of ReLU, and its calculation formula is as follows:

[0106]

[0107] The operator function graphs for GELU, RELU, and ELU are as follows: Figure 10 As shown.

[0108] GELU is a novel activation function in deep learning algorithms, not a common deep learning operator. Currently, few hardware platforms support its operation, necessitating manual development. Following existing operator development methods requires familiarity with operator programming syntax to utilize the operator instruction set provided by the development framework, and an understanding of the hardware platform's characteristics for targeted scheduling optimization. This makes development quite challenging.

[0109] However, when developing this operator using the data processing method of this application, the operator developer directly calls the basic operator calling interface in the basic operator calling interface library for programming. For example, writing the GELU source code as shown below and inputting it into the operator programming module of the operator development framework completes the development of the operator. The code parsing module of the operator development framework parses the GELU source code to obtain the following... Figure 11 The topological relationships shown, along with the parameter information of each basic operator, are illustrated. For example, in b = multiply(a, 0.044715), the parameter information of the multiply operator is 0.044715. It can be seen that the entire operator development process does not require any knowledge of the hardware characteristics of the hardware platform, significantly reducing development difficulty. Furthermore, the operator development method proposed in this application has a very simple syntax, directly calling the basic operator call interface in the basic operator call interface library for programming, resulting in very high development efficiency.

[0110] Among them, Figure 11 In this context, power represents the calling interface of the square root operator, mul represents the calling interface of the multiplication operator, add represents the calling interface of the addition operator, and tanh represents the calling interface of the hyperbolic tangent operator.

[0111] The source code for GELU is shown below:

[0112] def grelu_demo(A):

[0113] a = power(A, 3)

[0114] b = multiply(a, 0.044715)

[0115] c = add(A, b)

[0116] d = multiply(c, 0.797884)

[0117] e = tanh(d)

[0118] f = add(e, 1)

[0119] g = multiply(f, A)

[0120] h = multiply(g, 0.5)

[0121] return h

[0122] In the above embodiments, by providing users with a basic operator call interface library, users can write source code for custom operators without needing to understand the characteristics of the hardware platform or be familiar with operator development programming languages. This makes operator development easier and more efficient.

[0123] In one implementation, after obtaining the topology file of the custom operator, the operator development framework sends the topology file to the operator execution layer. For example, the operator execution layer can be the inference framework of the neural network model. The operator execution layer calls the basic operator 1, basic operator 2, basic operator 3, and basic operator 4 from the operator library provided by the target hardware platform, fills in the basic operator parameters according to the parameter information in the topology file, and executes the four basic operators sequentially based on the topological relationship in the topology file (i.e., basic operator 1 → basic operator 3 → basic operator 2 → basic operator 4), thereby realizing the operation of the custom operator. That is, it realizes the operation of operators in the neural network model that are not originally supported by the target hardware platform.

[0124] In one example, after obtaining the topological relationship between the calling interfaces of at least two basic operators and the parameter information of each basic operator, the code parsing layer stores the topological relationship between the calling interfaces of at least two basic operators and the parameter information of each basic operator in a topology structure file, and sends the topology structure file to the operator execution layer for use. Alternatively, the code parsing layer can also store the topology structure file within itself, which can then be actively invoked by the operator execution layer.

[0125] In one example, after the code parsing layer parses the topological relationship between the calling interfaces of at least two basic operators and the parameter information of each basic operator from the source code of the custom operator, the topology storage layer stores the topological relationship between the calling interfaces of at least two basic operators and the parameter information of each basic operator into the topology structure file of the topology storage layer, and sends the topology structure file to the operator execution layer for use by the operator execution layer. Alternatively, the topology storage layer can also store the topology structure file itself, which can be actively invoked by the operator execution layer.

[0126] In this scheme, the data processing method shields the underlying hardware structure information and does not depend on the hardware structure information of any hardware platform. By generating a topology structure file that can instruct the target hardware platform to call at least two basic operators and the computational logic of at least two basic operators from the operator library, the target hardware platform can run the custom operator based on the topology structure file. This eliminates the need to generate different executable code for different hardware platforms based on their characteristics, thereby achieving efficient development of custom operators that are universal across multiple hardware platforms.

[0127] Furthermore, since it is not necessary to generate proprietary executable code for each hardware platform, the operator development framework no longer needs to configure a code generation layer for each hardware platform, thereby achieving a lightweight operator development framework, greatly reducing the amount of code, and making framework maintenance simpler and more convenient.

[0128] Optionally, the topology file may also include a platform identifier to instruct the target hardware platform to obtain the topology file before running the custom operator.

[0129] In one implementation, the operator development framework obtains the platform identifier by parsing the source code and stores the platform identifier in a topology file.

[0130] In one implementation, after parsing the source code and obtaining the topology structure file, the operator development framework sends the topology structure file to the target hardware platform corresponding to the platform identifier. For example, the code parsing layer or the topology storage layer of the operator development framework may send the topology structure file to the target hardware platform corresponding to the platform identifier.

[0131] In another implementation, before running a custom operator, the operator execution layer obtains a topology file from the operator development framework, for example, from the code parsing layer or topology storage layer of the operator development framework. Specifically, when obtaining the topology file, the operator execution layer reads the platform identifier in the topology file to determine the topology file that includes the platform identifier of the target hardware platform, thereby obtaining the topology file.

[0132] Configuring a platform identifier in the topology file helps improve the accuracy of the hardware platform in obtaining the topology file, enabling the hardware platform to obtain the topology file corresponding to the custom operator to be executed, thereby ensuring that the target hardware platform can run the custom operator smoothly.

[0133] In the above embodiments, by using basic operators common to multiple hardware platforms to form custom operators, the custom operators are unaffected by the characteristics of different hardware platforms, thus enabling the custom operators to be applicable to different hardware platforms. Furthermore, by parsing the source code to obtain the topology structure file of the custom operator, this topology structure file can instruct the target hardware platform to obtain at least two basic operators from its own operator library and execute these at least two basic operators according to the computational logic indicated by the topology structure file, thereby realizing the operation of the custom operator and achieving multi-hardware platform universality of the custom operator. Furthermore, since the hardware platform can execute the custom operator based on the topology structure file and its own operator library, it is unnecessary to add a code generation backend for each hardware platform, greatly reducing the amount of code in the operator development framework and simplifying framework maintenance.

[0134] Furthermore, since the hardware platform uses basic operators from its own operator library to execute custom operators, and the basic operators in its own operator library are necessarily the most compatible with the platform, there is no longer a need to set up scheduling optimization templates for custom operators for the characteristics of each hardware platform, which greatly reduces the workload.

[0135] In one possible implementation, the data processing method further includes:

[0136] If it is determined that the custom operator includes a target operator that does not belong to the operator library, a prompt message will be issued.

[0137] The prompt message is used to instruct the user to modify the target operator.

[0138] Optionally, the prompt message includes the target operator. By including the target operator in the prompt message, users can quickly locate target operators that are not in the operator library, without having to check each custom operator individually, thus improving efficiency.

[0139] In one implementation, each operator included in the custom operator is determined, for example, operator 1, operator 2, operator 3, and operator 4. The basic operators included in the operator library of the target hardware platform are also determined, for example, operator 1, operator 2, and operator 4. Therefore, operator 3 is a target operator that does not belong to the operator library. At this point, the computer device issues a prompt message indicating that the target operator should be modified, that is, operator 3 should be modified.

[0140] In another implementation, each operator included in the custom operator is matched one by one with the operators in the operator library of the target hardware platform. If each operator includes a target operator that does not match an operator in the operator library, a prompt message is issued to remind the user that a custom operator combination using an operator not belonging to the operator library of the target hardware platform is used. This ensures that all the basic operators in the custom operator are pre-stored in the operator library of the target hardware platform.

[0141] In the above embodiments, if it is determined that the custom operator includes a target operator that does not belong to the operator library, a prompt message is issued to the user, indicating that the user has used a custom operator combination from an operator library that does not belong to the target hardware platform, and then instructs the user to modify the target operator, thereby preventing the target hardware platform from being unable to execute the custom operator.

[0142] In one possible implementation, combining Figure 6 ,like Figure 12 As shown, the data processing method also includes:

[0143] S121: Determine the custom operators in the neural network.

[0144] In one implementation, such as Figure 13 As shown, before the neural network model runs, during the inference phase, the inference framework constructs a graph of the neural network model's structure. During this graphing process, operators not supported by the hardware platform are identified as custom operators, such as Custom OPs.

[0145] S122: Obtain the topology file of the pre-stored custom operator.

[0146] In one implementation, such as Figure 13 As shown, after determining the custom operator, the code execution layer obtains the pre-stored topology structure file of the custom operator, automatically parses the topology structure file of the custom operator, obtains the topological relationships between the calling interfaces of the basic operators that make up the custom operator and the parameter information of each basic operator, and then constructs the topology graph of the custom operator based on the topology relationships and parameter information, and re-graphs the neural network model based on the topology graph of the custom operator. After the neural network model is re-graphed, the neural network model will enter the graph optimizer to perform graph optimization operations, and finally call the basic operators in the operator library of the hardware platform to run the neural network model.

[0147] S123: Based on the topology file, call at least two basic operators from the operator library of the target hardware platform, and run at least two basic operators based on the computational logic of the at least two basic operators indicated by the topology file to realize the operation of the custom operator.

[0148] In one implementation, such as Figure 14 As shown, when the operator runtime layer runs a custom operator, it calls the basic operators that make up the custom operator from the operator library of the target hardware platform. For example, when the target hardware platform 1 runs a custom operator, the operator runtime layer calls the basic operators that make up the custom operator from the operator library of the target hardware platform 1; when the target hardware platform n runs a custom operator, the operator runtime layer calls the basic operators that make up the custom operator from the operator library of the target hardware platform n.

[0149] In the above embodiments, basic operators are called from the operator library of the target hardware platform based on a pre-stored topology structure file of custom operators for the execution of custom operators. This enables secondary utilization of the underlying driver acceleration library of the target hardware platform, thereby maximizing the performance of the target hardware platform. Furthermore, since the execution of custom operators uses basic operators from the target hardware platform's own operator library, compared to the operators provided by the operator development platform in the prior art, the basic operators in the target hardware platform's own operator library have a higher degree of compatibility with the target hardware platform. Therefore, the performance of the executed custom operators is superior.

[0150] The foregoing primarily describes the solutions of the embodiments of this application from a methodological perspective. It is understood that, in order to achieve the above-described functions, the computer device includes at least one of the hardware structures and software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0151] This application embodiment can divide the data processing device into functional units according to the above method example. For example, each function can be divided into its own functional unit, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0152] For example, Figure 15A possible structural diagram of the data processing apparatus (denoted as data processing apparatus 1500) involved in the above embodiments is shown. The data processing apparatus 1500 includes an operator programming unit 1501 and a code parsing unit 1502. The operator programming unit is used to obtain the source code of a custom operator, which includes at least two basic operators. The target hardware platform for executing the custom operator has at least two basic operators pre-stored in its operator library. These basic operators are common to multiple hardware platforms, including the target hardware platform. For example, Figure 6 The S601 shown is a code parsing unit used to parse source code and obtain a topology file for the custom operator. This topology file instructs the target hardware platform to call at least two basic operators from the operator library and the computational logic for those two basic operators when executing the custom operator. For example, Figure 6 S602 is shown in the figure.

[0153] Optionally, the topology file includes parameter information for each basic operator, which is used to determine the parameters of at least two basic operators invoked by the target hardware platform.

[0154] Optionally, the code parsing unit 1502 is further configured to: issue a prompt message when it is determined that the custom operator includes a target operator that does not belong to the operator library; wherein the prompt message is used to instruct the user to modify the target operator.

[0155] Optionally, the operator programming unit 1501 is further configured to: provide an operator development framework including a pre-configured basic operator call interface library, which includes call interfaces for basic operators common to multiple hardware platforms; obtain the source code of a custom operator, including: obtaining the source code of a custom operator generated based on the operator call interface library, the source code including call interfaces for at least two basic operators; parse the source code to obtain a topology structure file of the custom operator, including: parsing the source code to obtain the topological relationship between the call interfaces of at least two basic operators; and provide at least two call interfaces for basic operators, used by the target hardware platform to call at least two basic operators from the operator library when executing the custom operator.

[0156] Optionally, the source code also includes a platform identifier for the target hardware platform, and the topology file also includes a platform identifier to instruct the target hardware platform to obtain the topology file before running the custom operator.

[0157] Optionally, the device further includes an operator execution unit 1503, which is used to determine the custom operators in the neural network after parsing the source code and obtaining the topology file of the custom operators; obtain the pre-stored topology file of the custom operators; call at least two basic operators from the operator library of the target hardware platform based on the topology file, and run at least two basic operators based on the computational logic of the at least two basic operators indicated by the topology file.

[0158] For a detailed description of the above-mentioned optional methods, please refer to the foregoing method embodiments, which will not be repeated here. Furthermore, the explanation of any of the data processing apparatus 1500 provided above, as well as the description of its beneficial effects, can be found in the corresponding method embodiments described above, and will not be repeated here.

[0159] As an example, combined Figure 4 The functions implemented by some or all of the operator programming unit 1501 and code parsing unit 1502 in the data processing device can be achieved through... Figure 4 Processor 401 in the middle executes Figure 4 The program code is implemented in memory 402.

[0160] This application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the methods executed by any of the computer devices described above.

[0161] For explanations of the relevant content and descriptions of the beneficial effects in any of the computer-readable storage media provided above, please refer to the corresponding embodiments described above, which will not be repeated here.

[0162] This application also provides a chip. The chip integrates a control circuit for implementing the functions of the data processing device 1500 described above, and one or more ports. Optionally, the functions supported by the chip can be referred to above, and will not be repeated here. Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium. The storage medium mentioned above can be a read-only memory, random access memory, etc. The processing unit or processor mentioned above can be a central processing unit, a general-purpose processor, an application-specific integrated circuit (ASIC), a microprocessor (digital signal processor, DSP), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof.

[0163] This application also provides a computer program product containing instructions that, when executed on a computer, cause the computer to perform any of the methods described in the above embodiments. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or may include one or more data storage devices such as servers or data centers that can be integrated with the medium. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., SSD), etc.

[0164] It should be noted that the devices for storing computer instructions or computer programs provided in the embodiments of this application, such as but not limited to the memory, computer-readable storage medium and communication chip, are all non-transitory.

[0165] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs).

[0166] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0167] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A data processing method, characterized in that, For an operator development framework, the method includes: Obtain the source code of a custom operator, which includes at least two basic operators; wherein, the at least two basic operators are pre-stored in the operator library of the target hardware platform to execute the custom operator, and the basic operators are common to multiple hardware platforms, including the target hardware platform. The source code is parsed to obtain the topology structure file of the custom operator. The topology structure file is used to instruct the target hardware platform to call the at least two basic operators from the operator library and the computation logic of the at least two basic operators when executing the custom operator. Determine the custom operator in the neural network; Obtain the pre-stored topology file of the custom operator; Based on the topology file, the at least two basic operators are called from the operator library of the target hardware platform, and the at least two basic operators are run based on the computational logic of the at least two basic operators indicated by the topology file.

2. The method according to claim 1, characterized in that, The topology file includes parameter information for each of the basic operators, which is used to determine the parameters of the at least two basic operators invoked by the target hardware platform.

3. The method according to claim 1, characterized in that, The method further includes: If it is determined that the custom operator includes a target operator that does not belong to the operator library, a prompt message is issued; wherein the prompt message is used to instruct the user to modify the target operator.

4. The method according to claim 1, characterized in that, The operator development framework includes a pre-configured basic operator calling interface library, which includes calling interfaces for basic operators common to the multiple hardware platforms; The process of obtaining the source code of the custom operator includes: Obtain the source code of the custom operator generated based on the operator call interface library, wherein the source code includes the call interfaces of the at least two basic operators; The process of parsing the source code to obtain the topology file of the custom operator includes: The source code is parsed to obtain the topological relationship between the calling interfaces of the at least two basic operators; the calling interfaces of the at least two basic operators are used by the target hardware platform to call the at least two basic operators from the operator library when executing the custom operator.

5. The method according to claim 1, characterized in that, The source code also includes the platform identifier of the target hardware platform; The topology file also includes the platform identifier to instruct the target hardware platform to obtain the topology file before executing the custom operator.

6. A data processing apparatus, characterized in that, For an operator development framework, the apparatus includes: An operator programming unit is used to obtain the source code of a custom operator, which includes at least two basic operators; wherein, the at least two basic operators are pre-stored in the operator library of the target hardware platform to execute the custom operator, and the basic operators are common to multiple hardware platforms, including the target hardware platform. The code parsing unit is used to parse the source code to obtain the topology structure file of the custom operator. The topology structure file is used to instruct the target hardware platform to call the at least two basic operators from the operator library and the computation logic of the at least two basic operators when executing the custom operator. The operator execution unit is used to determine the custom operator in the neural network; obtain the topology file of the pre-stored custom operator; call the at least two basic operators from the operator library of the target hardware platform based on the topology file, and run the at least two basic operators based on the computation logic of the at least two basic operators indicated by the topology file.

7. The apparatus according to claim 6, characterized in that, The code parsing unit is also used for: The topology file includes parameter information for each of the basic operators, and the parameter information is used to determine the parameters of the at least two basic operators invoked by the target hardware platform. If it is determined that the custom operator includes a target operator that does not belong to the operator library, a prompt message is issued; wherein the prompt message is used to instruct the user to modify the target operator; The operator development framework includes a pre-configured basic operator call interface library, which includes call interfaces for basic operators common to the multiple hardware platforms. Obtaining the source code of the custom operator includes: obtaining the source code of the custom operator generated based on the operator call interface library, the source code including call interfaces for at least two basic operators. Parsing the source code to obtain the topology file of the custom operator includes: parsing the source code to obtain the topological relationship between the call interfaces of the at least two basic operators. The call interfaces of the at least two basic operators are used by the target hardware platform to call the at least two basic operators from the operator library when executing the custom operator. The source code also includes a platform identifier for the target hardware platform; the topology file also includes the platform identifier to instruct the target hardware platform to obtain the topology file before running the custom operator.

8. A computer device, characterized in that, include: processor; The processor is connected to a memory for storing computer execution instructions, and the processor executes the computer execution instructions stored in the memory to enable the computer device to implement the method as described in any one of claims 1-5.

9. A computer-readable storage medium, characterized in that, Used to store computer instructions that, when executed on a computer device, cause the computer device to perform the method as described in any one of claims 1-5.

Images