Full-electronic DFPT simulation optimization acceleration method and device

Abstract

A full-electronic DFPT simulation optimization acceleration method is used for a full-electronic DFPT simulation calculation task, the simulation calculation task is divided into multiple batches of subtasks, and the method comprises the steps that through a batch processing merging strategy, the multiple independent subtasks are merged into batch tasks enabling GPU thread blocks to be fully loaded, so that the GPU thread utilization rate is increased; for the merged batch tasks, atomic or grid point attributes are uniformly stored in a structured memory allocation mode, and a lock page memory pool is pre-allocated to multiplex a transmission buffer area, so that the memory access efficiency is improved, and memory fragmentization is reduced; and constructing a calculation-transmission assembly line based on a multi-stream assembly line mechanism, and performing overlapped execution of calculation of the merged batch tasks and data transmission of the next batch by using a lock page memory buffer area. According to the method, the thread-level parallel efficiency of the GPU can be improved, the memory layout and multiplexing are optimized, the data transmission waiting time is shortened, and the performance of DFPT simulation under the high-throughput condition is improved.

Description

Technical Field

[0001] The present invention relates to the field of high performance computing technology, and in particular to an all-electronic DFPT simulation optimization acceleration method and device. Background Art

[0002] Density functional perturbation theory (DFPT) is an important method for studying the response properties of materials and molecules. All-electronic DFPT simulations require processing a large number of complex calculations, such as the real-space integral of the response density, the Poisson solution of the electrostatic potential, and the assembly of the response Hamiltonian matrix. These calculations are very time-consuming. In order to accelerate DFPT simulations, general GPU acceleration solutions have been introduced into some known technologies. For example, existing literature has implemented the main computational stages of all-electronic DFPT on a GPU using the open computing language (OpenCL), fully utilizing the parallel computing capabilities of the GPU and achieving certain acceleration effects in a heterogeneous computing environment. However, existing OpenCL-DFPT implementations still have many shortcomings, such as low GPU resource utilization and poor GPU memory reuse efficiency. Summary of the Invention

[0003] In order to solve the problems existing in the prior art, the embodiments of the present application provide a method, apparatus, computing device, computer storage medium and product containing a computer program for optimizing and accelerating all-electronic DFPT simulation, which can improve the thread-level parallel efficiency of the GPU, optimize memory layout and reuse, and reduce data transmission waiting time, thereby improving the performance of DFPT simulation in high-throughput situations.

[0004] In the first aspect, an embodiment of the present application provides an all-electronic DFPT simulation optimization acceleration method for an all-electronic DFPT simulation computing task, wherein the simulation computing task is divided into multiple batches of sub-tasks, and the method includes: through a batch merging strategy, merging multiple independent sub-tasks into a batch task that fully loads the GPU thread block to improve the GPU thread utilization; for the merged batch tasks, using a structured memory allocation method to uniformly store atomic or grid point attributes, pre-allocating a page-locked memory pool to reuse the transmission buffer to improve memory access efficiency and reduce memory fragmentation; constructing a calculation-transmission pipeline based on a multi-stream pipeline mechanism, and using a page-locked memory buffer to perform overlapping execution of the calculation of the merged batch tasks and the transmission of the next batch of data.

[0005] In some possible implementations, the batch merging strategy includes: dynamically monitoring the thread capacity of the GPU thread block, merging discrete atomic perturbations or grid integration subtasks into batch tasks that are an integer multiple of the thread capacity according to the thread block capacity threshold, and after the merger, the proportion of active threads in each thread block is not less than 80%.

[0006] In some possible implementations, the structured memory allocation method includes: storing atomic coordinates, potential energy fields, and charge density properties in independent continuous video memory arrays to form a structured array layout, and the storage offset of each array is strictly aligned to the GPU memory access granularity according to the atom / grid index.

[0007] In some possible implementations, the pre-allocated page-locked memory pool reuse transmission buffer includes: pre-allocating a continuous page-locked memory as a memory pool during the initialization phase, and managing the data buffer required by each computing module with a fixed offset in the memory pool to avoid frequent dynamic allocation and release; data exchange between the host and the GPU uses the buffer in the page-locked memory pool, reducing the overhead of the operating system repeatedly locking / unlocking memory pages and reducing the startup overhead of data transmission.

[0008] In some possible implementations, the multi-stream pipeline mechanism includes: using at least two GPU computing streams and corresponding two sets of data buffers, the first computing stream is used to perform the calculation of the current batch of tasks, and the second computing stream is used to transmit data of the next batch of tasks in parallel; when the calculation of the current batch of tasks is completed, the calculation of the next batch of tasks is started on the second computing stream, and the results are asynchronously returned through the first computing stream to form a pipeline operation.

[0009] In the second aspect, an embodiment of the present application provides an all-electronic DFPT simulation optimization acceleration device, which is deployed on a computing device, and the computing device is used for all-electronic DFPT simulation computing tasks, and the simulation computing tasks are divided into multiple batches of sub-tasks. The device includes: a merging module, which is used to merge multiple independent sub-tasks into batch tasks that fully load the GPU thread block through a batch merging strategy to improve GPU thread utilization; an allocation module, which is used to uniformly store atomic or grid point attributes for the merged batch tasks using a structured memory allocation method, and pre-allocate a page-locked memory pool to reuse the transmission buffer to improve memory access efficiency and reduce memory fragmentation; a transmission module, which is used to construct a calculation-transmission pipeline based on a multi-stream pipeline mechanism, and use the page-locked memory buffer to perform overlapping execution of the calculation of the merged batch tasks and the transmission of the next batch of data.

[0010] In some possible implementations, the batch merging strategy includes: dynamically monitoring the thread capacity of the GPU thread block, merging discrete atomic perturbations or grid integration subtasks into batch tasks that are an integer multiple of the thread capacity according to the thread block capacity threshold, and after the merger, the proportion of active threads in each thread block is not less than 80%.

[0011] In some possible implementations, the structured memory allocation method includes: storing atomic coordinates, potential energy fields, and charge density properties in independent continuous video memory arrays to form a structured array layout, and the storage offset of each array is strictly aligned to the GPU memory access granularity according to the atom / grid index.

[0012] In some possible implementations, the pre-allocated page-locked memory pool reuse transmission buffer includes: pre-allocating a continuous page-locked memory as a memory pool during the initialization phase, and managing the data buffer required by each computing module with a fixed offset in the memory pool to avoid frequent dynamic allocation and release; data exchange between the host and the GPU uses the buffer in the page-locked memory pool, reducing the overhead of the operating system repeatedly locking / unlocking memory pages and reducing the startup overhead of data transmission.

[0013] In some possible implementations, the multi-stream pipeline mechanism includes: using at least two GPU computing streams and corresponding two sets of data buffers, the first computing stream is used to perform the calculation of the current batch of tasks, and the second computing stream is used to transmit data of the next batch of tasks in parallel; when the calculation of the current batch of tasks is completed, the calculation of the next batch of tasks is started on the second computing stream, and the results are asynchronously returned through the first computing stream to form a pipeline operation.

[0014] In a third aspect, an embodiment of the present application provides a computer-readable storage medium comprising computer-readable instructions. When a computer reads and executes the computer-readable instructions, the computer executes the method as described in any one of the first aspects.

[0015] In a fourth aspect, an embodiment of the present application provides a computing device comprising a processor and a memory, wherein the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the method as described in any one of the first aspects is executed.

[0016] In a fifth aspect, an embodiment of the present application provides a product comprising a computer program, which, when the computer program product runs on a processor, enables the processor to execute the method as described in any one of the first aspects. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] 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.

[0018] Figure 1 1 is a flow chart of an all-electronic DFPT simulation optimization acceleration method provided in an embodiment of the present application;

[0019] Figure 2 This is a schematic diagram comparing GPU usage before and after adopting a batch merging strategy, provided in an embodiment of the present application;

[0020] Figure 3 This is a schematic diagram comparing access efficiency before and after memory management optimization provided by an embodiment of the present application;

[0021] Figure 4 This is a schematic diagram of the time difference before and after a pipeline parallel mechanism provided by an embodiment of the present application;

[0022] Figure 5 This is a structural diagram of an all-electronic DFPT simulation optimization acceleration device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0024] The term "and / or" as used herein describes an association between related objects, indicating that three possible relationships exist. For example, "A and / or B" can represent: A exists alone, A and B exist simultaneously, or B exists alone. The symbol " / " as used herein indicates that the related objects are in an "or" relationship, for example, A / B means either A or B.

[0025] The terms "first" and "second" in this specification and claims are used to distinguish different objects rather than to describe a specific order of objects. For example, "first response message" and "second response message" are used to distinguish different response messages rather than to describe a specific order of response messages.

[0026] In the embodiments of this application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of this application should not be interpreted as being preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0027] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more, for example, multiple processing units means two or more processing units, etc.; multiple elements means two or more elements, etc.

[0028] To facilitate understanding of the embodiments of the present application, further explanation will be given below with reference to specific embodiments in conjunction with the accompanying drawings. The embodiments do not constitute a limitation on the embodiments of the present invention.

[0029] First, the technical terms involved in the embodiments of this application are introduced:

[0030] 1. Open Computing Language (OpenCL) is an open, royalty-free standard designed to provide a unified programming interface for heterogeneous computing platforms (such as CPUs, GPUs, DSPs, FPGAs, etc.) for cross-platform parallel programming of various accelerators in supercomputers, cloud servers, personal computers, mobile devices, and embedded platforms.

[0031] 2. The heterogeneous-compute interface for portability (HIP) is a GPU computing platform designed to provide better cross-hardware compatibility.

[0032] Next, the technical solutions provided in the embodiments of the present application are introduced.

[0033] In existing OpenCL-DFPT implementations, due to limitations in task partitioning granularity and scheduling, many computing kernels can only launch relatively small thread blocks, or only a subset of threads within each thread block actually perform effective computations. This results in significant GPU hardware idleness and low overall GPU utilization. In other words, when a large number of "small batches" of tasks are executed in a distributed manner, thread block utilization is insufficient, and the GPU's parallel computing potential is not fully tapped. Furthermore, existing technologies lack optimal memory management, often employing fragmented memory allocation and object array data layout. On the one hand, frequent memory allocation and deallocation lead to memory fragmentation, impacting memory utilization. On the other hand, data is stored in complex object arrays (each object contains multiple attributes), preventing the GPU from accessing the required data continuously. This results in high memory access overhead and low cache hit rates. Furthermore, when exchanging data between the CPU and GPU, there is a lack of efficient memory mechanisms to accelerate transmission, such as underutilization of techniques like pinned memory, further limiting data transfer efficiency. Furthermore, the communication overhead associated with data transfer and computation is high. By default, OpenCL uses a single instruction stream to sequentially execute computations and data copies. The GPU is idle while waiting for data transfers or communicating with the host, preventing computation and communication from proceeding in parallel. This means the GPU computation phase and the CPU-GPU data transfer phase proceed in series, and communication latency directly increases overall execution time. When DFPT simulations involve repeated host-device data exchanges (e.g., multiple iterations or multiple submodules in series), communication and data transfer time becomes a performance bottleneck, limiting simulation throughput.

[0034] In view of this, the embodiment of the present application provides an all-electronic DFPT simulation optimization acceleration method. The DFPT simulation in this method is based on the HIP model. Although OpenCL has good code portability, compared with programming models such as HIP and CUDA, OpenCL lacks support for various optimization algorithm libraries and computing libraries. Therefore, the embodiment of the present application adopts the HIP model for DFPT simulation. HIP is a heterogeneous programming model, and its biggest feature is that it has good portability between acceleration hardware on different platforms. When programming using HIP, the same set of source code can run on both AMD GPUs and NVIDIA GPUs. The software stack of domestic accelerator cards has further developed HIP so that HIP can run successfully on accelerator cards. HIP is the most important programming model on accelerator cards, and the API interface of HIP is very similar to the API interface of CUDA. The HIP library in the accelerator card covers many aspects such as linear algebra, fast Fourier transform, convolution, pooling, communication, algorithms, etc., and is optimized for accelerator cards. In this method, a batch merging strategy is designed to merge multiple small batches of tasks into a large batch for execution. A unified structured memory allocation method and page-locked memory reuse improve memory access efficiency and reduce fragmentation. A multi-stream pipeline mechanism, double buffering, and non-blocking data transfers hide communication latency, enabling overlapping execution of communication, computation, and data handling.

[0035] For example, Figure 1 The figure shows a flow chart of an all-electronic DFPT simulation optimization acceleration method provided by an embodiment of the present application. The method is applied to an all-electronic DFPT simulation calculation task, and the simulation task is divided into multiple batches of subtasks. Figure 1 As shown, the method may include the following steps:

[0036] S11: Through the batch merging strategy, multiple independent small batch computing tasks are merged into large batch tasks that fully load the GPU thread block, thereby improving the GPU thread utilization.

[0037] In this embodiment, multiple small batch tasks are merged into a large batch for execution to improve the utilization of a single thread block and significantly improve the resource occupancy of the GPU. By packaging the originally scattered small workloads, each thread block on the GPU can take on more parallel computing tasks to avoid idle threads. The batch merging strategy is to dynamically monitor the thread capacity of the GPU thread block, and merge the discrete atomic perturbations or grid integration subtasks into batch tasks that are integer multiples of the thread capacity according to the thread block capacity threshold. After merging, the proportion of active threads in each thread block is not less than 80%. For example, if the thread block capacity is 256 threads, the total task volume after merging should be 256×N, where N is a positive integer. For example, if the original task consists of 4 subtasks, 64 threads per task can be merged into 64×4=256 threads. This strategy effectively solves the problem of low GPU utilization caused by too small task granularity in the prior art.

[0038] Specifically, during the computational process of the all-electronic DFPT simulation, the computational tasks can be divided into batches for processing. For example, when performing integral calculations on a large number of grid points, the grid points can be divided into multiple small batches and processed by different GPU thread blocks. If each batch contains too few work units (for example, each batch only corresponds to dozens of threads), most of the threads in the thread block are idle, and the parallel computing capabilities of the GPU cannot be fully utilized. For example, please refer to Figure 2 , Figure 2 FIG2 shows a comparison diagram of GPU usage before and after adopting the batch merging strategy provided by the embodiment of the present application. Figure 2 As shown, before the batch merging strategy is adopted, on CU1, only 50 threads are used, and the other threads are idle. On CU64, 93 threads are used, and the other threads are idle. This wastes the parallel computing capability of the GPU. To this end, this embodiment merges several small batches into one large batch, that is, packages and combines several originally independent small batch tasks, and processes them together in a single GPU kernel call. The merging strategy can determine the size of the merged batch based on the optimal thread block size of the GPU architecture (for example, 256 threads), and fill the number of threads of a thread block as much as possible. In the specific implementation, the host program traverses the list of small batch tasks to be calculated, and merges consecutive small batches according to certain rules. For example, it is determined whether the cumulative task volume of several small batches does not exceed the upper limit that a single thread block can carry. If so, they are merged into one large batch. The merged large batch tasks are executed by a GPU thread block, and the thread index offset is used in the kernel to distinguish the data range originally belonging to different small batches. In this way, all threads within each GPU thread block participate in the calculation, and each thread collaborates in parallel to complete the processing of a larger data set. Please continue to refer to Figure 2After adopting the batch merging strategy, the thread occupancy of CU1 can reach 249, and the thread occupancy of CU64 can reach 206. Compared with the traditional method of scheduling one by one in small batches, the strategy of merging small batches reduces the number of GPU kernel launches and scheduling overhead, and improves the parallel granularity of calculations. More importantly, the proportion of active threads in a single thread block is significantly improved, and the GPU multi-processor resources are fully utilized. For example, if only 50% of the threads in each thread block were originally performing calculations, batch merging can reach more than 80%, or even close to 100% thread participation, thereby significantly improving the GPU hardware occupancy rate. This strategy effectively avoids the idleness of GPU computing units and improves overall computing efficiency.

[0039] S12: For the merged batch tasks, a structured memory allocation method is used to uniformly store the atomic or grid point attributes, and a pre-allocated page-locked memory pool is used to reuse the transmission buffer to improve memory access efficiency and reduce memory fragmentation.

[0040] In this embodiment, GPU memory management optimization is implemented to improve memory access efficiency and reduce fragmentation through a unified structured memory allocation method and page-locked memory reuse. Specifically, the structured memory allocation method includes storing attributes that need to be frequently accessed, such as atomic coordinates, potential energy field, and charge density, in independent continuous video memory arrays to form a structured array layout, and the storage offset of each array is strictly aligned to the GPU memory access granularity according to the atom / grid index. A structured array data layout is used to replace the traditional object array, and data that needs to be frequently accessed is compactly stored in a continuous memory area, ensuring that the GPU thread can perform coherent (coal esced) memory access. At the same time, a reusable page-locked memory buffer is used when the host and the GPU interact to reduce the overhead caused by repeated allocation / release. This memory optimization method improves data reusability and solves the low efficiency problem caused by fragmented memory allocation and discontinuous access in the prior art.

[0041] Specifically, the GPU memory management optimization provided by this embodiment includes structured memory layout and page-locked memory reuse. For example, Figure 3 The following diagram shows the access efficiency comparison before and after memory management optimization. Figure 3In terms of data layout, the traditional array of structures (AoS) approach is replaced with structured arrays (SoA) for data storage. For example, for atomic or grid point data in DFPT simulations, traditional object arrays might create a structure containing multiple attributes (coordinates, density values, potential energy, etc.) for each grid point and store them in an array format. However, with this layout, when threads access data for the same attribute, the data is scattered across different objects and cannot be read sequentially, resulting in discontinuous memory access and low GPU global memory bandwidth utilization. With the structured array layout, each attribute is stored in a contiguous array, with each array subscript corresponding to a grid point. This allows GPU threads to read data from consecutive memory addresses (for example, the density values ​​of all grid points) in batches, resulting in coalesced accesses and significantly reducing the number of memory transactions and latency. This optimization also reduces cache misses and improves memory access throughput. When multiple threads read data from adjacent addresses in parallel, memory access coalescing (coal escencing) is achieved, fully leveraging the GPU's high-bandwidth memory. Secondly, in terms of memory allocation and transmission, a unified memory pool and page-locked memory reuse strategy are adopted. To address the recurring memory request / release operations in the DFPT simulation process, this embodiment pre-allocates a sufficiently large contiguous memory block as a memory pool during the initialization phase to store the various data structures required throughout the simulation process. The data buffers required by each module are managed with fixed offsets in the memory pool, which avoids frequent dynamic allocation and release, reducing memory fragmentation. At the same time, for data exchange between the host and the device, the present invention preferably uses page-locked memory to improve transmission efficiency. Specifically, a fixed-size page-locked memory buffer is requested on the host side and repeatedly used for data transmission throughout the simulation process, rather than creating and destroying a buffer for each transmission. Because this page-locked memory is fixed in physical memory, it reduces latency when the GPU performs direct DMA transmission. By reusing the same page-locked memory, the operating system does not need to repeatedly lock and unlock memory pages, and the startup overhead of data transmission is also reduced. Combining the above measures, the GPU memory management optimization solution ensures efficient data flow between the CPU and GPU, as well as within the GPU. On the one hand, it reduces memory fragmentation and unnecessary allocation and release time, and on the other hand, it improves data access continuity and transmission bandwidth, providing a stable and efficient data support environment for subsequent calculations.

[0042] S13: Build a computation-transmission pipeline based on a multi-stream pipeline mechanism, and use a page-locked memory buffer to overlap the computation of the merged batch tasks with the next batch of data transmission to hide the data transmission delay.

[0043] In this embodiment, a multi-stream pipeline mechanism is designed to hide communication delays through double buffering and non-blocking data transmission, thereby realizing overlapping execution of communication, calculation, and data handling. The multi-stream parallel execution capability provided by HIP is utilized to create multiple computing streams (streams) on the GPU, so that while one batch of data is being calculated on the GPU, another batch of data is being transmitted asynchronously. Specifically, a double buffering strategy is adopted: two sets of data buffers are used alternately to pre-fetch the next batch of data and return the results of the previous batch while the current batch of data is being calculated. Since data transmission adopts a non-blocking method, the CPU can initiate GPU calculations without waiting for the transmission to be completed, thereby transforming the original serial "transmission-computation" process into a parallel pipeline. This design greatly reduces the apparent time consumption of communication and data handling, and solves the bottleneck problem of GPU waiting for data transmission under the existing OpenCL sequential execution.

[0044] Specifically, to maximize the efficiency of the GPU and CPU working together, the present invention builds a multi-stream pipeline parallel execution mechanism, which enables data transmission and calculation to overlap and hide communication delays. Its core is to use multiple execution streams (streams) on the GPU side to manage the transmission and calculation of different batches of tasks, realizing "double buffering" alternating operations. For example, Figure 4 Schematic diagram showing the time difference before and after a pipeline parallel mechanism provided by an embodiment of the present application. Figure 4Assume that two GPU computation streams, Stream1 and Stream2, and two corresponding data buffers (Buffer A and Buffer B), serve as double buffering. In the first time step, the host transfers the first batch of data to the GPU's Buffer A using an asynchronous memory copy (e.g., a non-blocking call like hipMemcpyAsync), and then launches the computation kernel for that batch on Stream1. Simultaneously, while the GPU is processing the first batch, the host can concurrently transfer the second batch of data to the backup Buffer B (using Stream2 to perform the data copy). Because page-locked memory and asynchronous calls are used, the second batch of data can begin without blocking the CPU until the GPU completes the first batch of computations. Once the first batch of computations completes, the GPU immediately launches the second batch of data computation kernels on Stream2. Simultaneously, the host asynchronously copies the first batch of computation results from the GPU back to the host via Stream1. This cycle repeats until the third batch is transferred and computed using Buffer A in Stream1, while the second batch of results are returned via Stream2. The entire process forms a pipeline: at any given moment, the GPU is either computing the current batch of data, concurrently transmitting the next batch, or simultaneously returning results, thus achieving maximum overlap between computation and data transfer. This multi-stream pipeline design significantly reduces the time the GPU spends waiting for data. Compared to the traditional serial process (transfer, then compute, then transmit the results), the method of the present invention enables data transfer and computation to proceed essentially simultaneously, minimizing GPU idle time. Especially in high-throughput scenarios such as DFPT simulations that require processing multiple perturbations or multiple frames of data, the pipeline ensures that the GPU is always busy: either computing or sending and receiving data. Communication latency is hidden within the computational process, significantly reducing its impact on overall runtime. For example, without pipeline optimization, the GPU must wait in vain for the next batch of data to complete after completing each computation. However, with the multi-stream asynchronous mechanism of the present invention, the next batch of data is already in the GPU memory when the GPU completes one computation, allowing immediate computation. This seamless integration improves batch processing throughput and makes the transitions between the various stages of the DFPT simulation more compact and efficient.

[0045] The above is an introduction to the all-electronic DFPT simulation optimization acceleration method provided in the embodiment of the present application. Through the collaborative optimization of batch merging, memory management optimization and multi-stream pipeline, the execution efficiency of the all-electronic DFPT high-throughput simulation on the GPU is greatly improved. This method can increase the average GPU occupancy by about 55%, the simulation throughput by about 70%, and the acceleration ratio of the main computing sub-modules (such as response density integral, Poisson solution, Hamiltonian matrix calculation, etc.) reaches 1.6-2.5 times. Not only that, this method effectively eliminates the phenomenon of GPU idleness and memory waste, so that the DFPT high-throughput simulation can make full use of the GPU parallel performance to achieve faster computing response and higher resource utilization.

[0046] It is understandable that the size of the sequence number of each step in the above-mentioned embodiments does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. In addition, in some possible implementations, the steps in the above-mentioned embodiments can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here. All or part of any features of any embodiment of the present application can be freely and arbitrarily combined without contradiction. The combined technical solution is also within the scope of the present application.

[0047] Based on the method in the above embodiment, the embodiment of the present application also provides an all-electronic DFPT simulation optimization acceleration device. For example, Figure 5 The schematic diagram of the structure of the all-electronic DFPT simulation optimization acceleration device of the embodiment of the present application is shown. The device is deployed on a computing device, and the computing device is used for all-electronic DFPT simulation calculation tasks. The simulation calculation tasks are divided into multiple batches of subtasks. Figure 5 As shown, the apparatus 500 includes a merging module 501 , an allocating module 502 , and a transmitting module 503 .

[0048] The merging module 501 is used to merge multiple independent subtasks into a batch task that fully loads the GPU thread block through a batch merging strategy, so as to improve the GPU thread utilization.

[0049] The allocation module 502 is used to uniformly store the atomic or grid point attributes of the merged batch tasks using a structured memory allocation method, and pre-allocate a page-locked memory pool to reuse the transmission buffer to improve memory access efficiency and reduce memory fragmentation.

[0050] The transmission module 503 is used to build a calculation-transmission pipeline based on a multi-stream pipeline mechanism, and use a page-locked memory buffer to overlap the calculation of the merged batch tasks with the transmission of the next batch of data.

[0051] In some possible embodiments, the batch merging strategy includes: dynamically monitoring the thread capacity of the GPU thread block, merging discrete atomic perturbations or grid integration subtasks into batch tasks that are an integer multiple of the thread capacity according to the thread block capacity threshold, and after the merger, the proportion of active threads in each thread block is not less than 80%.

[0052] In some possible embodiments, the structured memory allocation method includes: storing atomic coordinates, potential energy fields, and charge density properties in independent continuous video memory arrays to form a structured array layout, and the storage offset of each array is strictly aligned to the GPU memory access granularity according to the atom / grid index.

[0053] In some possible embodiments, pre-allocating a page-locked memory pool for reuse of a transmission buffer includes: pre-allocating a block of continuous page-locked memory as a memory pool during the initialization phase, and managing the data buffer required by each computing module in the memory pool with a fixed offset to avoid frequent dynamic allocation and release; using the buffer in the page-locked memory pool for data exchange between the host and the GPU, reducing the overhead of the operating system repeatedly locking / unlocking memory pages and reducing the startup overhead of data transmission.

[0054] In some possible embodiments, the multi-stream pipeline mechanism includes: using at least two GPU computing streams and corresponding two sets of data buffers, the first computing stream is used to perform the calculation of the current batch of tasks, and the second computing stream is used to transmit data of the next batch of tasks in parallel; when the calculation of the current batch of tasks is completed, the calculation of the next batch of tasks is started on the second computing stream, and the results are asynchronously returned through the first computing stream to form a pipeline operation.

[0055] Based on the methods in the above embodiments, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the methods in the above embodiments.

[0056] Based on the methods in the above embodiments, an embodiment of the present application provides a computer program product. When the computer program product runs on a processor, the processor executes the methods in the above embodiments.

[0057] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0058] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0059] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0060] It will be understood that the various numerical numbers involved in the embodiments of the present application are merely distinctions for the convenience of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. An all-electronic DFPT simulation optimization acceleration method, characterized in that: The method is used for an all-electronic DFPT simulation calculation task, where the simulation calculation task is divided into multiple batches of subtasks. The method includes: Through the batch merging strategy, multiple independent subtasks are merged into batch tasks that fully load the GPU thread block to improve GPU thread utilization; For merged batch tasks, a structured memory allocation method is used to uniformly store atomic or grid point attributes, and a pre-allocated page-locked memory pool is used to reuse the transmission buffer to improve memory access efficiency and reduce memory fragmentation. A computation-transmission pipeline is constructed based on a multi-stream pipeline mechanism, and a page-locked memory buffer is used to overlap the computation of the merged batch tasks with the data transmission of the next batch.

2. The method according to claim 1, characterized in that The batch merging strategy includes: Dynamically monitor the thread capacity of GPU thread blocks, merge discrete atomic perturbations or grid integration subtasks into batch tasks that are integer multiples of the thread capacity according to the thread block capacity threshold, and ensure that the proportion of active threads in each thread block after merging is not less than 80%.

3. The method according to claim 1, characterized in that The structured memory allocation method includes: The atomic coordinates, potential energy field, and charge density properties are stored in separate continuous memory arrays to form a structured array layout, and the storage offset of each array is strictly aligned to the GPU memory access granularity according to the atom / grid index.

4. The method according to claim 1, wherein The pre-allocated page lock memory pool multiplexing transmission buffer includes: During the initialization phase, a continuous block of locked-page memory is pre-allocated as a memory pool. The data buffers required by each computing module are managed at fixed offsets in the memory pool to avoid frequent dynamic allocation and deallocation. Data exchange between the host and GPU uses buffers in the page-locked memory pool, reducing the operating system's overhead of repeatedly locking / unlocking memory pages and lowering the startup overhead of data transfer.

5. The method according to claim 1, wherein The multi-stream pipeline mechanism includes: Using at least two GPU computing streams and corresponding two sets of data buffers, the first computing stream is used to perform the calculations of the current batch of tasks, and the second computing stream is used to transmit data of the next batch of tasks in parallel; When the calculation of the current batch of tasks is completed, the calculation of the next batch of tasks is started on the second calculation flow, and the results are asynchronously returned through the first calculation flow to form a pipeline operation.

6. An all-electronic DFPT simulation optimization accelerator, characterized in that: The apparatus is deployed on a computing device used for full electronic DFPT simulation computing tasks, where the simulation computing tasks are divided into multiple batches of subtasks. The apparatus includes: The merging module is used to merge multiple independent subtasks into batch tasks that fully load the GPU thread block through a batch merging strategy to improve GPU thread utilization; The allocation module is used to uniformly store atomic or grid point attributes for merged batch tasks using a structured memory allocation method, and to pre-allocate a page-locked memory pool to reuse the transmission buffer to improve memory access efficiency and reduce memory fragmentation; The transmission module is used to build a computing-transmission pipeline based on the multi-stream pipeline mechanism, and uses the page-locked memory buffer to overlap the calculation of the merged batch tasks with the transmission of the next batch of data.

7. The device according to claim 6, characterized in that The batch merging strategy includes: Dynamically monitor the thread capacity of GPU thread blocks, merge discrete atomic perturbations or grid integration subtasks into batch tasks that are integer multiples of the thread capacity according to the thread block capacity threshold, and ensure that the proportion of active threads in each thread block after merging is not less than 80%.

8. The device according to claim 6, characterized in that The structured memory allocation method includes: The atomic coordinates, potential energy field, and charge density properties are stored in separate continuous memory arrays to form a structured array layout, and the storage offset of each array is strictly aligned to the GPU memory access granularity according to the atom / grid index.

9. The device according to claim 6, characterized in that The pre-allocated page lock memory pool multiplexing transmission buffer includes: During the initialization phase, a continuous block of locked-page memory is pre-allocated as a memory pool. The data buffers required by each computing module are managed at fixed offsets in the memory pool to avoid frequent dynamic allocation and deallocation. Data exchange between the host and GPU uses buffers in the page-locked memory pool, reducing the operating system's overhead of repeatedly locking / unlocking memory pages and lowering the startup overhead of data transfer.

10. The device according to claim 6, characterized in that The multi-stream pipeline mechanism includes: Using at least two GPU computing streams and corresponding two sets of data buffers, the first computing stream is used to perform the calculations of the current batch of tasks, and the second computing stream is used to transmit data of the next batch of tasks in parallel; When the calculation of the current batch of tasks is completed, the calculation of the next batch of tasks is started on the second calculation flow, and the results are asynchronously returned through the first calculation flow to form a pipeline operation.

Images