A method and apparatus for neighborhood node communication for scientific computing

Abstract

The application discloses a kind of scientific computing-oriented neighborhood node communication method and device, it is related to the field of many-core array chip, to optimize the field node communication efficiency of scientific calculation with spatial locality characteristic.The three-dimensional scientific computing space to be solved is divided into multiple space subdomains, and the three-dimensional index of each space subdomain is mapped into one-dimensional index using a space-filling curve algorithm;According to the principle of load balancing, two-level balanced mapping is carried out to generate a global mapping table of space subdomain to computing cluster;And further construct a neighbor data mapping table for each computing cluster;According to the neighbor data mapping table, the load data of the neighbor space subdomain is obtained for each computing cluster respectively, so as to construct a neighbor list for each load according to the neighbor data mapping table.This application greatly reduces the communication overhead between field nodes, improves the load balancing of computing cluster, and reduces the communication delay in the neighbor list construction process.

Description

Technical Field

[0001] This invention relates to the field of many-core array chip technology, and in particular to a neighborhood node communication method and apparatus for scientific computing. Background Technology

[0002] As the scale of scientific computing continues to expand, fields such as molecular dynamics simulations, computational fluid dynamics, astrophysical N-body simulations, and finite element analysis place extremely high demands on computational performance. These types of scientific computing problems typically exhibit significant spatial locality, meaning that computational units only need to frequently interact with neighboring units in physical space, while interacting less with distant units.

[0003] In three-dimensional space, a computing unit typically needs to exchange data with its 26 neighboring units. In traditional CPU- or GPU-based general-purpose computing architectures, this data exchange is usually conducted via shared memory (such as DDR / HBM), with the data flow being "computing unit-memory-computing unit". This model has the following serious drawbacks: The communication overhead is huge: the "memory wall" problem causes a lot of time to be spent on data transfer rather than effective computation, and communication latency has become a key bottleneck restricting overall efficiency.

[0004] Lack of topology awareness: The hardware interconnect of traditional many-core array architectures usually does not take into account the three-dimensional spatial topology of scientific computing, which means that logical neighbors may be physically far apart, increasing the number of communication hops and latency.

[0005] Currently, there is a lack of an efficient and universal neighborhood node communication mechanism for on-chip many-core array accelerators that can directly leverage the advantages of hardware topology to accelerate scientific computing with spatial locality. Summary of the Invention

[0006] The purpose of this invention is to provide a neighborhood node communication method and apparatus for scientific computing, addressing all or part of the problems mentioned above, so as to optimize the efficiency of neighborhood node communication in scientific computing with spatial locality characteristics.

[0007] The technical solution adopted in this invention is as follows: In a first aspect, this application provides a neighborhood node communication method for scientific computing, applied to many-core processors, comprising: S1. Divide the three-dimensional scientific computing space to be solved into multiple spatial subdomains, each of which contains at least one load; continuously assign a three-dimensional index to each of the spatial subdomains according to the spatial distribution; S2. The three-dimensional index is mapped to a one-dimensional index using a space-filling curve algorithm; S3. Based on the load balancing principle, continuously map all the spatial subdomains to multiple computing node groups, and continuously map the spatial subdomain subsets within each computing node group to multiple computing clusters; generate a global mapping table from spatial subdomains to computing clusters; S4. Based on the global mapping table, construct a neighbor data mapping table for each computing cluster, wherein the neighbor data mapping table maps the data addresses of each neighbor spatial subdomain to each spatial subdomain. S5. According to the neighbor data mapping table, obtain the load data of the neighbor space subdomain for each computing cluster, so that the computing cluster can construct a neighbor list for each load according to the neighbor data mapping table during the computing phase.

[0008] Optionally, based on load balancing principles, all the aforementioned spatial subdomains are continuously mapped to multiple computing node groups, including: S301. Arrange all the spatial subfields in ascending order according to the one-dimensional index; S302. The spatial subdomains are traversed sequentially, and the cumulative load at each traversal position is calculated. The spatial subdomain whose cumulative load is closest to the first average load of all computing node groups is used as the splitting position, and the arranged spatial subdomains are split. This process is repeated until all the arranged spatial subdomains are grouped. S303. The space filling curve algorithm is used to map each spatial subdomain group to each computing node group.

[0009] Optionally, based on load balancing principles, the spatial subdomain subsets within each computing node group are continuously mapped to multiple computing clusters, including: S304. Arrange all the spatial subdomains in the computing node group in ascending order according to the one-dimensional index; S305. The spatial subdomains are traversed sequentially, and the cumulative load at each traversal position is calculated. The spatial subdomain whose cumulative load is closest to the second average load of all computing clusters is used as the splitting position, and the arranged spatial subdomains are split. This process is repeated until all the arranged spatial subdomains are grouped. S306. Using the space filling curve algorithm, each spatial subdomain is grouped and mapped to each computation cluster.

[0010] Optionally, based on the global mapping table, a neighbor data mapping table is constructed for each computing cluster, including: S401. For each of the aforementioned spatial subdomains, determine the one-dimensional index of all neighboring spatial subdomains; S402. Based on querying each of the one-dimensional indexes in the global mapping table, obtain the neighbor type of each neighbor space subdomain; the neighbor type is divided into three categories: neighbors within a computing cluster, neighbors within a computing node group, and neighbors between computing node groups. S403. In each computing cluster's storage unit, a first storage area and a second storage area are respectively opened. The first storage area stores all load data within the computing cluster, and the second storage area stores copies of the load data of neighbors between computing node groups. S404. Construct a neighbor data mapping table for each computing cluster. The neighbor data mapping table maps the data addresses of each neighbor spatial subdomain to each spatial subdomain. Specifically, the data addresses of neighbors within a computing cluster are mapped to the first storage area, the data addresses of neighbors within a computing node are mapped to the first storage area of ​​the corresponding neighbor computing cluster within the same computing node group, and the data addresses of neighbors between computing node groups are mapped to the corresponding positions in the second storage area.

[0011] Optionally, based on the neighbor data mapping table, load data for the neighbor spatial subdomains is obtained for each computing cluster, including: S501. Traverse the neighbor data mapping table, filter out the neighbor space subdomains whose neighbor type is inter-computation node group neighbor, and determine the target computing cluster corresponding to each of the filtered neighbor space subdomains according to the global mapping table. S502, request the required load data of the neighbor space subdomain from each target computing cluster; according to the neighbor data mapping table, write the requested load data to the corresponding position in the second storage area.

[0012] Optionally, request the required load data for the neighboring spatial subdomains from each target computing cluster, including: The subdomain identifiers of all neighboring spatial subdomains mapped to the same target computing cluster are loaded into the same data request to simultaneously request the load data of all required neighboring spatial subdomains from the same target computing cluster.

[0013] Optionally, methods for requesting load data from the target computing cluster for the required neighboring spatial subdomains include: Calculate the physical distance from the current computing cluster to the target computing cluster; If the physical distance indicates that the current computing cluster and the target computing cluster are adjacent, then the load data of the required neighboring spatial subdomain is requested through the direct connection port between the current computing cluster and the target computing cluster; If the physical distance indicates that the current computing cluster and the target computing cluster are in a remote relationship, then the load data of the required neighboring spatial subdomain is requested through the global exchange network.

[0014] Optionally, based on the neighbor data mapping table, a neighbor list is constructed for each load, including: Based on the neighbor data mapping table, load data of the neighbor space subdomain is obtained from the storage unit for each load; wherein: For a neighbor space subdomain whose neighbor type is compute cluster neighbor, read the load data of the neighbor space subdomain from the first storage area; For a neighbor space subdomain whose neighbor type is a neighbor within a compute node group, the load data of the neighbor space subdomain is read from the first storage area of ​​the neighbor within the compute node group through the local cross-high-speed network within the compute cluster. For a neighbor space subdomain whose neighbor type is compute node group neighbor, read the load data of the neighbor space subdomain from the corresponding location in the second storage area; The neighbor list is constructed based on the load data of the neighbor space subdomains obtained from the storage unit.

[0015] Optionally, the method by which the computing cluster constructs the neighbor list during the computing phase includes: The computing cluster acquires the load data of all spatial subdomains within the computing cluster, and divides all the load into each computing core according to the number of computing cores contained therein. Each computing core obtains the load data of the neighbor space subdomain of each load in parallel from the storage unit and loads it into the private L0 cache of each computing core. Each computing core constructs the neighbor list based on the load data of the neighbor space subdomain in the L0 cache.

[0016] In a second aspect, this application also provides a neighborhood node communication device for scientific computing, applied to a many-core processor. The device includes a processor and a storage medium, the storage medium storing a computer program, and the processor running the computer program to execute the aforementioned neighborhood node communication method for scientific computing.

[0017] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: This invention divides the three-dimensional scientific computing space into multiple spatial subdomains and maps their three-dimensional indices to one-dimensional indices using a space-filling curve algorithm. A rigorous "spatial adjacency-memory adjacency-hardware adjacency" mapping chain is then established through a two-level balanced mapping. This ensures that high-frequency neighborhood interactions are concentrated between computing nodes with shorter communication distances, utilizing local cross-connection high-speed networks within computing nodes for fast point-to-point direct transmission. Low-frequency neighborhood communications can be routed via multi-hops using global on-chip network switches. This significantly reduces communication overhead and improves communication efficiency. Furthermore, the two-level balanced mapping method of this application load balances the computing clusters, ensuring that load deviations between computing node groups are minimized while limiting most neighborhood interactions to within a single computing node group or between adjacent computing clusters, thus reducing the need for global communication across computing nodes at the source. Additionally, this application achieves high-quality mapping from three-dimensional spatial indices to two-dimensional computing arrays by employing a space curve filling algorithm. Because the space curve filling algorithm mathematically eliminates the long-distance "jumps" at spatial boundaries that occur in traditional dimensionality reduction and expansion algorithms (such as row-first search), it ensures that the 26 adjacent neighbor subdomains in three-dimensional space have extremely high clustering in the linear memory layout. This characteristic aligns with the sensitivity of many-core architectures to on-chip storage bandwidth, not only optimizing the locality of memory access but also significantly improving the performance of the many-core processor's hardware prefetcher and greatly reducing memory access latency during the neighbor list construction process. Attached Figure Description

[0018] The present invention will be described by way of example and with reference to the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating the implementation of a neighborhood node communication method for scientific computing.

[0019] Figure 2 This is a schematic diagram of the partitioning of a spatial subdomain in one embodiment.

[0020] Figure 3 This is a schematic diagram of the two-dimensional grid array layout of computing nodes.

[0021] Figure 4 This is a schematic diagram of the mapping process from a spatial subdomain to a computing node group.

[0022] Figure 5 This is a flowchart of constructing a molecular dynamics neighbor list for a liquid water system.

[0023] Figure 6 This is a comparison chart of the communication ratio of this application and the traditional method under different neighbor types. Detailed Implementation

[0024] All features disclosed in this specification, or all steps in all disclosed methods or processes, may be combined in any way, except for mutually exclusive features and / or steps.

[0025] Any feature disclosed in this specification (including any appended claims and abstract) may be replaced by other equivalent or similar features, unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is merely one example of a series of equivalent or similar features.

[0026] To address the problems of high communication overhead and lack of spatial topology awareness in existing technologies, this application proposes a neighborhood node communication method and apparatus for scientific computing, aiming to accelerate neighborhood node communication for scientific computing with spatial locality characteristics.

[0027] like Figure 1 As shown, the neighborhood node communication method for scientific computing provided in this application includes the following stages: S1. Divide the three-dimensional scientific computing space to be solved into multiple spatial subdomains, each containing at least one load; continuously assign three-dimensional indexes to each spatial subdomain according to the spatial distribution.

[0028] The so-called three-dimensional scientific computing space to be solved refers to the three-dimensional space formed by scientific computing objects such as molecular dynamics simulations, computational fluid dynamics, astrophysical N-body simulations, and finite element analysis. For example, for a molecular dynamics simulation problem, the three-dimensional scientific computing space is the three-dimensional distribution space of molecules.

[0029] Suppose the three-dimensional scientific computing space to be solved is represented as Based on a preset granularity (e.g., unit size), in Divided into three dimensions respectively Thus, the total is Each spatial subfield (cell).

[0030] Each spatial subdomain contains at least one load. Corresponding to the above embodiment, each spatial subdomain contains at least one molecule. Each spatial subdomain is assigned a three-dimensional index based on its spatial distribution.

[0031] For example, each spatial subdomain is assigned a three-dimensional index coordinate, represented as follows: ,in They represent in The sorting on the top has Thus, a three-dimensional index representing the continuity of a spatial subdomain in physical space can be obtained.

[0032] like Figure 2As shown, assuming the three-dimensional scientific computing space is divided into There are 3 spatial subdomains, where the 3D index coordinates of the spatial subdomain located at the center are . This spatial subdomain has 26 neighboring spatial subdomains, with corresponding 3D index coordinates as follows: , ... wait.

[0033] S2. Use the space filling curve algorithm to map the three-dimensional index to a one-dimensional index.

[0034] The space-filling curve algorithm, through index encoding, achieves the mapping of indices of different dimensions while preserving the spatial location characteristics of the indexes. In this embodiment, by mapping three-dimensional indices to one-dimensional indices, the locality of neighborhood spatial subdomains in memory layout is established. That is, a topological mapping relationship is established between logical computing domains and physical computing nodes, realizing a direct correspondence from spatial neighbors to hardware neighbors.

[0035] As an optional implementation, this application uses the Hilbert filling curve algorithm to map the three-dimensional index of each spatial subdomain to a one-dimensional index, thereby achieving index serialization while preserving the locality of the spatial subdomain.

[0036] Specifically, the one-dimensional index of the mapping is represented as This one-dimensional index The calculation methods include: Given the 3D index coordinates of a spatial subdomain, calculate the order of the space-filling curve required to cover the entire 3D scientific computing space. , This represents the floor function, where n represents the minimum cube side length required to cover the entire three-dimensional scientific computing space. The exponent. Initialize the one-dimensional index h to 0, initialize the rotation state s to 0 (representing the standard direction), and set the initial value of the bit processing counter i to n. 1. (Processing starts from the most significant bit). Then, a recursive mapping is performed bit by bit. Finally, the value stored in variable h is the one-dimensional index of the space-filling curve mapping corresponding to the three-dimensional index. .

[0037] The above mapping calculation maintains the spatial proximity of spatial subdomains, that is, spatial subdomains that are adjacent in physical space remain adjacent in one-dimensional index.

[0038] S3. Based on the load balancing principle, continuously map all spatial subdomains to multiple computing node groups, and continuously map the spatial subdomain subsets within each computing node group to multiple computing clusters; generate a global mapping table from spatial subdomains to computing clusters.

[0039] The continuous mapping of spatial subdomains to compute node groups (Tile Groups, TGs) and compute clusters (Tiles) is based on the load balancing principle. That is, in the embodiments of this application, in addition to maintaining the proximity of physically adjacent spatial subdomains on compute node groups and compute clusters as much as possible to reduce communication overhead across compute node groups, the load within each compute node group tends to be balanced.

[0040] The on-chip many-core processor has multiple TGs, which are physically arranged in a... The two-dimensional grid array arrangement, i.e. ( The TGs are arranged in a two-dimensional grid array. Each TG has continuous two-dimensional physical coordinates in this two-dimensional grid array, represented as follows: ,in This represents the x-coordinate of TG in a two-dimensional grid array. This represents the ordinate of TG in the two-dimensional grid array. In this embodiment, the two-dimensional grid array layout of the computing nodes in the many-core architecture is as follows: Figure 3 As shown, the range of the two-dimensional physical coordinates P of TG is... .

[0041] As an optional implementation method, such as Figure 4 As shown, the method for continuously mapping all spatial subdomains to multiple computing node groups according to the load balancing principle includes the following steps: S301. Sort all spatial subfields in ascending order according to the one-dimensional index.

[0042] As described in the previous embodiment, the one-dimensional index of the spatial subdomain is a binary string of length n (i.e., the order of the space-filling curve). Based on the magnitude of the numerical value it represents, the string is sorted in ascending order to obtain a one-dimensional index sequence table. This one-dimensional index sequence table preserves the proximity characteristics of the spatial subdomains in physical space.

[0043] S302. The spatial subdomains are traversed sequentially, and the cumulative load at each traversal position is calculated. The spatial subdomain whose cumulative load is closest to the first average load of all computing node groups is used as the splitting position, and the arranged spatial subdomains are split. This process is repeated until all the arranged spatial subdomains are grouped.

[0044] Step S302 is used to segment the one-dimensional index sequence list, thereby grouping the corresponding spatial subdomains.

[0045] As mentioned earlier, each spatial subdomain contains at least one load (such as the number of particles / molecules contained within the spatial subdomain), and the estimated value of the load of the spatial subdomain is used as the weight of that spatial subdomain when grouping. The total weight of all spatial subdomains c within the entire three-dimensional scientific computing space. Assuming the number of many-core processors (TGs) is M, then the first average load of each compute node group is... .

[0046] Traverse each spatial subfield in the order of the one-dimensional index sequence list and calculate the cumulative load at the current traversal position.

[0047] Assume the cumulative load includes the weights of the currently traversed spatial subdomains, denoted as... The grouped load that does not include the weights of the currently traversed spatial subdomains is represented as: Calculate the cumulative load while traversing each spatial subdomain. Simultaneously compare and The size. If Then continue traversing the next spatial subdomain until... .like Then the current traversed subfield is used as the dividing position, if Then calculate and distance and grouped load and distance Compare two distances and The size of the distance is used to select the spatial subfield corresponding to the smallest of the two distances as the splitting position. For example, If the previous spatial subfield (relative to the current traversal position) is used as the dividing position, then the previous spatial subfield is used as the dividing position; otherwise, if... Then the currently traversed subfield is used as the dividing point. If Then, one of the two spatial subdomains (the previous spatial subdomain and the current spatial subdomain) is randomly selected as the seat partitioning position. As a preferred implementation, the previous spatial subdomain is selected as the partitioning position to ensure that the cumulative weight of the spatial subdomain grouping does not exceed the first average weight. The weights are then re-accumulated starting from the next traversed spatial subdomain from the partitioning position. Similarly, based on the one-dimensional index sequence list, all segmentation positions are determined, and all spatial subdomains are grouped. The last group contains all remaining spatial subdomains after segmentation, resulting in no more than M spatial subdomain groups. Here, we take obtaining M spatial subdomain groups as an example.

[0048] To facilitate the mapping of spatial subdomain groups, each spatial subdomain group is consecutively numbered to obtain a one-dimensional grouping index. .

[0049] S303. The space filling curve algorithm is used to map each spatial subdomain group to each computing node group.

[0050] Taking the Hilbert filling curve algorithm as an example, the mapping between the one-dimensional grouping index m and the two-dimensional physical coordinate P of TG is expressed as follows: ; in, This represents a space-filling curve mapping function from a one-dimensional group index (i.e., sequence number) to two-dimensional physical coordinates.

[0051] The above method completes a balanced grouping of all spatial subdomains and the mapping to the two-dimensional computation node group. This mapping relationship is as follows: Figure 4 As shown. This mapping calculation ensures that the one-dimensional grouping indices of adjacent load intervals are also adjacent on the two-dimensional physical array, thus extending the spatial proximity maintained by the load balancing partition to the TG hardware topology level.

[0052] In addition, in this embodiment, a secondary balanced mapping is performed on the spatial subdomains, that is, the spatial subdomain subsets within each computing node group are continuously mapped to multiple computing clusters.

[0053] The secondary equalization mapping method is similar to the primary equalization mapping method. It also involves grouping each spatial subdomain and then mapping each group to a two-dimensional tile, thus maintaining the proximity characteristics of the load in the physical space.

[0054] As an optional implementation method, the quadratic equalization mapping method includes: S304. Sort all spatial subdomains in the compute node group in ascending order of their one-dimensional indices. This sorting method is the same as in step S301.

[0055] S305. Sequentially traverse the spatial subdomains, calculate the cumulative load at each traversal position, and use the spatial subdomain whose cumulative load is closest to the second average load of all computing clusters as the splitting position to split the arranged spatial subdomains; repeat this process until all spatial subdomains of the arrangement are grouped.

[0056] The grouping method in step S305 is the same as that in step S302, the only difference is that in step S305 the number of tiles is used as the grouping base, while in step S302 the number of TGs is used as the grouping base.

[0057] Specifically, the tiles within TG are physically arranged in a... The two-dimensional grid array arrangement, i.e. ( The tiles are arranged in a two-dimensional grid array. Each tile in this two-dimensional grid array has continuous two-dimensional physical coordinates, represented as follows: ,in This represents the x-coordinate of a tile in a two-dimensional grid array. This represents the ordinate of the tile in the two-dimensional grid array. In this embodiment, the two-dimensional grid array layout of the tile in the many-core architecture is as follows: Figure 3 As shown, the range of the two-dimensional physical coordinates T of the Tile is... .

[0058] The total weight of all spatial subdomains c within the entire 3TG , Let represent the set of spatial subdomains within TG. Assuming the number of tiles in TG is K, then the second average load of each tile is . .

[0059] Traverse each spatial subfield in the order of the one-dimensional index sequence list and calculate the cumulative load at the current traversal position.

[0060] Assume the cumulative load includes the weights of the currently traversed spatial subdomains, denoted as... The grouped load that does not include the weights of the currently traversed spatial subdomains is represented as: Calculate the cumulative load while traversing each spatial subdomain. Simultaneously compare and The size. If Then continue traversing the next spatial subdomain until... .like Then the current traversed subfield is used as the dividing position, if Then calculate and distance and grouped load and distance Compare two distances and The size of the distance is used to select the spatial subfield corresponding to the smallest of the two distances as the splitting position. For example, If the previous spatial subfield (relative to the current traversal position) is used as the dividing position, then the previous spatial subfield is used as the dividing position; otherwise, if... Then, the current traversed subfield is used as the splitting point. Weights are re-accumulated starting from the next traversed subfield from the splitting point. .like Then, one of the two spatial subdomains (the previous spatial subdomain and the current spatial subdomain) can be randomly selected as the segmentation position. As a preferred implementation, the previous spatial subdomain is chosen as the segmentation position to ensure that the cumulative weight of the spatial subdomain grouping does not exceed the second average weight. This process is repeated until all segmentation positions are determined based on the one-dimensional index sequence list, completing the grouping of all spatial subdomains within TG. The last group contains all remaining spatial subdomains after segmentation, resulting in no more than K spatial subdomain groups. Here, we take obtaining K spatial subdomain groups as an example.

[0061] To facilitate the mapping of spatial subdomain groups, each spatial subdomain group is consecutively numbered to obtain a one-dimensional subgroup index. .

[0062] S306. Using the space filling curve algorithm, each spatial subdomain is grouped and mapped to each computation cluster.

[0063] Taking the Hilbert filling curve algorithm as an example, the one-dimensional subgroup index is... Mapping to the two-dimensional physical coordinates T of the Tile, it can be represented as: .

[0064] The above method maps the one-dimensional subgroup index k of the spatial subdomain to the two-dimensional physical coordinates of the tile inside the TG, ensuring that logically adjacent spatial subdomains are also adjacent in terms of physical tile.

[0065] This completes the mapping from spatial subdomains to computing clusters. Based on the first and second leveling mappings, a global mapping table from spatial subdomains to computing clusters is generated. This global mapping table contains N entries, each storing the home address of the corresponding Cell, in the format {TG_ID, Tile_Local_ID}. Here, TG_ID represents the unique identifier of the TG within the many-core processor, which can be represented by the one-dimensional grouping index m corresponding to the TG; Tile_Local_ID represents the unique identifier of the Tile within the TG, which can be represented by the one-dimensional sub-grouping index k corresponding to the Tile. This global mapping table is distributed and stored in the storage unit of each Tile (such as local high-speed scratch memory) during the initialization phase (before the computing phase starts) for local lookup.

[0066] S4. Based on the global mapping table, construct a neighbor data mapping table for each computing cluster. The neighbor data mapping table maps the data addresses of each neighbor spatial subdomain to each spatial subdomain.

[0067] Before the computation phase begins, each tile must first resolve the spatial topology of the spatial subdomains it manages in order to determine the communication path for obtaining load data from neighboring spatial subdomains.

[0068] Phase S4 is applied to each computation cluster. As an optional implementation, phase S4 includes the following steps: S401. For each spatial subdomain, determine the one-dimensional index of all neighboring spatial subdomains.

[0069] As mentioned earlier, each spatial subdomain has 26 neighboring spatial subdomains in the three-dimensional scientific computing space. The local spatial subdomain of each tile is then determined. The one-dimensional index of the 26 neighboring spatial subdomains. To easily distinguish it from the traversed spatial subdomains, the one-dimensional index of the neighboring spatial subdomains is represented as... .

[0070] S402. Based on querying each one-dimensional index in the global mapping table. Each neighbor type is obtained for each neighbor space subdomain.

[0071] Neighbor types are divided into three categories: intra-cluster neighbors (i.e., the neighbor's spatial subdomain and the currently traversed spatial subdomain are in the same Tile), intra-group neighbors (i.e., the neighbor's spatial subdomain and the currently traversed spatial subdomain are in the same TG but belong to different Tile), and inter-group neighbors (i.e., the neighbor's spatial subdomain and the currently traversed spatial subdomain belong to different TG).

[0072] The global mapping table records the two-level home address {TG_ID, Tile_Local_ID} from each spatial subdomain to the Tile. The TG_ID distinguishes whether they belong to the same TG, and the Tile_Local_ID distinguishes whether they belong to the same Tile. In this way, the neighbor types of the 26 neighbor spatial subdomains can be classified.

[0073] S403. Allocate a first storage area and a second storage area in the storage unit (such as Scratch Memory) of each computing cluster.

[0074] The first storage area stores all load data within the compute cluster, while the second storage area stores copies of load data from neighbors between compute node groups.

[0075] The first storage area is called the Home Data area, which is used to store all load data for the Tile local space subdomain.

[0076] The second storage area is called the Neighbor Copy Buffer, which caches only the load data of neighbors between compute node groups.

[0077] As an optional implementation, contiguous storage space is allocated within the storage unit as a second storage area. This second storage area stores the load data of neighboring compute node groups according to a layout strategy of "source tile address lexicographical aggregation".

[0078] Specifically, the load data of all neighboring compute node groups is arranged in ascending lexicographical order according to their home addresses {TG_ID, Tile_Local_ID}. For load data belonging to multiple spatial subdomains of the same Tile, the load data is stored consecutively in ascending order according to the subdomain identifier (such as subdomain ID, which can be represented by a one-dimensional index or other unique identifier assigned in an order). This design facilitates a direct communication mechanism for obtaining load data of neighboring compute node groups after the compute phase starts, effectively improving communication efficiency.

[0079] S404. Construct a neighbor data mapping table for each computing cluster.

[0080] The neighbor data mapping table maps the data addresses of each neighbor spatial subdomain to each spatial subdomain. Specifically, it maps the data addresses of neighbors within a compute cluster to the first storage area, the data addresses of neighbors within a compute node to the first storage area of ​​the corresponding neighbor compute cluster within the same compute node group, and the data addresses of neighbors between compute node groups to the corresponding locations in the second storage area.

[0081] The construction of the neighbor data mapping table facilitates the quick acquisition of load data for neighbor space subdomains after the computation phase starts.

[0082] As an optional implementation, a data pointer points to the memory address, and a data offset points to the corresponding location within the memory.

[0083] Specifically, the neighbor data mapping table contains one record for each neighbor spatial subdomain, and each record contains the following key fields: (1) Subdomain identifier of a neighboring space subdomain. For example, subdomain ID.

[0084] (2) Neighbor types. They are divided into three categories: neighbors within a computing cluster, neighbors within a computing node group, or neighbors between computing node groups.

[0085] (3) Data pointer. For neighbors within a compute cluster, it points to the first storage area of ​​the local tile; for neighbors within a compute node group, it points to the first storage area of ​​the neighbor tile (i.e., different tiles within the same TG); for neighbors between compute node groups, it points to the starting address of the second storage area of ​​the local tile.

[0086] (4) Data Offset. This field applies only to neighbors within compute node groups. It represents the offset of the neighbor's load data within its respective second storage area. By combining the data pointer and the data offset, the specific address of the neighbor's load data within the second storage area can be uniquely determined.

[0087] S5. Based on the neighbor data mapping table, obtain the load data of the neighbor space subdomain for each computing cluster, so that during the computing phase, the computing cluster can build a neighbor list for each load according to the neighbor data mapping table.

[0088] In the S5 phase, the methods for obtaining the load data of the neighbor spatial subdomains for each computing cluster based on the neighbor data mapping table include: S501. Traverse the neighbor data mapping table, filter out the neighbor space subdomains whose neighbor type is inter-computation node group neighbor, and determine the target computing cluster corresponding to each filtered neighbor space subdomain according to the global mapping table.

[0089] The neighbor data mapping table records the neighbor types of the neighbor spatial subdomains, which can be used to directly filter the neighbors between compute node groups. The global mapping table records the two-level home address {TG_ID, Tile_Local_ID} of each spatial subdomain (including the neighbors between compute node groups here), where the second-level address Tile_Local_ID represents the target compute cluster of the neighbors between compute node groups.

[0090] S502. Request the required load data of the neighbor space subdomains from each target computing cluster; write the requested load data to the corresponding location in the second storage area according to the neighbor data mapping table.

[0091] In the S5 phase, according to the defined communication protocol, the neighbor data mapping table is used to obtain the load data of the neighbor space subdomain for each computing cluster in order to construct the neighbor list.

[0092] As an optional implementation, a method for constructing a neighbor list based on a neighbor mapping table includes: Based on the neighbor data mapping table, construct a neighbor list for each load, including: (1) Based on the neighbor data mapping table, obtain the load data of the neighbor space subdomain from the storage unit for each load.

[0093] Specifically, the defined communication protocols include: 1) For a neighbor space subdomain whose neighbor type is compute cluster neighbor, read the load data of the neighbor space subdomain from the first storage area; 2) For neighbor space subdomains whose neighbor type is within the compute node group, load data of the neighbor space subdomains is read from the first storage area of ​​the neighbor within the compute node group through the local cross-connect high-speed network within the compute cluster. 3) For a neighbor space subdomain whose neighbor type is compute node group neighbor, read the load data of the neighbor space subdomain from the corresponding location in the second storage area (e.g., by determining the specific address through data pointer + data offset).

[0094] (2) Construct a neighbor list based on the load data of the neighbor space subdomain obtained from the storage unit.

[0095] In addition, in one alternative implementation, this application requests or responds to load data in a data aggregation manner.

[0096] Specifically, the methods described above for requesting the required load data of neighboring spatial subdomains from each target computing cluster include: (Requesting a compute cluster) loads the subdomain identifiers of all neighboring spatial subdomains that map to the same target compute cluster into the same data request, so as to request the load data of all required neighboring spatial subdomains from the same target compute cluster at the same time.

[0097] Correspondingly, the target computing cluster writes the load data of all required neighboring spatial subdomains into the same data response based on the received data request and feeds it back to the requesting computing cluster.

[0098] Based on the above design, this application defines a unified data packet structure. The data packet is constructed using a hierarchical home address {TG_ID, Tile_Local_ID}, which includes the source address and destination address in the data packet.

[0099] Request packet: Used to request payload data from neighboring spatial subdomains of the target computing cluster.

[0100] Request packet structure: [Packet header|Source address|Destination address|List of request subdomain IDs].

[0101] The “Packet Header” is a fixed structure that indicates the data packet type, length, etc.; the “Source Address” is the home address of the sender’s computing cluster; the “Destination Address” is the home address of the receiver’s computing cluster; and the “Request Subdomain ID List” is a set of subdomain identifiers that map to all neighboring spatial subdomains of the same target computing cluster.

[0102] Feedback packet (or data packet): Used to carry the actual payload data in response to the request packet.

[0103] Feedback packet structure: [Packet header|Source address|Destination address|Number of payload segments (U)|(Subdomain metadata segment_1, Data segment_1)|...|(Subdomain metadata segment_U, Data segment_U)].

[0104] (Subdomain Meta-information Segment_U, Data Segment_U) represents the relevant information of the load data of the U-th required neighbor space subdomain. The "Subdomain Meta-information Segment" indicates the attribute information of the load data, such as the subdomain identifier of the neighbor space subdomain and the length of the load data in this segment; the "Data Segment" is the load data of the required neighbor space subdomain.

[0105] The above feedback packet structure design ensures that the receiver can correctly receive and parse the payload data of multiple neighboring spatial subdomains.

[0106] As an optional implementation, this application employs a Tile concurrency mechanism for data exchange (requests and responses) of load data between neighboring spatial subdomains. Each Tile acts as an independent communication entity, utilizing built-in routing units to achieve parallel physical layer communication, thereby improving communication efficiency.

[0107] The above data exchange steps include: A. Data aggregation request from the requesting party.

[0108] Each tile iterates through its neighbor data mapping table, filtering out the home addresses corresponding to all "inter-computing node group neighbors". If the current tile needs to request load data from multiple spatial subdomains from the same target tile, the communication controller merges the subdomain identifiers (hereinafter referred to as subdomain IDs) of these spatial subdomains into a single request packet to reduce the number of communications. Finally, the communication controller within the tile injects the request packet into the routing.

[0109] B. Response processing and feedback.

[0110] Once the target tile receives the request packet, it extracts the list of request subdomain IDs from the packet. Based on the subdomain ID, it queries the local first storage area and reads the corresponding payload data. The read payload data is then encapsulated in ascending order of the subdomain IDs to generate a response packet. Finally, the response packet is sent back to the requesting tile.

[0111] C. Data reception and storage.

[0112] When the requesting Tile receives the returned feedback packet, the communication controller parses the source address {TG_ID, Tile_Local_ID} in the packet header. It then queries the neighbor data mapping table to obtain the storage base address of the neighbor space subdomain corresponding to the source address in the second storage area, and directly writes the feedback packet payload into the corresponding absolute address area in the second storage area.

[0113] D. Classification of interconnection network communication switches.

[0114] In one alternative embodiment of this application, the communication path between the current computing cluster and the target computing cluster is determined based on the physical distance between the current computing cluster and the neighboring computing node group.

[0115] Specifically, the communication methods include: (1) Calculate the physical distance between the current computing cluster and the target computing cluster.

[0116] (2) If the physical distance indicates that the current computing cluster and the target computing cluster are adjacent, then request the load data of the required neighboring spatial subdomain through the direct connection port between the current computing cluster and the target computing cluster.

[0117] (3) If the physical distance indicates that the current computing cluster and the target computing cluster are remote, then request the load data of the required neighboring spatial subdomain through the global exchange network.

[0118] For example, the home address {TG_ID, Tile_Local_ID} of each tile has been mapped to physical coordinates using a space-filling curve. The TG physical coordinates are based on... Mapping. Local tile physical coordinates within the TG are determined according to... Mapping. Then the physical coordinates of the global tile are... .

[0119] Define the physical coordinates of the current tile as The physical coordinates of the target tile are Define Chebyshev distance. ,in, , .

[0120] It is used to determine the proximity relationship in orthogonal and diagonal directions, thereby deciding which communication path in the hierarchical routing strategy to use for data exchange.

[0121] Calculate the neighbors within the cluster: If the source tile and the target tile have the same home address, the data is directly obtained from the first storage area of ​​the local tile.

[0122] Calculate the neighbors within the node group: If the source Tile and the target Tile have different Tile_Local_IDs with the same TG_ID, then the request packet and the response packet will not go through routing, but will be forwarded quickly through the local cross-high-speed network within the TG.

[0123] Calculate the neighbors between node groups: If the source tile and the target tile's home addresses point to different TG_IDs, then consider... There are two communication paths.

[0124] like If the source tile and target tile are only one hop apart, indicating they are adjacent, then the request / feedback packet injects the route of the initiating tile, and the route is based on the difference vector. The routing selects a dedicated direct-connect port at the initiating Tile edge for single-hop fast transmission (the receiving end's direct-connect port corresponds to this), bypassing global network switching. The route selects the corresponding physical port based on vector values; for example, when... Select the southeast port of the initiator Tile; The east port is selected at the time, and so on.

[0125] like If the distance from the source tile to the target tile is more than one hop, it means that the source tile and the target tile are in a remote relationship. In this case, the request / feedback packet needs to be transmitted through the global switching network. The XY-dimensional routing algorithm is used for multi-hop routing communication through the chip's global on-chip network switch.

[0126] By using the communication protocol (including communication route selection) and data packet structure defined above, when it is necessary to obtain the load data of the neighboring spatial subdomains, the load data of the neighboring spatial subdomains can be obtained from the corresponding route according to the neighbor type of the neighboring spatial subdomain and stored in the corresponding storage area of ​​the local Tile storage unit. This allows the Tile to quickly obtain the load data of each load's neighboring spatial subdomain with minimal communication overhead after the computation phase starts, reducing communication latency and improving the processing efficiency of scientific computing problems.

[0127] As an optional implementation, after the computation phase begins, the method by which the computing cluster constructs the neighbor list during the computation phase includes: (1) The computing cluster obtains the load data of all spatial subdomains within the computing cluster and divides all loads into each computing core according to the number of computing cores contained therein.

[0128] For example, based on a preset computation granularity, the load data of the spatial subdomain managed by the local tile is divided into several computation task blocks. The computation cluster includes multiple computation cores, assuming the number is... Define the index of the computational core as Then the computing core The load balancing method for the element at index i satisfies the following conditions: .

[0129] (2) Each computing core obtains the load data of the neighbor space subdomain of each load from the storage unit in parallel and loads it into the private L0 cache of each computing core.

[0130] For each assigned load (index i), the computation core determines the three-dimensional indices of its neighboring spatial subdomains based on the three-dimensional index of its own spatial subdomain. Then, it retrieves the description fields of the load data for each neighboring spatial subdomain from the neighbor data mapping table.

[0131] To improve the utilization of on-chip storage units, the compute core adopts a "streaming compute" strategy based on neighbor space subdomains to acquire workload data. The compute core first loads the workload data of the target neighbor space subdomain into the L0 cache in batches from the storage units via the internal bus. For neighbors within the compute cluster, the workload data is directly read from the local first storage area; for neighbors within the compute node group, a cross-tile read request is initiated to the target tile via the high-speed local cross-network within the tile, and the TG hardware automatically routes to the neighbor tile (i.e., the target tile) to quickly read the workload data; for neighbors between compute node groups, the workload data is directly read from the local second storage area.

[0132] (3) Each computing core constructs a neighbor list based on the load data of the neighbor space subdomain in the L0 cache.

[0133] Once the load data of the neighbor space subdomains has been fully loaded from the local first storage area, the neighbor tile's first storage area, and the local second storage area, the computing core can construct the neighbor list.

[0134] For each load it is responsible for, the computing core writes all loads whose distance to its own spatial subdomain and neighboring spatial subdomains (a total of 27 spatial subdomains) is less than the preset cutoff radius (i.e., the unit size for dividing spatial subdomains) into its neighbor list.

[0135] Example 1 For ease of understanding, this application uses the construction of a molecular dynamics neighbor list in a classic liquid water system as a scientific computing problem to introduce the proposed neighborhood node communication method for scientific computing. The implementation process is as follows: Figure 5 As shown.

[0136] S601, Simulation scene initialization.

[0137] The three-dimensional scientific computing space simulation to be solved has a size of 200 Å × 200 Å. The system has a diameter of 200 Å and contains approximately 50,000 water molecules, resulting in a total load of 150,000 atoms. This embodiment selects the Cell Linked List algorithm, commonly used in molecular dynamics, as the basic method for constructing the neighbor list, and establishes the cutoff radius for this algorithm. R cut It is 10 Å. Therefore, the three-dimensional scientific computing space is divided into L x =200Å / 10Å=20,L y =200Å / 10Å=20, L z A cubic mesh of 200Å / 10Å = 20 is formed, resulting in a total of N = 20 × 20 × 20 = 8000 spatial subdomains, each with a side length of... L cell = R cut =10Å. Each spatial subdomain has a unique three-dimensional index.

[0138] S602, hardware resource scheduling of many-core arrays.

[0139] Resource scheduling parameters can be adjusted according to the actual chip specifications. First, assume there are 16 computing cores within a Tile, with each core processing 32 atoms. The required number of Tile is 150000 / (16×32)=292. Then, assume one group of TG consists of 2×2 Tile. The required number of TG is 292 / 4=73. Therefore, the actual TG array that needs to be scheduled is 9×9 (a total of 81 TGs, 324 Tile) as the active execution area for the current computing task.

[0140] S603, Two-level Equalization Mapping.

[0141] First, the spatial subdomain is mapped to the TG. The system counts the number of atoms in each cell as the load weight. W(c) The Hilbert curve filling algorithm is used to transform the three-dimensional indexes of these 8000 cells into a one-dimensional Hilbert sequence (i.e., one-dimensional index) and sort them. The sorted sequence list is then divided into 81 load-balanced segments (i.e., groups) using a weighted interval partitioning method, with each segment mapped to a TG in the TG array. Then, the spatial subdomains within each TG are mapped to tiles. Within each TG, the allocated local spatial subdomain set is again generated and sorted using the Hilbert curve filling algorithm, and divided into four consecutive intervals through secondary load balancing, stored in the first storage area of ​​the four tiles' Scratch Memory. A global mapping table is constructed based on the two-level load balancing mapping. At this point, the global mapping table is complete, containing the home addresses of the 8000 cells in the format {TG_ID, Tile_Local_ID}.

[0142] S604, Neighborhood Communication and Data Exchange.

[0143] Each tile resolves its local spatial subdomain to 26 neighboring spatial subdomains, constructing a neighbor data mapping table. By querying the global mapping table and the neighbor data mapping table, the allo addresses corresponding to all "inter-computing node group neighbors" are filtered out. Each source tile aggregates the cells of those inter-computing node group neighbors into the target tile according to the request packet format. If the target tiles are the same tile, the load data is directly obtained from the first storage area; if the target tiles are in the same TG, the request packet is quickly transmitted via the local cross-connect high-speed network; if the target tiles are in adjacent TGs (… D c =1), the request packet is transmitted quickly via a dedicated direct connection interface; if the distance is long ( D c If >1), then the on-chip network performs XY-dimensional routing. Upon receiving the request packet, the target tile extracts the subdomain ID list according to the request packet format. Subsequently, it accesses the first storage area of ​​its local Scratch Memory via the internal bus. It encapsulates the payload data, such as atom coordinates and atom types, within the subdomain in ascending order of subdomain ID, and sends the encapsulated feedback packet to the source tile (for the request packet) based on the source address tag in the request packet. Upon receiving the returned payload data packet, the source tile continuously writes this payload data according to the base address and offset of the subdomain in the second storage area. At this point, the payload data copy of the remote neighbor's subdomain is ready.

[0144] S605, Neighbor list addressing and calculation.

[0145] Within each tile, 16 compute cores begin parallel distance calculations. When constructing the neighbor list, the compute cores simply retrieve data based on the data pointers and offsets provided by the neighbor data mapping table. For neighbors within a compute cluster, the compute core directly reads the load data from the first storage area via the internal bus. For neighbors within a compute node group, the compute core reads the load data of the neighbor space subdomain from the first storage area of ​​the neighbor within the compute node group via the local cross-connect high-speed network within the tile. For neighbors between compute node groups, the compute core directly reads the load data from the already filled second storage area via the internal bus. Once the load data of the neighbor space subdomain is fully loaded, the 16 compute cores within each tile, operating as independent units, construct the neighbor list in parallel for the local atoms they are responsible for. The neighbor list is defined as: for any atom, storing all atoms whose Euclidean distance is less than the cutoff radius. The set of other atom identifiers. This embodiment uses a fixed-length array and includes neighbor counting. The specific implementation is as follows: a single computational core processes 32 atoms at a time, targeting atom i (three-dimensional coordinates are...). Perform the following operation: Traverse atom j in the load data (atomic data of 27 cells), and its three-dimensional coordinates The core performs the calculation of the squared Euclidean distance between atom i and atom j, using the following formula: + + ; like ， and If the atom j is found to be missing, its identifier is added to the neighbor list of atom i, and its neighbor count is incremented by 1. This process is repeated until all 27 cells are processed, at which point the neighbor list construction for atom i is complete. The computational core then continues processing the next local atom until the neighbor lists for the assigned 32 atoms are completed. Within each tile, the 16 computational cores construct the neighbor lists in parallel, ensuring that every atom in the entire system generates a complete neighbor list.

[0146] Finally, the communication ratio of the method provided in this application was compared with that of traditional general methods, and the results are as follows: Figure 6 As shown.

[0147] In constructing the neighbor list of 150,000 atoms mentioned above, the method in this application demonstrates significant advantages by recording the proportion of communication classification results between neighbor subdomains: (1) In this embodiment, the three-dimensional simulation space of molecular dynamics is mapped to the two-dimensional computing node group in the many-core array architecture based on the space filling curve algorithm, so that 55.29% of the neighbor space subdomain load data interaction is locked within a single TG, and the number of neighbors between computing node groups is reduced by 46% compared with the traditional method.

[0148] (2) This application significantly reduces the dependence of data exchange on the global on-chip network, avoids communication congestion, and improves the overall neighbor list construction speed by more than 2 times. This fully demonstrates the superior efficiency of the "neighborhood node communication method" described in this application in handling spatial local scientific computing.

[0149] Based on the ideas of this application, embodiments of this application also provide a neighborhood node communication device for scientific computing, applied to a many-core processor. The device includes a processor and a storage medium, the storage medium storing a computer program, and the processor running the computer program to execute the neighborhood node communication method for scientific computing according to any of the optional embodiments described above.

[0150] This invention is not limited to the specific embodiments described above. The invention extends to any new feature or combination disclosed in this specification, as well as any new method or process step or combination disclosed herein.

Claims

1. A neighborhood node communication method for scientific computing, applied to many-core processors, characterized in that, include: S1. Divide the three-dimensional scientific computing space to be solved into multiple spatial subdomains, each of which contains at least one load; continuously assign a three-dimensional index to each of the spatial subdomains according to the spatial distribution; S2. The three-dimensional index is mapped to a one-dimensional index using a space-filling curve algorithm; S3. Based on the load balancing principle, continuously map all the spatial subdomains to multiple computing node groups, and continuously map the spatial subdomain subsets within each computing node group to multiple computing clusters. Generate a global mapping table from spatial subdomains to computational clusters; S4. Based on the global mapping table, construct a neighbor data mapping table for each computing cluster, wherein the neighbor data mapping table maps the data addresses of each neighbor spatial subdomain to each spatial subdomain. S5. According to the neighbor data mapping table, obtain the load data of the neighbor space subdomain for each computing cluster, so that the computing cluster can construct a neighbor list for each load according to the neighbor data mapping table during the computing phase.

2. The neighborhood node communication method for scientific computing as described in claim 1, characterized in that, Based on the load balancing principle, all the aforementioned spatial subdomains are continuously mapped to multiple computing node groups, including: S301. Arrange all the spatial subfields in ascending order according to the one-dimensional index; S302. The spatial subdomains are traversed sequentially, and the cumulative load at each traversal position is calculated. The spatial subdomain whose cumulative load is closest to the first average load of all computing node groups is used as the splitting position, and the arranged spatial subdomains are split. This process is repeated until all the arranged spatial subdomains are grouped. S303. The space filling curve algorithm is used to map each spatial subdomain group to each computing node group.

3. The neighborhood node communication method for scientific computing as described in claim 1, characterized in that, Based on the load balancing principle, the spatial subdomain subsets within each computing node group are continuously mapped to multiple computing clusters, including: S304. Arrange all the spatial subdomains in the computing node group in ascending order according to the one-dimensional index; S305. The spatial subdomains are traversed sequentially, and the cumulative load at each traversal position is calculated. The spatial subdomain whose cumulative load is closest to the second average load of all computing clusters is used as the splitting position, and the arranged spatial subdomains are split. This process is repeated until all the arranged spatial subdomains are grouped. S306. Using the space filling curve algorithm, each spatial subdomain is grouped and mapped to each computation cluster.

4. The neighborhood node communication method for scientific computing as described in claim 1, characterized in that, Based on the global mapping table, a neighbor data mapping table is constructed for each computing cluster, including: S401. For each of the aforementioned spatial subdomains, determine the one-dimensional index of all neighboring spatial subdomains; S402. Based on querying each of the one-dimensional indexes in the global mapping table, obtain the neighbor type of each neighbor space subdomain; the neighbor type is divided into three categories: neighbors within a computing cluster, neighbors within a computing node group, and neighbors between computing node groups. S403. In each computing cluster's storage unit, a first storage area and a second storage area are respectively opened. The first storage area stores all load data within the computing cluster, and the second storage area stores copies of the load data of neighbors between computing node groups. S404. Construct a neighbor data mapping table for each computing cluster. The neighbor data mapping table maps the data addresses of each neighbor spatial subdomain to each spatial subdomain. Specifically, the data addresses of neighbors within a computing cluster are mapped to the first storage area, the data addresses of neighbors within a computing node are mapped to the first storage area of ​​the corresponding neighbor computing cluster within the same computing node group, and the data addresses of neighbors between computing node groups are mapped to the corresponding positions in the second storage area.

5. The neighborhood node communication method for scientific computing as described in claim 4, characterized in that, Based on the neighbor data mapping table, load data for each computing cluster's neighbor spatial subdomain is obtained, including: S501. Traverse the neighbor data mapping table, filter out the neighbor space subdomains whose neighbor type is inter-computation node group neighbor, and determine the target computing cluster corresponding to each of the filtered neighbor space subdomains according to the global mapping table. S502, request the required load data of the neighbor space subdomain from each target computing cluster; according to the neighbor data mapping table, write the requested load data to the corresponding position in the second storage area.

6. The neighborhood node communication method for scientific computing as described in claim 5, characterized in that, Request the required load data for the neighboring spatial subdomains from each target computing cluster, including: The subdomain identifiers of all neighboring spatial subdomains mapped to the same target computing cluster are loaded into the same data request to simultaneously request the load data of all required neighboring spatial subdomains from the same target computing cluster.

7. The neighborhood node communication method for scientific computing as described in claim 5 or 6, characterized in that, Methods for requesting load data from the target computing cluster for the required neighboring spatial subdomains include: Calculate the physical distance from the current computing cluster to the target computing cluster; If the physical distance indicates that the current computing cluster and the target computing cluster are adjacent, then the load data of the required neighboring spatial subdomain is requested through the direct connection port between the current computing cluster and the target computing cluster; If the physical distance indicates that the current computing cluster and the target computing cluster are in a remote relationship, then the load data of the required neighboring spatial subdomain is requested through the global exchange network.

8. The neighborhood node communication method for scientific computing as described in claim 4, characterized in that, Based on the neighbor data mapping table, a neighbor list is constructed for each load, including: Based on the neighbor data mapping table, load data of the neighbor space subdomain is obtained from the storage unit for each load; wherein: For a neighbor space subdomain whose neighbor type is compute cluster neighbor, read the load data of the neighbor space subdomain from the first storage area; For a neighbor space subdomain whose neighbor type is a neighbor within a compute node group, the load data of the neighbor space subdomain is read from the first storage area of ​​the neighbor within the compute node group through the local cross-high-speed network within the compute cluster. For a neighbor space subdomain whose neighbor type is compute node group neighbor, read the load data of the neighbor space subdomain from the corresponding location in the second storage area; The neighbor list is constructed based on the load data of the neighbor space subdomains obtained from the storage unit.

9. The neighborhood node communication method for scientific computing as described in claim 8, characterized in that, The method by which the computing cluster constructs the neighbor list during the computing phase includes: The computing cluster acquires the load data of all spatial subdomains within the computing cluster, and divides all the load into each computing core according to the number of computing cores contained therein. Each computing core obtains the load data of the neighbor space subdomain of each load in parallel from the storage unit and loads it into the private L0 cache of each computing core. Each computing core constructs the neighbor list based on the load data of the neighbor space subdomain in the L0 cache.

10. A neighborhood node communication device for scientific computing, applied to many-core processors, characterized in that, It includes a processor and a storage medium, the storage medium storing a computer program, the processor running the computer program to perform the neighborhood node communication method for scientific computing as described in any one of claims 1-9.

Images