Method for optimizing design parameters of multi-core particle system, computing equipment and storage medium

Abstract

The embodiment of the invention provides a method for optimizing design parameters of a multi-core-particle system, computing equipment and a non-transitory machine readable storage medium. The method comprises the steps of obtaining a task graph corresponding to a target application, wherein a single task is executed through a single core in a core grain; the design parameters of the multi-core particle system are optimized through multiple rounds of iteration operation, and any ith round of iteration operation comprises the steps that current hardware design variables of the multi-core particle system are fixed, and the mapping relation from all tasks in the task graph to all cores in the multi-core particle system is updated with the purpose of optimizing the operation performance of the target application; and on the basis of the updated mapping relationship, by taking optimization of the operation performance as a target, updating a hardware design variable of the multi-core-particle system.

Description

Technical Field

[0001] One or more embodiments of this specification relate to designing a multi-chip system for executing a target application, and more particularly, to optimizing design parameters of the multi-chip system. Background Art

[0002] With the promulgation of a series of regulations and policies regarding data security, the importance of data security has been elevated to a higher level. Cryptographic technologies, such as homomorphic encryption, are at the core of ensuring data security. They allow business calculations to be performed without exchanging plaintext data (secret computing), helping to manage "data silos" and break down data barriers. For example, a user can encrypt medical images or account information containing private information and transmit them to a server. The server returns the results after secret computing, and the user can obtain the required information by decrypting it, effectively protecting the user's data privacy. For example, fully homomorphic encryption (FHE) provides a promising solution for privacy-preserving machine learning, enabling computation and analysis on encrypted data.

[0003] However, homomorphic encryption causes serious ciphertext expansion and involves a large number of polynomial modular addition and modular multiplication operations. To ensure security, the number of polynomial terms is usually set to 2. 15 or 2 16 , the coefficients are 1200 to 2500 bits, which leads to a sharp increase in the amount of computation and data access, and the ciphertext expansion rate is as high as one million times. Compared with plaintext calculations, the computational and memory communication overhead of FHE applications is also significantly increased. For example, encrypting a 4B integer into the homomorphic domain will increase its size to more than 20KB. When running the CKKS homomorphic encryption algorithm in the HEAAN library, the encrypted multiplication time is 27721 times that of the non-encrypted multiplication time; the amount of homomorphic encrypted input data required for the conv0 convolution layer of CryptoNets is 10 times that of the non-encrypted state. 3 On CPUs, homomorphic encryption applications run 10,000× to 100,000× slower than their unencrypted counterparts, and data access requirements can reach hundreds of MB to hundreds of GB. Therefore, there is an urgent need to research how to optimize homomorphic encryption algorithms and their overall performance on domain-specific many-core processor chips to enhance the feasibility of homomorphic encryption in future applications.

[0004] Research is currently underway in this area, with a particular focus on homomorphic encryption hardware acceleration chips. Existing studies have proposed various solutions for accelerating FHE on general-purpose computing platforms (such as GPUs and CPUs) and specialized computing platforms (such as FPGAs and ASICs). However, homomorphic encryption hardware and software acceleration efforts based on FPGAs, ASICs, and GPUs primarily focus on optimizing specific operations or circuits within the homomorphic encryption algorithm, without considering the numerous circuit-system-algorithm parameters of homomorphic encryption applications and domain-specific many-core processor chips. This has limited exploration of the optimization space for hardware and software acceleration. This is due to the significant increase in the complexity of the optimization problem caused by the numerous circuit-system-algorithm parameters, and the unclear mechanisms by which these parameters affect performance.

[0005] Therefore, improved solutions are desired to optimize the design of hardware for running applications such as FHE applications. Summary of the Invention

[0006] According to a first aspect, a method for optimizing design parameters of a multi-core system is provided, comprising: obtaining a task graph corresponding to a target application, wherein a single task is executed by a single core in a core; optimizing the design parameters of the multi-core system through multiple rounds of iterative operations, wherein any i-th round of iterative operations comprises: fixing the current hardware design variables of the multi-core system, updating the mapping relationship between each task in the task graph and each core in the multi-core system with the goal of optimizing the operating performance of the target application; and updating the hardware design variables of the multi-core system based on the updated mapping relationship with the goal of optimizing the operating performance.

[0007] In one embodiment, the target application is an encrypted neural network based on fully homomorphic encryption (FHE), and the single task is a basic operator in the FHE operation.

[0008] In one embodiment, the operation performance depends on the communication volume and the communication path; updating the mapping relationship between each task in the task graph and each core in the multi-core particle includes: with the goal of optimizing the communication volume, under the constraints related to the hardware design variables, dividing the task graph into multiple subgraphs; Figure 1 The system maps the plurality of core particles in the multi-core particle system to each other, and with the goal of optimizing the communication path, maps the tasks in each subgraph to the cores in the corresponding core particles one by one.

[0009] In one embodiment, the hardware design variables include the number of cores in the cores and the number of cores in the cores; dividing the task graph into multiple subgraphs includes: using a graph partitioning algorithm to minimize the amount of communication between cores, and dividing the task graph into multiple subgraphs under the constraints of the current number of cores in the multi-core system and the number of cores in each core.

[0010] In one embodiment, with the goal of optimizing the communication path, the tasks in each subgraph are mapped one by one to the cores in the corresponding coreparticles, including: based on the inter-coreparticle communication volume and / or intra-coreparticle communication volume of the tasks, according to the preset mapping rules related to the communication path, the tasks in each subgraph are mapped one by one to the cores in the corresponding coreparticles in turn.

[0011] In one embodiment, the mapping rules include mapping each task in sequence according to the priority rules, wherein the first type of tasks are mapped to the idle core closest to the inter-chip interconnection interface, and the second type of tasks are mapped to the idle core closest to the geometric center of the chip; wherein the first type of tasks are tasks whose inter-chip communication volume exceeds a first threshold, and the second type of tasks are tasks whose intra-chip communication volume exceeds a second threshold; the priority rules include at least one of the following: the priority of the first type of tasks is arranged from high to low according to the inter-chip communication volume, and the priority of the second type of tasks is arranged from high to low according to the intra-chip communication volume, and the priority of the first type of tasks is higher than the priority of the second type of tasks.

[0012] In one embodiment, the hardware design variables take values from a preset numerical set, and updating the hardware design variables of the multi-core system includes: using a branch and bound algorithm based on a search tree to determine the optimal solution of the hardware design variables that optimizes the operating performance under the current mapping relationship as the target value, and updating the hardware design variables to the target value, wherein the nodes of the search tree represent a set of partial or complete solutions of some or all of the hardware design variables that take values from the preset numerical set.

[0013] In one embodiment, the branch and bound algorithm includes: initializing the optimal value of the operating performance and the optimal solution of the hardware design variables, and pushing the root node of the search tree into a work queue; looping and executing the target operation until the work queue is cleared, and returning the optimal solution when cleared as the target value. The target operation includes: taking out the current node in the work queue, and when the current node is a leaf node and its corresponding operating performance value is better than the current optimal value, updating the optimal value to the operating performance value corresponding to the current node, and updating the optimal solution to a set of solutions represented by the current node; when the current node is a non-leaf node, branching and pruning the current node according to preset branching and pruning rules, and pushing the newly added nodes of the search tree after the branching and pruning process into the work queue.

[0014] In one embodiment, the hardware design variables include x attribute parameters of the core particle and y structural variables within and between core particles; the branching rules include: if the level of the current node in the search tree is less than x, the current node is branched by adding attribute parameters and their corresponding solutions; if the level is greater than or equal to x, the current node is branched by adding structural variables and their corresponding solutions.

[0015] In one embodiment, the attribute parameters include the number of cores in the core, the number of core-to-core interconnection interfaces in the core, and / or the memory size in the core, and the structural variables include interconnection variables between cores in the same core, interconnection variables between cores and core-to-core interconnection interfaces in the same core, and / or interconnection variables between core-to-core interconnection interfaces of different cores.

[0016] In one embodiment, the pruning rules include at least one of the following: when the node obtained by branching is a leaf node, pruning the node whose corresponding running performance value is not better than the current optimal value; when the node obtained by branching is a non-leaf node, estimating the running performance value corresponding to the node, and pruning the node whose estimated value is not better than the current optimal value; pruning the node that does not satisfy the current mapping relationship; and pruning the node obtained by branching when the current queue length of the work queue has reached the preset queue length.

[0017] In one embodiment, the running performance is the running time, and the running time is calculated as follows: determining the computation time of each task and the communication time of each edge in the task graph, determining the longest path in the task graph based on the computation time and the communication time, and calculating the total time on the longest path as the running time.

[0018] In one embodiment, the multiple rounds of iterative operations are all performed under at least one of the following constraints: the area of the multi-core system is not greater than a first preset value; the power consumption of the multi-core system is not greater than a second preset value; each core cannot be directly interconnected with the cores in other cores and the inter-core interconnection interface; different inter-core interconnection interfaces in the same core cannot be directly interconnected; and the tasks correspond one-to-one to the cores.

[0019] According to a second aspect, a computing device is provided, comprising: a processor; and a memory on which executable code is stored, wherein when the executable code is executed by the processor, the processor executes the method of any one of the embodiments of the first aspect.

[0020] According to a third aspect, a non-transitory machine-readable storage medium is provided, on which executable code is stored. When the executable code is executed by a processor of an electronic device, the processor is caused to execute the method of any embodiment of the first aspect.

[0021] In the embodiments of this specification, a scheme is proposed for optimizing the design parameters of a multi-core system, wherein the multi-core system is designed to execute a target application. The scheme adopts a two-layer optimization algorithm to decompose the design optimization problem into two sub-problems: (1) mapping each task in the target application to each core in the multi-core system, and (2) selecting the hardware design parameters of the multi-core system, and iteratively solving these sub-problems, thereby making it possible to use modular cores to simplify the design of the system, effectively solve the optimization problem, and effectively improve the operating performance of the multi-core system for the target application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0023] Figure 1 An exemplary flow chart illustrating a method of optimizing design parameters of a multi-chip system according to some embodiments;

[0024] Figure 2 A schematic diagram showing a task graph corresponding to an exemplary FHE operator and the mapping relationship between each task in the graph and each core in a multi-core system;

[0025] Figure 3 A schematic diagram illustrating an inter-chiplet interconnection network topology structure and an intra-chiplet interconnection network topology structure in modeling a multi-chiplet system according to some embodiments;

[0026] Figure 4 A schematic diagram illustrating runtime calculation of a target application according to some embodiments;

[0027] Figure 5 A schematic diagram illustrating calculation of the shortest path within a core particle in a communication time model according to some embodiments;

[0028] Figure 6 A schematic diagram illustrating construction of an upper portion of a search tree according to some embodiments;

[0029] Figure 7 A schematic diagram illustrating construction of a lower portion of a search tree according to some embodiments;

[0030] Figure 8A schematic diagram illustrating three pruning rules according to some embodiments;

[0031] Figure 9 A schematic diagram illustrating an exemplary structure of a computing device according to some embodiments is shown. DETAILED DESCRIPTION

[0032] The solution provided in this specification is described below in conjunction with the accompanying drawings.

[0033] First, the terminology is explained as follows:

[0034] Fully homomorphic encryption involves homomorphic operations (hereinafter referred to as FHE operations): the result of a homomorphic operation is the same as the result of the same operation on the original plaintext after decryption. Homomorphic operations include: homomorphic addition (HAdd), homomorphic multiplication (HMult), modular conversion (BConv), rescaling (Rescale), modular up (ModUp), modular down (ModDown), key switching (Keyswitch), ciphertext rotation (Rotation), ciphertext conjugation (Conjugate) and bootstrapping, etc.

[0035] Number theoretic transformation (NTT): NTT converts polynomial convolution operations into point-valued form, reducing computational complexity from N² to N·logN, significantly improving computational efficiency and effectively reducing memory requirements. The inverse NTT is called inverse NTT (iNTT).

[0036] Chiplets: They can be designed modularly, have specific functions, and can be combined and integrated into a multi-chiplet system through interconnection technology.

[0037] Number of Chiplets: This refers to the number of chiplets in a system. Increasing the number of chiplets can improve the system's computing power and parallelism, but it also increases power consumption and cost.

[0038] Inter-chiplet interconnect: This refers to the physical connection between different chiplets, such as on-chip interconnect and PCB interconnect. The design of the inter-chiplet interconnect has a significant impact on the system's communication bandwidth, latency, and power consumption.

[0039] Intra-chiplet interconnect: This refers to the physical connections between different functional units within a chiplet, such as on-chip buses and on-chip networks. The design of intra-chiplet interconnects directly affects the efficiency and latency of data transmission within the chiplet.

[0040] Inter-chiplet interconnection interface: used to provide a data transmission interface between different chiplets in the same package.

[0041] Power consumption of a multi-chip system refers to the total power consumed by all components in the system under normal working conditions.

[0042] As mentioned earlier, current research on accelerating FHE applications primarily focuses on optimizing and accelerating individual operations or circuits, while optimizing the overall system is extremely difficult. This is because the scientific problem of collaborative hardware and software acceleration for FHE applications can be formulated as: given an FHE application, optimize system performance within constraints such as chip area and power consumption. The decision variables include numerous circuit-system-algorithm parameters (such as matrix partitioning, SIMD packing, modular decomposition, on-chip interconnect topology, and on-chip memory capacity). This problem is difficult due to the large number of decision variables, extremely high dimensionality, and extremely complex optimization problems, resulting in an extremely large design space.

[0043] To this end, this disclosure proposes the use of multi-chip integration technology to accelerate FHE applications. By integrating multiple modular cores within a single package, heterogeneous chips with specialized functions can be constructed, enabling high-performance chip design. In a multi-chip integrated system, each core can process different computing tasks in parallel, significantly improving computing efficiency. In addition, in some cases, proven cores can be reused, allowing designers to reduce risk, shorten time to market, and quickly launch new products with optimized system performance.

[0044] While applying FHE algorithms to multi-chip integrated systems can fully exploit their parallel computing capabilities, setting hardware and software parameters, such as the interconnection network between chips and the mapping of tasks to the multi-chip system, is a complex issue. Furthermore, this disclosure has found that different hardware and software parameters significantly impact FHE application performance in multi-chip systems.

[0045] Therefore, the present disclosure proposes a two-level optimization algorithm, which utilizes the task graph of the target application to be run by the multi-core system to decompose the optimization problem of the design parameters of the multi-core system into two sub-problems: (1) mapping each task in the target application to each core in the multi-core system, and (2) selecting the hardware design parameters of the multi-core system, and iteratively solves these sub-problems, thereby reducing the complexity of the design, effectively solving the optimization problem, and thus effectively improving the running performance of the multi-core system for the target application.

[0046] Optimization can be performed through multiple rounds of iteration. In each round, the two subproblems mentioned above are solved sequentially. While the variables of the other subproblems are fixed at constants, the decision variables of each subproblem are adjusted to the optimal value to solve the current subproblem. This allows the original complex optimization problem to be decomposed into two relatively simple subproblems that are completely decoupled, and appropriate solutions can be applied to each subproblem.

[0047] Figure 1 An exemplary flow chart illustrating a method of optimizing design parameters of a multi-chip system according to some embodiments.

[0048] The multi-core system is specifically designed for the operation of the target application and is designed to include multiple cores, each of which includes multiple cores and an inter-core interconnection interface for interconnecting with other cores. There is also an interconnection topology within and between cores to facilitate data communication. Therefore, the design parameters of the multi-core system can include the aforementioned hardware-related hardware design variables, such as core attribute parameters (such as the number of cores, the number of cores in each core), as well as structural variables within and between cores (such as interconnect relationships).

[0049] The core in the present disclosure refers to the processor core in the chiplet, which is generally an independent computing unit embedded in a single chiplet, and its function is similar to that of a traditional processor core. In the multi-core design of the chiplet, each processor core can execute tasks independently, and multiple cores work together to improve the overall computing performance. Therefore, the operation of the entire target application can be decomposed into multiple tasks, where each task is executed by a core in the multi-chiplet system, and the mapping relationship between tasks and cores will greatly affect the operating performance of the target application. Therefore, the design parameters of the multi-chiplet system can also include the mapping relationship between each task and each core in the multi-chiplet system. For the convenience of design, the embodiment of the present disclosure adopts a task graph to solve the mapping relationship.

[0050] like Figure 1 As shown, in the method for optimizing design parameters of a multi-chiplet system according to an embodiment of the present disclosure, in step S110 , a task graph corresponding to a target application is obtained, wherein a single task is executed by a single core in a chiplet.

[0051] For example, the target application could be an FHE-based encrypted neural network, where a single task is a basic operator in the FHE operation. The entire encrypted neural network operation can be decomposed into a series of FHE operations, such as homomorphic addition, homomorphic multiplication, rescaling, key conversion, and bootstrapping. Each FHE operation can be decomposed into a series of basic operators, such as NTT, iNTT, MM (Modular Multiplication), and MA (Modular Addition). Therefore, the task graph corresponding to the encrypted neural network can be composed of a series of basic operators in FHE operations.

[0052] Since a single task in the task graph is to be executed by a single core in a chiplet, in some examples, the tasks can be divided according to the design computing power of the core in a multi-chiplet system so that the computational amount of each task matches the design computing power of the core.

[0053] It should be understood that although the following embodiments or examples are described using FHE-based encrypted neural networks as examples of target applications, the solutions disclosed herein are not limited thereto, but can be similarly applied to other target applications with similar design requirements, such as other FHE-based applications.

[0054] Figure 2 An example of a task graph and its mapping to the core is given below. For the sake of clarity and simplicity, Figure 2 Only one exemplary FHE operator in the target application is given, namely the Keyswitch operator in the CKKS scheme, and the corresponding task graph is used as an illustration. It should be understood that the task graph of the actual target application will consist of multiple Figure 2 The same or similar FHE operator task graphs are connected according to the computation process of the target application.

[0055] Figure 2 The far right side of the task graph shows the meaning of the tasks (i.e., basic operators) represented by the diagrams of each node. The basic operator SBT represents the second step of the modular reduction operation (as shown in Algorithm 5 below), which includes a modular reduction operation and a modular multiplication (multiplication by the inverse element).

[0056]

[0057] exist Figure 2 In FIG, a schematic diagram of a multi-core particle system is shown below the task diagram, which exemplarily includes 16 core particles in 4 rows and 4 columns, wherein each core particle includes 4 cores in 2 rows and 2 columns. Figure 2As illustrated by the dotted arrow in , each task in the task graph can be mapped to a core, which is responsible for executing the corresponding task.

[0058] The task graph can be represented as G(V,A), where node v i ∈V represents the i-th task, edge a i,j ∈A represents the distance (e.g., communication time) between the i-th task and the j-th task. In addition, u i,j ∈U represents the i-th core in the j-th core in the multi-core system. The mapping relationship between the task graph and the multi-core system is expressed as That is, m i,j,k =1 means task v i Mapping to core u j,k , a value of 0 means there is no mapping between the two.

[0059] For example, tasks v1, v2, v3, and v4 can be mapped to the four cores u in the first core particle respectively. 1,1 、u 3,1 、u 2,1 and u 4,1 . That is m 1,1,1 =m 2,3,1 =m 3,2,1 =m 4,4,1 = 1. For the sake of simplicity, the mapping relationship between other tasks and cores in the task graph is not shown in Figure 2 Shown in.

[0060] Back to Figure 1 In step S120 after step S110, the design parameters of the multi-core system are optimized through multiple rounds (N rounds, N>1) of iterative operations, wherein any i-th round of iterative operations includes:

[0061] Step S121 , fixing the current hardware design variables of the multi-core system, and updating the mapping relationship between each task in the task graph and each core in the multi-core system with the goal of optimizing the running performance of the target application;

[0062] Step S122 : Based on the updated mapping relationship, the hardware design variables of the multi-chip system are updated with the goal of optimizing the operating performance.

[0063] In some examples, the number of rounds N of the iterative operation may be determined by a preset iterative convergence condition. For example, the iterative convergence condition may be that the running performance σ converges or the number of iterations reaches a predetermined upper limit, as shown in the following formula:

[0064] σ i -σ i-1 ≤δor i≤n max

[0065] Among them, i represents the current iteration number, σ i represents the optimal value of the running performance obtained by the current round of iterative operation, σ i-1 represents the optimal value of the running performance obtained by the previous round of iterative operation, δ represents the preset convergence value, and n max is a predetermined upper limit value.

[0066] Let us first discuss some specific examples of step S121.

[0067] Step S121 optimizes or finds the optimal value for the mapping between each task in the task graph and each core in the multi-core system, with the goal of optimizing the target application's performance. The multi-core system's other design parameters, namely the hardware design variables, are fixed to their current values, remaining unchanged throughout step S121. In the first iteration, the hardware design variables may be set to initial values, which are a set of values determined empirically or by other known methods. In subsequent iterations, the current values of the hardware design variables are the values optimized in the previous iteration.

[0068] In some examples, the operating performance of the target application, such as the running time, depends on the communication volume and the communication path. The communication volume, especially the communication volume between core particles, has a greater impact on the operating performance, especially the running time. The communication volume and communication path here refer to the communication volume and communication path required by the core to which each task is mapped when executing each task, which are greatly affected by the mapping relationship between the task and the core. Therefore, step S121 can simplify the goal of optimizing the operating performance of the target application to the goal of optimizing the communication volume and communication path, and it can be relatively easy to solve the mapping relationship with the goal of optimizing the communication volume and communication path using graph-related algorithms.

[0069] In some examples, the mapping relationship can be solved in two steps: first, each task is assigned to a core particle with the goal of optimizing communication volume, and then each task is assigned to a core in the corresponding core particle with the goal of optimizing communication path. For example, step S121 may include: with the goal of optimizing communication volume, under the constraints related to hardware design variables, dividing the task graph into multiple subgraphs; Figure 1 One is mapped to multiple core particles in a multi-core particle system, and with the goal of optimizing the communication path, the tasks in each subgraph are mapped one by one to the cores in the corresponding core particles.

[0070] The aforementioned hardware design variables can include the number of cores and the number of cores within a core. A graph partitioning algorithm, such as the recursive Fiducia-Mattheyses algorithm, can be employed to minimize inter-core communication, partitioning the task graph into multiple subgraphs within the constraints of the current number of cores in the multi-core system and the number of cores within each core. Because each subgraph maps to a core, inter-core communication corresponds to inter-subgraph communication. Furthermore, the total number of subgraphs cannot exceed the number of cores, and the number of tasks in a subgraph cannot exceed the number of cores within a core. In a one-to-one correspondence between tasks and cores, the total number of subgraphs should equal the number of cores, and the number of tasks in a subgraph should equal the number of cores within a core.

[0071] In addition, in some examples, based on the inter-core particle communication volume and / or intra-core particle communication volume of the tasks, the tasks in each subgraph can be mapped one by one to the cores in the corresponding core particles according to preset mapping rules related to the communication path.

[0072] For example, tasks within each core can be divided into two categories based on intra-core and inter-core communication volume, and then mapped sequentially according to their priority. Tasks with high intra-core communication volume can be mapped to a core close to the core's geometric center, thereby reducing the communication distance with other tasks within the core. Tasks with high inter-core communication volume can be mapped to the core closest to the inter-core interconnect interface, thereby reducing the communication distance with tasks in other cores. Typically, tasks with high inter-core communication volume do not overlap with tasks with high intra-core communication volume. Because inter-core communication has a greater impact on communication time than intra-core communication, priority can be calculated based on inter-core communication volume first, followed by intra-core communication volume. That is, tasks with high inter-core communication volume are prioritized and allocated in descending order, followed by tasks with high intra-core communication volume, also in descending order. Other tasks with low communication volume can be prioritized and allocated according to other pre-set rules.

[0073] For example, the above-mentioned mapping rules related to communication paths may include mapping each task in sequence according to a priority rule, wherein the first type of task is mapped to the idle core closest to the inter-chip interconnection interface, and the second type of task is mapped to the idle core closest to the geometric center of the chip; wherein the first type of task is a task whose inter-chip communication volume exceeds a first threshold, and the second type of task is a task whose intra-chip communication volume exceeds a second threshold. The so-called "idle" core refers to a core that has not yet been assigned (mapped) a task. When there are multiple interconnection interfaces within a chip, the idle core closest to one of the interconnection interfaces can be randomly selected.

[0074] The above-mentioned priority rules may include at least one of the following: the priority of the first category of tasks is arranged from high to low according to the communication volume between core particles, and the priority of the second category of tasks is arranged from high to low according to the communication volume within the core particle, and the priority of the first category of tasks is higher than the priority of the second category of tasks.

[0075] Next, some specific examples of the above-mentioned step S122 are discussed.

[0076] Step S122 optimizes or finds optimal values for the hardware design variables of the multi-chip system, with the goal of optimizing the performance of the target application. The other design parameters of the multi-chip system, namely the aforementioned mapping relationships, are fixed to the values determined in step S121 and remain unchanged throughout step S122. In each iteration, the mapping relationships are first updated in step S121, and then, in step S122, the hardware design variables are optimized while maintaining the fixed mapping relationships.

[0077] This paper has found that using different hardware parameter values can significantly impact the performance of target applications, particularly runtime. For example, for a ResNet-20 application based on FHE, using a torus topology on-chip can reduce runtime by 20.3% compared to a mesh topology. Furthermore, changes in cache size can result in a 27.5% performance difference.

[0078] Moreover, the present disclosure also found that the interconnection topology structures between various core particles that have been proposed so far still have room for optimization for the multi-core particle system of the present disclosure, because they may not match the traffic and may cause long delays. For example, if a Mesh structure is used between core particles, the hardware cost and wiring cost are high, the circuit design is more difficult, and it may cause routing congestion problems. If a Butterfly structure is used between core particles, there will be complex routing management, which may cause routing congestion problems, increase the cost and complexity in hardware design and implementation, and reduce resource utilization and increase communication delays. If a Ring structure is used between core particles, the bandwidth of the ring structure may become a bottleneck, there will be problems of delay accumulation, single point failure risk and load imbalance problems, thereby affecting the overall performance. Therefore, as will be described later, in some embodiments of the present disclosure, the optimal interconnection topology structure for the current multi-core particle system can be found by traversal search.

[0079] Some specific embodiments will be described below using the running time as an example of the running performance, but it should be understood that the present disclosure is not limited thereto.

[0080] In some examples, the optimization problem of step S122 may be modeled, and the optimization model may be solved to optimize the hardware design variables.

[0081] The objective function in this optimization model is to minimize the runtime of the multi-chip system for the target application, i.e., minσ(x), where the decision variable x represents the hardware design variables of the multi-chip system. In some cases, constraints can also be set, such as the total area and / or total power consumption of the multi-chip system. This allows the target application's execution time to be minimized within the constraints of chip area and power consumption, thereby improving resource utilization efficiency.

[0082] First, a hardware design variable model for a multi-chiplet system is constructed to determine the number of corelets in the system, their attribute parameters, and the structural variables within and between corelets. For example, attribute parameters can include the number of cores in a corelet, the number of inter-corelet interconnect interfaces within a corelet, and the memory size within the corelet. Structural variables can include variables related to the topology of the inter-corelet interconnect network and the topology of the intra-corelet interconnect network, such as the interconnection variables between cores in the same corelet, the interconnection variables between cores and inter-corelet interconnect interfaces within the same corelet, and the interconnection variables between inter-core interconnect interfaces of different corelets.

[0083] Figure 3 Schematic diagram illustrating inter-chiplet interconnection network topology and intra-chiplet interconnection network topology in modeling a multi-chiplet system according to some embodiments.

[0084] Specifically, c represents the number of cores in the multi-core system, R1,...,R c ,R j ∈U(j=1,...,c) represents the core set in the jth core particle, |R j | represents the number of cores in the jth core particle, u i,j ∈U represents the i-th core in the j-th core particle, and the edge e i,k,j ∈E represents the connection core u within the j-th core particle i,j and u k,j Links between (interconnected variables), represents the core particle interconnection interface within the jth core particle, where d j Indicates the number of core-to-core interconnection interfaces (e.g., D2D interfaces (Die to Die interfaces)) within the j-th core. i,j Interconnection interface between core particles The links (interconnected variables) between Inter-core interconnection interface within the j-th core Inter-core interconnection interface with the p-th core The links (interconnected variables) between In addition, use b j Indicates the memory size of the j-th core particle.

[0085] like Figure 3 As shown, the values of the interconnection variables e and α between cores in the same core particle, the interconnection variables between the core and the interconnection interface between core particles in the same core particle, and the interconnection variables e and α between the interconnection interfaces between core particles of different core particles are 1, indicating that there is a link between the corresponding two components (i.e., the two are interconnected), and 0 indicates that there is no connection.

[0086] Then, when the mapping relationship between the task graph and the multi-core system is determined and remains unchanged in step S121 as described above, the running time of the entire target application can be calculated based on the task graph.

[0087] For example, the computation time of each task and the communication time of each edge in the task graph can be determined; based on the computation time and communication time, the longest path in the task graph can be determined; and the total time on the longest path can be calculated as the running time.

[0088] Figure 4 An example of calculating the runtime of a target application based on a task graph is given.

[0089] Figure 4 An exemplary task graph G(V,A) is shown in FIG, where the task v of each node can be determined based on the mapping relationship between each task and the core. i ∈V is the computation time ω(v i ).

[0090] In addition, in some examples, each edge a in the task graph can be determined based on the communication time model established as follows: i,j ∈A’s communication time T(a i,j ).

[0091] Communication time T(a i,j ) is from the source node v i To the destination node v j The communication time includes the zero-load delay time and the queuing delay time.

[0092] 1. Zero load delay time:

[0093] Zero load delay time t zero (v i ,v j ) refers to the communication time of all packets from the source node to the destination node, which can be divided into the time when the first packet arrives (related to bandwidth and shortest path) and t head (v i ,v j ) and serialized data transmission time (related to bandwidth, data size or number of packets) t serialization (a i,j ), that is, tzero (v i ,v j )=t head (v i ,v j )+t serialization (a i,j ), where t head (v i ,v j ) indicates that from task v i To task v j The arrival time of the first packet, t serialization (a i,j 0 means from task v i To task v j The amount of communication on the edge a i,j Serialization time.

[0094] 1.1. Arrival time of the first packet:

[0095] Header packet arrival time t head (v i ,v j ) can be expressed by the following formula:

[0096] t head (v i ,v j )=k*L(a i,j )

[0097] Among them, k represents the number of routing pipeline stages, L(a i,j ) represents task v i to v j communication distance.

[0098] If the task v i and task v j are mapped to the two cores in the same core particle, then define L(a i,j ) is to execute task v i and v j The communication distance between cores.

[0099] If the task v i and task v j are mapped to different core particles, such as task v i Mapping to core u m,p , task v j Mapping to core u n,q , then task v i to v j Communication distance L(a i,j ) is the core u m,p To core u n,q The shortest path lm,p,n,q Consider the shortest path for the first packet to arrive as follows:

[0100]

[0101] in, Represents the source node u m,p The shortest path to the corep interconnection interface in corep, represents the shortest path from core particle p to core particle q, Represents the interconnection interface between core particles in core particle q and the destination node u n,q The shortest path.

[0102] In the process of obtaining the three shortest paths mentioned above, the shortest path algorithm, for example, Bellman's shortest path algorithm, may be used to solve the shortest path and calculate the shortest path length. Figure 5 An exemplary schematic diagram of the calculation of the shortest path within the core particle is given. Figure 5 As shown in the dotted box in , if the shortest path length from v1 to v2 has been obtained, and v2 to the next node is the shortest path in the current greedy thinking, then the shortest path can be obtained by using the greedy thinking to select the smallest value. It should be noted that Figure 5 The solid arrows in FIG. 1 represent the time at which the first packet arrives, and the dotted lines represent nodes that are omitted and not shown in the figure.

[0103] 1.2, Serialization time:

[0104] The serialization time is related to the specific bandwidth and packet length, and can be modeled according to various known methods, which will not be described in detail here.

[0105] 2. Queuing delay time:

[0106] Queue delay time where x i,j Indicates that on the shortest path π p,q,m,n On the router, Indicates router x i,j The queuing delay time from input port α to output port β. According to the proposed delay model based on priority arbitration, considering multiple input channels Competing for the same output channel The data packet is at router x of chip j i,j Average waiting delay in It can be approximately expressed as follows:

[0107]

[0108] in Output channel OC β The proportion of time occupied by data packets, and Respectively represent input channels To output channel Packet arrival rate and output port The average service rate, and It is the correlation coefficient between the corresponding data packet arrival rate and service rate obtained according to the known approximate formula.

[0109] In summary, the comprehensive inter-task communication time is as follows:

[0110] T(v i ,v j )=T(a i,j )=k*L(a i,j )+t serialization (a i,j )+F(a i,j ),

[0111] The first part is the arrival time of the first packet, the second part is the serialization time, and the third part is the queuing delay time.

[0112] Back to Figure 4 As an example, in the task graph, the computation time ω(v i ) and the communication time T(a i,j ), the longest path in the task graph G(V,A) (i.e., the path with the longest time) can be solved to represent the running time of the target application, and the longest path of the last task in the task graph represents the longest path of G(V,A), that is, the running time σ of the application.

[0113] exist Figure 4 In the figure, solid arrows represent the length of each side or path (representing the communication time), and dashed lines represent omitted nodes in the line. The dashed box illustrates that the next node with the longest side length (path) of node v2 is selected, thereby obtaining the longest path represented by the red line. It should be understood that although Figure 4 and Figure 5 The task graph in is very similar, but it does not mean that the same task graph is operated on. It is only used as an example of a graph to show it.

[0114] The longest path calculation formula for each task in the task graph is as follows:

[0115]

[0116] Among them, d(v j ) means v i Previous mission v j The longest path, T(a j,i ) represents task vj to v i communication time.

[0117] The above formula can be transformed into the following formula through the smoothing function:

[0118]

[0119] Various algorithms can be used to find the longest path in the task graph. After obtaining the longest path, the running time of the entire application can be calculated using the following formula:

[0120]

[0121] Among them, Π(v0,v m ) is the set of nodes on the longest path. The longest path includes m+1 nodes with sequential numbers, v0 and v m are the first and last nodes of the longest path respectively. It should be understood that the node subscripts here are renumbered according to the order of the nodes on the longest path, which is consistent with Figure 4 The node subscripts in are not necessarily the same.

[0122] In addition, the area and power consumption model of the multi-chip system can be established to evaluate the resource consumption and energy consumption of the system. For example, define A(u i,j )(The value range of i is 1~|R j |) is the area of each core in the j-th core particle, A(u i,j 0(i's value range is |R j |+1~|R j |+d j ) is the area of the interconnection interface between each core particle in the jth core particle, P(u i,j )(The value range of i is 1~|R j |) is the power of each core in the jth core particle, P(u i,j )(The value range of i is |R j |+1~|R j |+d j ) is the power of the interconnection interface between each core particle in the jth core particle, which can be obtained as follows:

[0123] The area of each core particle

[0124] Power consumption of each chip

[0125] Therefore, the total area of the multi-core system is The total power consumption of the multi-chip system is

[0126] In summary, based on the above modeling, we can obtain the following optimization model to minimize the runtime of the target application under the constraints of area and power. Mathematically, the optimization objective function is defined as follows:

[0127]

[0128] The constraints may include at least one of the following five points:

[0129] 1) The area of the multi-core system is not greater than the first preset value A0:

[0130]

[0131] 2) The power consumption of the multi-chip system is not greater than the second preset value P0:

[0132]

[0133] 3) Each core cannot be directly interconnected with the cores in other cores and the inter-core interconnection interface:

[0134] α i,j,p,q =0,if j≠q and(0 <i≤|R j |or 0 <p≤|R q |)

[0135] 4) Interconnection interfaces between different cores in the same core cannot be directly interconnected:

[0136] α i,j,p,q =0,if j=q and|R j |+1≤i≤|R j |+d j and|R q |+1≤p≤|R q |+d q

[0137] 5) One-to-one correspondence between tasks and cores:

[0138]

[0139] The decision variables of the optimization model are hardware design variables. In some examples, to simplify the design, the hardware design variables can all be assigned values from a preset set of values. Therefore, the hardware design variables can be solved as follows: a branch-and-bound algorithm based on a search tree is used to determine the optimal solution for the hardware design variables that optimizes operating performance under the current mapping relationship as the target value, and the hardware design variables are updated to the target value. The nodes of the search tree represent a set of partial or complete solutions for some or all of the hardware design variables that take values from the preset set of values.

[0140] For example, a search tree can be created to represent the search process, and a branch-and-bound algorithm with a pruning strategy can be executed to accelerate the search process and obtain the optimal solution. Each node of the search tree represents a partial or complete generated topology.

[0141] In some examples, the branch and bound algorithm works as follows:

[0142] 1) Initialization: Initialize the optimal value of the operating performance and the optimal solution of the hardware design variables, and push the root node of the search tree into the work queue.

[0143] For example, initialize the current optimal objective function value σ * is ∞, the optimal solution g * Empty set g * Used to record the optimal solution found in the search tree so far, and push the root node (set to an empty set) into the work queue.

[0144] 2) Search process: Loop the target operation until the work queue is cleared, and the target operation includes: taking out the current node in the work queue, and when the current node is a leaf node and its corresponding running performance value is better than the current optimal value, updating the optimal value to the running performance value corresponding to the current node, and updating the optimal solution to a set of solutions represented by the current node; when the current node is a non-leaf node, branching and pruning the current node according to the preset branching and pruning rules, and pushing the nodes of the search tree newly added after branching and pruning into the work queue.

[0145] For example, the search process can be viewed as a multi-round iterative branching process. In each round of iterative branching, the work queue is checked to see if it is empty. If the work queue is not empty, the current node in the queue is removed. If the current node If it is not a leaf node, branch and prune according to the branching and pruning rules. After branching and pruning, add the newly added node to the work queue; if it is a leaf node, confirm its corresponding objective function value. Is it better than the current optimal objective function value σ * , if it is better than * Updated to The current optimal solution g * Update to the current node If the solution is not better than the set of solutions represented by abandon.

[0146] When hardware design variables include core particle attribute parameters and structural variables within and between core particles, the attribute parameters can be searched first, followed by the structural variables. This means that when branching the current node, the attribute parameters are considered first, and the structural variables are considered after all attribute parameters have been branched. Each branching operation forms a layer of nodes in the search tree. The resulting search tree adds a solution for each attribute parameter in each upper layer and a solution for each structural variable in each lower layer.

[0147] For example, when the hardware design variables include x attribute parameters of the core particles (referring to the total number of attribute parameters of all core particles being x), and y structural variables within and between core particles (referring to the total number of structural variables within and between core particles being y), the above-mentioned branching rules may include: if the level of the current node in the search tree is less than x, branch the current node by adding attribute parameters and their corresponding solutions; if the level is greater than or equal to x, branch the current node by adding structural variables and their corresponding solutions. The attribute parameters may include the number of cores in the core particle, the number of core-to-core interconnection interfaces in the core particle, and / or the memory size in the core particle, and the structural variables may include interconnection variables between cores in the core particle, interconnection variables between cores in the core particle and core-to-core interconnection interfaces, and / or interconnection variables between core-to-core interconnection interfaces of different core particles.

[0148] In some examples, the above-mentioned pruning rules may include at least one of the following: when the node obtained by branching is a leaf node, pruning the node whose corresponding running performance value is not better than the current optimal value; when the node obtained by branching is a non-leaf node, estimating the running performance value corresponding to the node, and pruning the node whose estimated value is not better than the current optimal value; pruning the node that does not satisfy the current mapping relationship; and pruning the node obtained by branching when the current queue length of the work queue has reached the preset queue length.

[0149] The estimated value can be an upper or lower limit. For example, if the optimization goal is to minimize runtime, the estimated value can be a lower limit for the runtime of the partial solution represented by the node. If the lower limit is not better than the current optimal value, then any branches below the node cannot be further optimized. Therefore, the node is pruned to speed up the search process.

[0150] In addition, when solving under the aforementioned constraints, the pruning rules may further include pruning nodes that do not satisfy the constraints. In addition, in some examples, the pruning rules may further include pruning nodes that do not satisfy other feasibility requirements, where the feasibility requirements may be preset based on, for example, design logic.

[0151] 3) Termination: Whenever the work queue is empty, the search process is terminated and the optimal solution at the time of emptying is returned as the target value.

[0152] The following combination Figures 6 to 8 To describe some specific examples of the above branch and bound algorithm.

[0153] Figure 6 and Figure 7 Together they show a schematic diagram of an example of building a search tree, where Figure 6 is the upper part of the search tree, Figure 7 To continue Figure 6 The lower part of the search tree.

[0154] The search tree generates a layer of nodes based on each decision variable, where the decision variables, i.e., hardware design variables, include the number of cores in each core, the number and memory size of the core-to-core interconnect interfaces, the interconnection variables between cores in the same core, the interconnection variables between cores in the same core and the core-to-core interconnect interfaces, and the interconnection variables between core-to-core interconnect interfaces of different cores.

[0155] Can be used Represents the nth tree node at level l in the search tree. Each tree node is defined as: where |R1|,...,|R c | respectively represent the core numbers of core particles 1 to c; d1,...,d c Respectively represent the number of interconnection interfaces between core particles 1 to c; b1,...,b c Represents the memory size of core particles 1 to c respectively; They represent the interconnection variables between cores and cores within the same core particle and between cores and core particles respectively; These represent the interconnection variables between the coreparticle interconnection interfaces of different coreparticles. That is, each tree node represents a combination of some or all of these decision variables (including all decision variables along the path from that tree node to the root node), where each decision variable takes a value from its preset set of values. Therefore, each tree node represents part or all of a set of solutions.

[0156] exist Figure 6 and Figure 7 In the example, the number of core particles in the system is set to c. In the branch rule, if Figure 6 As shown in , according to the value of the attribute parameters of each core particle (number of cores, number of interconnection interfaces between core particles, and memory size), a combination of decision variables can be constructed through branch operations from layer 0 to layer 3c-1; Figure 7As shown in Figure 1, based on the values of all the structural variables (interconnection variables) within and between core particles, a combination of decision variables can be constructed through branching operations in layer 3c and later. Layer 0 is the root node, which is an empty set.

[0157] Specifically, if Figure 6 As shown, the branch operation from layer 0 to layer c-1 is performed by core particle 1 to the number of cores in c | R i |Determine, set the number of cores in the core|R i | Take a value from the set {0,16,36,64}. The branch operation from layer c to layer 2c-1 is the number of coreparticle interconnection interfaces d from coreparticle 1 to coreparticle c. i Determine and set the number of interconnection interfaces d between core particles within a core particle i The branch operation from layer 2c to layer 3c-1 is performed by core particle 1 to the memory size b in c. i Determine and set the memory size b within a core particle i Get a value from the set {8,16,32}.

[0158] It should be understood that Figure 6 For the sake of clarity, many nodes are omitted. In fact, each branch of the next layer should be connected to each node of the previous layer. In addition, because the above attribute parameters are independent of each other, the order of branches can be changed as needed, not limited to Figure 6 in the order shown.

[0159] like Figure 7 As shown, starting from the 3c layer, each node is interconnected according to the intra-core and inter-core variables e i,j,k and α i,j,m,n The value expands the branch, and each node branches out two child nodes corresponding to the case where the interconnected variable takes the value of 0 or 1. The interconnected variables in the core particle are The number of interconnected variables between core particles is indivual.

[0160] It should be understood that Figure 7 In order to make the diagram clear, many nodes are omitted. In fact, each group of branches in the next layer should be connected to each node in the previous layer. Figure 7 The order of branches is not shown, but can be changed as needed.

[0161] In addition, as mentioned above, in order to speed up the search process, nodes can be pruned. Nodes that meet any pruning rule will be pruned and can no longer branch. The remaining unpruned nodes are added to the work queue WQ for the next branch.

[0162] Figure 8The following three examples of pruning rules are given:

[0163] 1) Optimality pruning:

[0164] At the node If it is a leaf node (that is, all variables have been assigned and no child nodes will be branched out), if its objective function value is Greater than the objective function value corresponding to the currently known optimal solution (denoted as the current optimal objective function value σ * ), which means leaf node The minimum running time is greater than the global minimum running time σ that has been searched * , then the node is pruned; otherwise, Added to WQ.

[0165] At the node If it is a non-leaf node, the minimum value is estimated. If the estimated minimum value of the objective function is greater than the current optimal objective function value σ * , which means non-leaf node The minimum running time is greater than the global minimum running time σ that has been searched * , then the node is pruned; otherwise, Added to WQ.

[0166] For example Figure 8 As shown in (a), in the case of minimizing the running performance, nodes 2 and 3 obtained by the branch of node 1 are judged, and the objective function value or estimated minimum value σ2 corresponding to node 2 is greater than σ * In the case of , node 2 is pruned.

[0167] 2) Infeasibility pruning:

[0168] If the node If the constraints mentioned above, the currently fixed mapping relationship or other infeasibility rules are not met, the node is pruned.

[0169] For example Figure 8 As shown in (b), nodes 2 and 3 obtained by branching from node 1 are judged, and the system power consumption corresponding to node 3 is In the case of , node 3 does not meet the aforementioned power consumption constraint, and node 3 is pruned.

[0170] 3) Pruning by queue length:

[0171] In large multi-chip systems, the number of hardware design variables is enormous, making a traversal search computationally prohibitive. A trade-off between performance and computational effort can be achieved by presetting a maximum queue length. A search method can be designed that doesn't necessarily require finding the absolute optimal value for the target performance, but rather ensures an acceptable approximation to the optimal value while constraining the work queue length.

[0172] Therefore, during the branching process, if the current work queue length |WQ| is not less than the preset queue maximum length W, all nodes obtained by the current branch are pruned.

[0173] For example Figure 8 As shown in (c), the current work queue length |WQ| is judged. When the current work queue length |WQ|=W, both nodes 2 and 3 branched from node 1 are pruned.

[0174] Thus, through the above-mentioned solution of the embodiment of the present disclosure, it is possible to obtain the optimal topology of the hardware running the target application within certain power consumption and area constraints. It is very flexible, for example, it can add many long links (such as connecting to non-adjacent cores to reduce communication time). Compared with the topology of currently known architectures such as REED, it can greatly reduce circuit complexity, reduce bandwidth conversion, routing congestion and other problems, thereby reducing hardware costs, communication delays and communication time. The efficient on-chip network design designed by the embodiment of the present disclosure can ensure fast data transmission and optimize system bandwidth and latency.

[0175] Furthermore, the multi-chip system designed according to the disclosed embodiments can achieve task-parallel computing and optimized data flow organization, minimizing data movement and significantly improving the computational efficiency of target applications (such as FHE applications). Furthermore, by constructing a multi-chip integrated system while balancing various parameters, it is possible to improve the problem of reduced resource utilization caused by increased parallelism in parallel circuits, enhance the system's flexibility and adaptability, and enable it to handle computing tasks for a wider range of applications.

[0176] According to another embodiment, a computing device is also provided, such as the following Figure 9 shown.

[0177] Figure 9 FIG2 shows a schematic structural diagram of a computing device that can be used to implement the method for optimizing design parameters of a multi-chip system according to at least one embodiment of the present disclosure.

[0178] See also Figure 9 , the computing device 900 includes a memory 910 and a processor 920 .

[0179] The processor 920 may be a multi-core processor or may include multiple processors. In some embodiments, the processor 920 may include a general-purpose main processor and one or more special coprocessors, such as a graphics processing unit (GPU) or a digital signal processor (DSP). In some embodiments, the processor 920 may be implemented using customized circuits, such as application-specific integrated circuits (ASICs) or field-programmable gate arrays (FPGAs).

[0180] The memory 910 may include various types of storage units, such as system memory, read-only memory (ROM), and permanent storage devices. ROM may store static data or instructions required by the processor 920 or other modules of the computer. The permanent storage device may be a readable and writable storage device. The permanent storage device may be a non-volatile storage device that does not lose stored instructions and data even when the computer is powered off. In some embodiments, the permanent storage device uses a large-capacity storage device (such as a magnetic or optical disk, flash memory) as the permanent storage device. In other embodiments, the permanent storage device may be a removable storage device (such as a floppy disk, optical drive). The system memory may be a readable and writable storage device or a volatile readable and writable storage device, such as dynamic random access memory. The system memory may store some or all instructions and data required by the processor during operation. In addition, the memory 910 may include any combination of computer-readable storage media, including various types of semiconductor memory chips (DRAM, SRAM, SDRAM, flash memory, programmable read-only memory), and magnetic disks and / or optical disks may also be used. In some embodiments, the memory 910 may include a readable and / or writable removable storage device, such as a compact disc (CD), a read-only digital versatile disc (e.g., DVD-ROM, dual-layer DVD-ROM), a read-only Blu-ray disc, an ultra-density optical disc, a flash memory card (e.g., SD card, mini SD card, Micro-SD card, etc.), a magnetic floppy disk, etc. Computer-readable storage media do not include carrier waves and transient electronic signals transmitted wirelessly or wired.

[0181] The memory 910 stores executable codes. When the executable codes are processed by the processor 920 , the processor 920 can execute the above-mentioned method for optimizing the design parameters of the multi-chip system.

[0182] In addition, the method according to the present disclosure may also be implemented as a computer program or a computer program product, which includes computer program code instructions for executing the above steps defined in the above method of the present disclosure.

[0183] Alternatively, the present disclosure may also be implemented as a non-transitory machine-readable storage medium (or computer-readable storage medium, or machine-readable storage medium) on which executable code (or computer program, or computer instruction code) is stored. When the executable code (or computer program, or computer instruction code) is executed by a processor of an electronic device (or computing device, server, etc.), the processor is caused to perform the various steps of the above-mentioned method according to the present disclosure.

[0184] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both.

[0185] The flowcharts and block diagrams in the accompanying drawings show the possible architecture, functions and operations of the systems and methods according to multiple embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of code, and the part of the module, program segment or code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0186] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for optimizing design parameters of a multi-core system, comprising: Obtain the task graph corresponding to the target application, where a single task is executed by a single core in the core particle; The design parameters of the multi-core particle system are optimized through multiple rounds of iterative operations, wherein any i-th round of iterative operations includes: Fixing the current hardware design variables of the multi-core system, and updating the mapping relationship between each task in the task graph and each core in the multi-core system with the goal of optimizing the running performance of the target application; Based on the updated mapping relationship, the hardware design variables of the multi-chip system are updated with the goal of optimizing the operating performance.

2. The method according to claim 1, wherein The target application is an encrypted neural network based on fully homomorphic encryption (FHE), and the single task is a basic operator in the FHE operation.

3. The method according to claim 1, wherein Said operational performance depends on the communication volume and the communication path; Updating the mapping relationship between each task in the task graph and each core in the multi-core particle includes: With the goal of optimizing the communication volume, the task graph is divided into a plurality of subgraphs under constraints related to the hardware design variables; The multiple subgraphs are mapped one by one to multiple coregrains in the multi-coregrain system, and with the goal of optimizing the communication path, the tasks in each subgraph are mapped one by one to the cores in the corresponding coregrain.

4. The method according to claim 3, wherein: The hardware design variables include the number of cores and the number of cores in the core; dividing the task graph into multiple subgraphs includes: A graph partitioning algorithm is adopted to partition the task graph into multiple subgraphs under the constraints of the current number of cores in the multi-core system and the number of cores in each core. The task graph is then partitioned into multiple subgraphs with the goal of minimizing the amount of inter-core communication.

5. The method according to claim 4, wherein With the goal of optimizing the communication path, the tasks in each subgraph are mapped one by one to the cores in the corresponding core particles, including: Based on the inter-core particle communication volume and / or intra-core particle communication volume of the tasks, the tasks in each subgraph are mapped one by one to the cores in the corresponding core particles in accordance with the preset mapping rules related to the communication paths.

6. The method according to claim 5, wherein: The mapping rule includes mapping tasks in sequence according to a priority rule, wherein first-category tasks are mapped to idle cores closest to the inter-chiplet interconnection interface, and second-category tasks are mapped to idle cores closest to the geometric center of the chiplet; wherein the first-category tasks are tasks whose inter-chiplet communication volume exceeds a first threshold, and the second-category tasks are tasks whose intra-chiplet communication volume exceeds a second threshold; The priority rules include at least one of the following: the priority of the first category tasks is arranged from high to low according to the communication volume between core particles, and the priority of the second category tasks is arranged from high to low according to the communication volume within the core particle, and the priority of the first category tasks is higher than the priority of the second category tasks.

7. The method according to claim 1, wherein The hardware design variables take values from a preset numerical set, and updating the hardware design variables of the multi-core system includes: using a branch and bound algorithm based on a search tree to determine the optimal solution of the hardware design variables that optimizes the operating performance under the current mapping relationship as the target value, and updating the hardware design variables to the target value, wherein the nodes of the search tree represent a set of partial or complete solutions for some or all of the hardware design variables that take values from the preset numerical set.

8. The method according to claim 7, wherein: The branch and bound algorithm includes: Initializing the optimal value of the operating performance and the optimal solution of the hardware design variable, and pushing the root node of the search tree into a work queue; Execute the target operation cyclically until the work queue is cleared, and return the optimal solution when the work queue is cleared as the target value. The target operation includes: Take out the current node in the work queue, If the current node is a leaf node and its corresponding operating performance value is better than the current optimal value, the optimal value is updated to the operating performance value corresponding to the current node, and the optimal solution is updated to a set of solutions represented by the current node; In the case that the current node is a non-leaf node, branching and pruning are performed on the current node according to preset branching and pruning rules, and the nodes of the search tree newly added after the branching and pruning are pushed into the work queue.

9. The method according to claim 8, wherein The hardware design variables include x attribute parameters of the core particle and y structural variables within and between core particles; The branching rule includes: if the level of the current node in the search tree is less than x, branching the current node by adding an attribute parameter and its corresponding solution; If the level is greater than or equal to x, branch the current node by adding a structural variable and its corresponding solution.

10. The method according to claim 9, wherein: The attribute parameters include the number of cores in the core, the number of core-to-core interconnection interfaces in the core, and / or the memory size in the core; the structural variables include the interconnection variables between cores in the same core, the interconnection variables between cores in the same core and core-to-core interconnection interfaces, and / or the interconnection variables between core-to-core interconnection interfaces of different cores.

11. The method according to claim 8, wherein The pruning rules include at least one of the following: If the node obtained by branching is a leaf node, prune the node whose corresponding running performance value is not better than the current optimal value; If the node obtained by branching is a non-leaf node, the running performance value corresponding to the node is estimated, and the nodes whose estimated value is not better than the current optimal value are pruned; Prune nodes that do not satisfy the current mapping relationship; When the current queue length of the work queue has reached a preset queue length, the nodes obtained by branching are pruned.

12. The method according to claim 1, wherein The running performance is the running time, which is calculated as follows: Determine the computation time of each task and the communication time of each edge in the task graph, Determine the longest path in the task graph based on the computation time and the communication time, The total time consumed on the longest time-consuming path is calculated as the running time.

13. The method according to claim 1, wherein The multiple rounds of iterative operations are all performed under at least one of the following constraints: The area of the multi-core particle system is not greater than a first preset value; The power consumption of the multi-chip system is not greater than a second preset value; Each core cannot directly interconnect with the cores in other cores and the inter-core interconnection interface; Interconnection interfaces between different cores in the same core cannot be directly interconnected; The tasks correspond one-to-one to the cores.

14. A computing device comprising: processor; as well as A memory having executable codes stored thereon, which, when executed by the processor, causes the processor to perform the method according to any one of claims 1 to 13. 15 . A non-transitory machine-readable storage medium having executable code stored thereon, wherein when the executable code is executed by a processor of an electronic device, the processor is caused to perform the method according to claim 1 .

Images