Methods, apparatus, storage media, and computing devices for testing parallel computing performance

Abstract

This application provides a method, apparatus, storage medium, and computing device for detecting parallel computing performance. The method includes: obtaining a parameter configuration file for a computing job; loading a target script template matching the parameter configuration file from batch processing script templates corresponding to various parallel computing cluster types, and instantiating the target script template using the parameter configuration file to obtain an instantiated script; scheduling the parallel computing program indicated by the parameter configuration file and the computing resources in the parallel computing cluster to execute the computing job through the instantiated script, and collecting initial performance monitoring data during the job execution process; the initial performance monitoring data includes at least the job execution status and cluster resource usage; and generating a performance detection result of the parallel computing program under the parallel computing cluster based on the initial performance monitoring data.

Description

Technical Field

[0001] This application relates to the field of high-performance computing technology, and more specifically, to a method, apparatus, storage medium, and computing device for detecting parallel computing performance. Background Technology

[0002] With the rapid development of scientific computing, engineering simulation, and big data analytics, the scale of computing jobs is increasing, which not only increases the demand for computing power but also places higher demands on the efficient utilization of computing resources. Parallel computer systems, such as intelligent computing clusters and supercomputing platforms, have gradually become key facilities for handling large-scale computing jobs due to their powerful high-performance computing (HPC) capabilities. Currently, to manage the scheduling and allocation of computing resources for large-scale computing jobs on parallel computer systems, job scheduling systems such as Simple Linux Utility for Resource Management (Slurm) and Portable Batch Systems (PBS) are commonly used.

[0003] However, existing job scheduling systems primarily focus on queuing, scheduling, and basic lifecycle management of computational jobs (such as job submission time, start time, and end time), failing to evaluate the performance metrics of parallel computing programs executed by the parallel computer system during job execution. Therefore, manual methods are currently often used to evaluate and optimize the performance of parallel computing programs, but this approach suffers from inefficiency and a high error rate, exhibiting significant drawbacks. Summary of the Invention

[0004] In view of this, this application provides a method, apparatus, storage medium, and computing device for detecting parallel computing performance, so as to significantly improve the efficiency and accuracy of parallel computing performance detection and achieve optimization of computing resources and parallel computing programs.

[0005] Specifically, this application is implemented through the following technical solution: In a first aspect, embodiments of this application provide a method for detecting parallel computing performance, including: Obtain the parameter configuration file for the computation job; From the batch processing script templates corresponding to various parallel computing cluster types, load the target script template that matches the parameter configuration file, and instantiate the target script template using the parameter configuration file to obtain the instantiated script; The instantiated script executes the computing job using the parallel computing program indicated by the scheduling parameter configuration file and the computing resources in the parallel computing cluster, and collects initial performance monitoring data during the job execution process; the initial performance monitoring data includes at least the job execution status and cluster resource usage. Based on the initial performance monitoring data, the performance test results of the parallel computing program under the parallel computing cluster are generated.

[0006] Secondly, embodiments of this application also provide a parallel computing performance testing device, comprising: The acquisition module is used to acquire the parameter configuration file for the computation job; The loading module is used to load a target script template that matches the parameter configuration file from the batch processing script templates corresponding to various parallel computing cluster types, and to instantiate the target script template using the parameter configuration file to obtain an instantiated script. The scheduling module is used to execute the computing job through the instantiated script, the parallel computing program indicated by the scheduling parameter configuration file, and the computing resources in the parallel computing cluster, and to collect initial performance monitoring data during the job execution process; the initial performance monitoring data includes at least the job execution status and the cluster resource usage status. The generation module is used to generate the performance test results of the parallel computing program under the parallel computing cluster based on the initial performance monitoring data.

[0007] Thirdly, an optional implementation of this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the parallel computing performance detection method as described in the first aspect above, or any optional implementation of the first aspect.

[0008] Fourthly, an optional implementation of this application also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the parallel computing performance detection method as described in the first aspect above, or any optional implementation of the first aspect.

[0009] The parallel computing performance detection method, apparatus, storage medium, and computing device provided in this application embodiment, by pre-setting batch processing script templates corresponding to various parallel computing cluster types, can quickly load the target script template matching the target computing cluster type when parallel computing resources are needed. Then, by instantiating the target script template using a parameter configuration file, instantiated scripts for computing job scheduling and processing can be generated quickly and automatically. This solves the problem of error-proneness and low efficiency caused by manually writing scripts for each computation in traditional methods. By automatically scheduling parallel computing programs and computing resources to execute computing jobs through instantiated scripts, and simultaneously collecting performance monitoring data during job execution, and automatically generating performance detection results based on the collected performance monitoring data, this not only achieves fully automated monitoring of job operation and resource consumption, but also provides a clear and quantitative display of detailed performance data and performance of parallel computing programs under parallel computing clusters. This replaces the inefficient traditional method of relying on manual recording and piecing together data using fragmented tools. Thus, the parallel computing performance testing method provided in this application completes the entire closed loop from job submission to performance monitoring and then to performance testing and evaluation, significantly improving the accuracy and overall efficiency of parallel computing performance evaluation, and providing a foundation for the optimization of subsequent parallel computing programs.

[0010] Furthermore, the parallel computing performance detection method, apparatus, storage medium, and computing device provided in this disclosure automatically associate the collected performance monitoring data with the specific number of cores used in the parallel computing cluster during job execution, and calculate standardized performance quantification parameters such as total running time, parallel speedup ratio, parallel efficiency, and computing overhead. This transforms the originally scattered and basic system logs into accurate indicators that can be directly used to evaluate the performance and resource utilization efficiency of parallel computing programs.

[0011] Furthermore, the parallel computing performance detection method, apparatus, storage medium, and computing device provided in this disclosure generate detection reports and trend graphs by calculating performance detection parameters under different core counts, achieving an intuitive and visual presentation of how the performance of a parallel computing program changes with the number of cores used in the computation. This overcomes the shortcomings of existing technologies that rely on manual data processing and chart drawing, resulting in low efficiency, poor consistency, and difficulty in comparing multiple configuration parameters horizontally. It forms a fully automated performance detection closed loop from performance monitoring data collection and performance detection parameter calculation to performance detection report and chart output, providing users with a visual basis for quickly locating performance bottlenecks and optimizing resource allocation. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating an exemplary embodiment of a parallel computing performance testing method according to this application; Figure 2 This is a schematic diagram illustrating the content structure of a parameter template file according to an exemplary embodiment of this application; Figure 3 This is a schematic diagram illustrating a specific process of parallel computing according to an exemplary embodiment of this application; Figure 4 This is a schematic diagram illustrating a specific method for generating parallel computing performance test results, as shown in an exemplary embodiment of this application. Figure 5 This is an overall flowchart illustrating an exemplary embodiment of a parallel computing performance testing method. Figure 6 This is a schematic diagram of a parallel computing performance testing device illustrated in an exemplary embodiment of this application; Figure 7 This is a schematic diagram of the structure of a computer device shown in an exemplary embodiment of this application. Detailed Implementation

[0013] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0014] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0015] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0016] Research has revealed that in the fields of parallel computing and high-performance computing, parallel computer systems typically rely on job scheduling systems such as Slurm and PBS to allocate computing resources and schedule the execution of computational jobs. Existing job scheduling systems often focus on job queuing, scheduling, and basic lifecycle management (such as job submission and tracking start and end times), but they provide limited performance monitoring information during job execution and cannot automatically collect fine-grained performance metrics that reflect the execution efficiency of parallel computing programs. For example, they cannot statistically analyze the actual utilization rate of computing cores under different parallel scales, changes in parallel speedup ratios, or the proportion of communication overhead. However, these fine-grained performance metrics are crucial for performance evaluation and optimization of parallel computing programs.

[0017] However, in parallel computing environments, since there's no need to directly provide the aforementioned fine-grained performance metrics, users typically evaluate the performance of parallel computing programs by manually recording or searching for the required data, writing temporary scripts to extract logs from different sources, and using third-party tools for data processing and testing. This manual approach is inefficient or even impossible to implement when facing large-scale, continuously submitted computing jobs, and is prone to incomplete or inconsistent performance data collection. Furthermore, it's difficult to comprehensively analyze the correlation between the configuration parameters of the computing job, actual resource usage, and the final performance test parameters. In addition, because manually collected performance data is often not recorded and stored systematically in a unified and standardized format, it's impossible to easily compare the performance of different optimized versions of parallel computing programs or analyze performance trends under different resource configurations, thus failing to provide effective data support for the continuous iterative optimization of parallel computing programs.

[0018] Based on the above research, this application provides a method, apparatus, storage medium, and computing device for testing parallel computing performance. By employing a standardized parameter configuration file to uniformly define job execution parameters and automatically matching the batch processing script template corresponding to the target cluster type to generate instantiated executable job scripts, it achieves standardization and cross-platform adaptation for job submission. During job execution, performance monitoring commands are automatically embedded and executed to collect fine-grained job execution data and system resource data. Based on the collected data, key performance indicators such as parallel speedup and parallel efficiency are automatically calculated, ultimately generating a performance test report and visualized performance test charts. Thus, through the full automation of the process from job configuration, script generation, data collection to test report, closed-loop testing of parallel program performance is achieved. This effectively solves the problems of low efficiency and low accuracy in performance testing caused by difficulties in data collection, cumbersome testing processes, and lack of historical comparison data in existing technologies. It significantly improves the efficiency and accuracy of parallel computing performance evaluation, providing scientific data support and direction for subsequent optimization of parallel computing programs and efficient utilization of computing resources.

[0019] The shortcomings of the above solutions are the result of the inventor's practical experience and careful research. Therefore, the discovery process of the above problems and the solutions proposed in this application below should be considered as the inventor's contributions to this application.

[0020] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0021] It should be noted that the specific terms mentioned in the embodiments of this disclosure include: Python: A high-level programming language widely used in the field of computer software development, especially suitable for quickly building automated scripts and implementing data analysis and processing logic; Pandas: A core data processing library based on Python that makes it easy to store, organize, filter, and manipulate structured row and column data; Matplotlib: A basic and comprehensive plotting library that provides a large number of low-level plotting functions, allowing you to create and customize various types of static and interactive charts, such as line charts, scatter plots, bar charts, etc. Seaborn: A high-level interface built on Matplotlib, with a particular focus on the visualization of statistical data. It makes it easier and faster to create beautiful and informative statistical graphs (such as relationship diagrams and distribution plots).

[0022] To facilitate understanding of this embodiment, a method for detecting parallel computing performance disclosed in this application will first be described in detail. The execution subject of the parallel computing performance detection method provided in this application is generally a terminal device or other processing device with certain computing power. The terminal device can be a user equipment (UE), mobile device, user terminal, terminal, personal digital assistant device (PDA), handheld device, computer device, etc. In some possible implementations, the parallel computing performance detection method can be implemented by the processor calling computer-readable instructions stored in the memory.

[0023] The following describes the method for detecting parallel computing performance provided in this application embodiment, taking a cloud computing server as the execution subject as an example.

[0024] like Figure 1 The flowchart shown is a method for detecting parallel computing performance provided in an embodiment of this application, which may include the following steps: S101: Obtain the parameter configuration file for the computation job.

[0025] Here, the parallel computing performance method provided in this disclosure can be applied to parallel computing program performance testing scenarios, as well as other data processing and testing scenarios that require computational task orchestration, computational resource scheduling, and performance evaluation, such as large-scale scientific data processing scenarios, batch execution and comparison scenarios of machine learning model training tasks, etc. The parallel computing program is used to perform parallel computations on computational jobs using the computational resources in a parallel computing cluster; the parallel computing program can be a pre-written processing program.

[0026] This application provides a method for evaluating parallel computing performance, which can be implemented using a central control scheduler deployed on a cloud computing server. The central control scheduler can manage the entire process from receiving user-submitted parameter configuration files as input to outputting visualized performance testing results for the parallel computing program under test, thus completing the parallel computing performance evaluation.

[0027] Parameter configuration files can be generated by users using pre-written, standardized parameter configuration templates. These templates standardize the various parameters required for running parallel computing programs and batch processing script templates (summarized later). The parameter configuration templates explicitly define the parameter types and formats for each required parameter item. For example, the templates must explicitly declare the following parameter items and their data types: `exe_path`: the absolute path to the executable file of the parallel computing program; `config_file`: the input path for the computation job; `output_dir`: the output directory for the computation result files; `type`: the type of parallel computing cluster to be used, and various other configuration parameters required during job execution. The parameter configuration templates provide a unified input standard for the computation jobs that parallel computer systems need to process.

[0028] Parameter configuration files describe various parameters required for executing computational jobs, including but not limited to exe_path, config_file, output_dir, and type. As a structured data carrier, the parameter configuration file centrally contains all the parameter information needed to define the computational task and can serve as a standardized interface between the user and the parallel computer system.

[0029] In practice, when there is a need to process large-scale computational jobs, users can obtain a parameter configuration template and fill in the parameters indicated in the template to create a parameter configuration file. Then, the user-configured parameter configuration file is obtained through the aforementioned central control scheduler.

[0030] In one embodiment, the parameter configuration file in S101 above may include first parameter information and second parameter information. Both the first parameter information and the second parameter information are information that needs to be set in the parameter configuration template. The first parameter information may at least include parallel computing cluster type information, first path information of the parallel computing program, second path information of the computing job, output directory information of the computing results, and runtime environment information; the second parameter information is used to indicate multiple test instance information for the parallel computing program.

[0031] Here, the parameter configuration file is used to centrally define and store all the key parameters and settings required for the runtime of a computation job. The parameter configuration file can include first-level parameter information about the basic runtime environment and resource framework necessary for executing the current computation job, and second-level parameter information for testing the performance of the parallel computing program under different resource usage limits. Based on the second-level parameter information, the same parallel computing program can be used in a parallel computing cluster to execute jobs according to different resource usage limits. Each resource usage limit serves as a test instance.

[0032] Specifically, the parameter configuration file can be in YAML (Yin't Markup Language) format or JavaScript Object Notation (JSON) format.

[0033] The first path information is the absolute path of the parallel computing program to be executed; the second path information is the file path of the input data (i.e., the computing job) that the computing needs to read; the output directory information is the directory where the computing results are saved; and the runtime environment information is the software environment that needs to be pre-loaded (such as a specific Message Passing Interface (MPI) library). These information, as components of the first parameter information, constitute the basic environment and resource settings necessary for the computing job to run successfully on the specified computing cluster.

[0034] The second parameter information includes at least information on different test instances for the parallel computing program. This information indicates resource usage limitations of the parallel computing program, such as core count limits and parallel scale limits. Specifically, a test instance can refer to a complete computing task instance upon which the parallel computing program can load resources and perform computations. Based on different test instance information, the performance of the parallel computing program can be tested and evaluated. Multiple test instance information can be specifically represented as case 1, case 2, etc. , case M; case M represents the Mth test instance.

[0035] The output directory is a specific folder path used to store and archive all result files and related data generated by a single computation job. Specifically, this directory typically includes output data files directly generated by the parallel computing program, runtime logs, performance test reports, and visualizations of performance test charts.

[0036] Understandably, in this application, multiple test instances can be flexibly configured. Specifically, all test instances can be based on the exact same computational program and input data, with only the number of computational cores varying to form a series of comparative tests, thereby systematically evaluating the parallel performance scalability of the parallel computing program under different numbers of computational cores. Alternatively, multiple test instances can be configured so that each test instance corresponds to an independent and complete set of parameter configurations. These parameter configurations can differ from each other in multiple dimensions such as parallel computing program path, input data, and number of cores, for simultaneously performing batch performance tests and comparisons on multiple different computing tasks or different variations of the same task.

[0037] Specifically, the parameter configuration file can be generated by the user filling in the specific content according to a predefined parameter template file with a fixed structure. This unified parameter template file specifies which parameter items need to be filled in, the format and meaning of each item (such as which are required paths and which are resource quantities). Users only need to fill in the specific information of this computing job (such as the actual path of the parallel computing program used and the number of cores required) according to the template specifications to generate a valid parameter configuration file.

[0038] like Figure 2 The diagram illustrates the content structure of a parameter template file provided in this embodiment. This parameter template file predefines a structured parameter configuration framework, explicitly listing key parameter configuration items to standardize various parameter configurations required for the operation of parallel computing programs. Specifically, it includes a "type" field specifying the type of parallel computing cluster, a "modules" field describing the system operating environment, a "output_dir" field defining the storage location of computation results, a "config_file" field setting input file parameters, a "exe_path" field indicating the path to the parallel computing program file, and a "runs" field listing test instance information. Based on this, users can obtain a complete parameter configuration file by filling in specific parameter configuration information related to the current computation task into the various predefined fields of the parameter template file. The parallel computing performance testing method provided in this embodiment ensures that the configuration information of all computation jobs follows the same standard format through a pre-designed parameter template file, providing consistent and reliable input for subsequent automated processing.

[0039] In practice, before testing, it is necessary to ensure that the parallel computing program to be tested has been compiled into an executable file that can run on the parallel computing cluster, and that the input data files required by the program are placed in a location accessible to all members of the parallel computing cluster. Simultaneously, a result output directory with sufficient space and write permissions should be created in advance. Subsequently, the user, based on the actual computing job requirements and... Figure 2The structured parameter template file shown is used to fill in specific paths, resource requirements, and other information to generate a complete parameter configuration file. When a user submits this parameter configuration file via command line or a user interface (such as a graphical user interface, GUI), the aforementioned central control scheduler receives and retrieves the file, using it as input to initiate the entire automated parallel computing performance testing process. For example, if a user wants to test the performance of a fluid mechanics program with different numbers of cores, they only need to fill in the program's path, input data path, output directory, and other parameter configurations in the parameter template file, and specify the use of 32 cores, 64 cores, and 128 cores in the runs list respectively. This will generate a parameter configuration file for the computing job, which can then be submitted. Subsequent performance testing will be automatically handled by the central control scheduler.

[0040] Optionally, after obtaining the parameter configuration file, the central control scheduler can perform automated verification to ensure the completeness and validity of the parameter configuration. This can include: checking whether the parameter configuration file contains all necessary attribute fields (such as program path, parallel computing cluster type, etc.); verifying whether the format of the entered parameter values ​​conforms to preset specifications (e.g., whether the path is a valid string, whether the number of cores is a positive integer); accessing the system status of the parallel computing cluster to be used to confirm whether the current cluster can provide the computing resources requested in the configuration file (such as a sufficient number of available computing cores and memory); and verifying whether the specified output directory has sufficient storage space. The purpose of these automated verifications is to preemptively eliminate runtime failures caused by configuration errors or insufficient resources before job submission, ensuring the smooth execution of subsequent automated performance testing processes.

[0041] Furthermore, if any non-compliance is detected during the aforementioned automated verification process, the central control scheduling program will immediately terminate the current process, clearly identify the specific error type (such as "missing necessary parameters", "invalid core number format", "insufficient storage space", or "resources not available"), and generate a prompt message containing the error type and a detailed description to be fed back to the user.

[0042] S102: Load the target script template that matches the parameter configuration file from the batch processing script templates corresponding to various parallel computing cluster types, and instantiate the target script template using the parameter configuration file to obtain the instantiated script.

[0043] Here, the types of parallel computing clusters can include, but are not limited to, HPC clusters, intelligent computing clusters (such as graphics processing unit (GPU) clusters), and supercomputing clusters.

[0044] Batch script templates are pre-written text files containing a specific job scheduling system syntax framework and general instruction structure. Their key parameter variables are designed as replaceable placeholder variables (e.g., ...). Batch script templates can be instantiated into executable job scripts on a parallel computing cluster according to actual computing task requirements. Performance data collection commands are embedded before and after the job execution commands in the batch script template to record the actual computing job time and computing resource usage. In other words, batch script templates can be used to control the execution of computing jobs and collect performance data during job execution.

[0045] The target script template is a batch processing script template that matches the type of parallel computing cluster indicated in the parameter configuration file and the currently used job scheduling system. The instantiated script is an executable job script obtained by instantiating the target script template with parameters. This script can be executed on the parallel computing cluster indicated in the parameter configuration file. The instantiated script can contain a set of operation instructions such as specific computation job parameters and computation resource requirements.

[0046] In practice, the central control scheduler reads the "type" field from the parameter configuration file to determine the type of computing cluster the current job is targeting (e.g., HPC cluster or GPU cluster). Then, based on the identified cluster type and the job scheduling system used by that cluster type, the central control scheduler selects and loads the corresponding target script template from the batch processing script template library according to the adaptation relationship. Next, by parsing the parameter information in the parameter configuration file, the central control scheduler instantiates the target script template, thereby generating an instantiated script with all parameters specified, which can be directly recognized and executed by the corresponding parallel computing cluster.

[0047] In one embodiment, S102 described above can be implemented according to the following steps: S102-1: Determine the target parallel computing cluster type used by the computing job based on the parallel computing cluster type information.

[0048] Here, the parallel computing cluster type information can specifically be the type configuration item in the parameter configuration file. This item is used to indicate the specific type of parallel computing cluster used in this computing job, which is the target parallel computing cluster type.

[0049] In practice, the obtained parameter configuration file can be parsed and read by the central control scheduling program to determine the parallel computing cluster type information in the first parameter information, and the cluster type indicated by the parallel computing cluster type information can be used as the target parallel computing cluster type.

[0050] S102-2: Based on the job scheduling system used by the target parallel computing cluster type and the correspondence between the job scheduling system and the batch script template, load the target script template from a variety of batch script templates.

[0051] Here, the job scheduling system is a core management system deployed on a parallel computing cluster. It is used to uniformly manage and allocate computing resources (such as CPU, memory, GPU, etc.) within the parallel computing cluster, and is responsible for receiving, queuing, scheduling, and executing submitted computing jobs. The job scheduling system may include SimpleLinux Utility for Resource Management (Slurm), a PortableBatch System (PBS), and a Load Sharing Facility (LSF), etc. There is a strict matching relationship between batch script templates and job scheduling systems. Specifically, there can be a one-to-one correspondence between batch script templates and job scheduling systems; different job scheduling systems correspond to different batch script templates. For example, job scheduling system 1 corresponds to batch script template 1, and job scheduling system 2 corresponds to batch script template 2.

[0052] Alternatively, there may be a corresponding relationship between batch processing script templates, job scheduling systems, and parallel computing clusters. For any parallel computing cluster, different batch processing script templates can be used under different job scheduling systems.

[0053] In practice, after determining the type of the target parallel computing cluster, the central control scheduler can simultaneously determine the job scheduling system used by that type of cluster. For example, if the "type" field is identified as "HPC_Slurm", the target parallel computing cluster type is an HPC cluster, and the corresponding job scheduling system is the Slurm system. As another example, if the "type" field is identified as "HPC", the central control scheduler can automatically determine the corresponding job scheduling system as the Slurm system based on the established association relationships and / or job scheduling system indication information (this information can be pre-specified or determined based on the cluster's operating environment, and it indicates the required job scheduling system). Subsequently, based on the one-to-one correspondence between the defined job scheduling systems and batch script templates, the central control scheduler retrieves and loads the target script template that precisely matches the identified job scheduling system from the preset batch script template library.

[0054] S102-3: Generate multiple parameter dictionaries using the test instance information indicated by the first parameter information and the second parameter information.

[0055] Here, the parameter dictionary is an internal data structure that temporarily stores and organizes the set of all parameters required for a single job execution. It is used to transform the abstract configuration items in the parameter configuration file into key-value pairs that can be directly used by the parallel computing program. Specifically, the parameter dictionary may contain general configurations obtained from the first parameter information (such as the program path exe_path) and specific running parameters obtained from the information of a certain test instance (such as the number of cores requested in this run node_count).

[0056] For example, when the second parameter information defines three test instances that apply to run the same parallel computing program using 16, 32, and 64 computing cores respectively, three independent parameter dictionaries will be generated. These three parameter dictionaries all contain the same parallel computing program path, but the values ​​in the key-value pairs corresponding to the number of cores are 16, 32, and 64 respectively.

[0057] In practice, the central control scheduler reads the second parameter information used to define batch test tasks. This information lists multiple test instance information in a list format, with each test instance containing its own specific runtime parameters. Then, the program iterates through each test instance, merging the general configuration items from the aforementioned first parameter information (e.g., first path information exe_path, second path information config_file, output directory information output_dir, and target parallel computing cluster type type) with the specific parameters from the currently iterated test instance information (e.g., the number of computing cores requested for this run, node_count), together forming a complete dictionary describing the parameter requirements for a single job run.

[0058] S102-4: Instantiate the target script template using each parameter dictionary to obtain the instantiated scripts corresponding to multiple test instance information.

[0059] In practice, the central control and scheduling program reads the loaded target script template as the base text for each independent parameter dictionary. It then iterates through each key-value pair in the dictionary, searching for a placeholder with the same name as the key in the template text and replacing it with the corresponding value from the parameter dictionary. Once all key-value pairs in the dictionary have been searched and replaced, all the original placeholders in the template are replaced with the specific parameter values, thus generating a complete and executable instantiated script. This process is performed independently for each parameter dictionary, ultimately generating multiple instantiated script files equal to the number of test instance files.

[0060] S103: By instantiating scripts, scheduling parameter configuration files indicate the parallel computing program and computing resources in the parallel computing cluster to execute computing jobs, and collect initial performance monitoring data during job execution; the initial performance monitoring data includes at least job execution status and cluster resource usage.

[0061] Here, initial performance monitoring data refers to the raw recorded data collected throughout the complete execution cycle of a computation job. Initial performance monitoring data includes, but is not limited to, job execution status and cluster resource usage. Job execution status, for example, can be the actual start time of the computation job (which can be expressed as...). ), calculate the actual end time of the task (which can be expressed as The cluster resource usage can include the actual number of computing cores used during job execution (which can be expressed as...). This includes the job's running status (success or failure) and the specific output files or calculation results generated after the computation job completes. (and other resources consumed during operation, such as memory usage, storage I / O, or network bandwidth).

[0062] In practice, for each instantiated script, the central control scheduler submits the script to the job scheduling system. The job scheduling system then runs the script, automatically allocating the corresponding computing resources based on the instructions in the script and starting the parallel computing program specified in the runtime parameter configuration file, thereby executing the current computational job. During this process, the execution status of the computational job is monitored simultaneously, and initial performance monitoring data generated during the complete execution flow of the job is automatically collected.

[0063] like Figure 3 The diagram shown is a schematic representation of a specific parallel computing process provided in an embodiment of this application. Figure 3 This demonstrates the complete implementation process from parameter configuration to multi-job parallel execution and data acquisition. First, a parameter configuration file containing first and second parameter information is received. Based on this, for each test instance defined by the second parameter information, the general first parameter information is merged with the instance-specific parameters to generate corresponding parameter dictionaries. Figure 3 Taking M test instance information as an example, the corresponding parameter dictionaries 1 to M are shown. Then, a target script template matching the target parallel computing cluster is loaded, and variables are replaced using each parameter dictionary to generate instantiated scripts 1 to M in batches. These instantiated scripts are automatically submitted to the job scheduling system. The scheduling system executes the program sequentially according to each instantiated script. Figure 3Programs 1 through M are the execution processes of programs implemented according to M instantiated scripts. Specifically, the execution process of each program in Programs 1 through M can be as follows: according to the instantiated scripts, the parallel computing program and the computing resources in the target parallel computing cluster are scheduled to process the computing job. During the execution of each program, key performance data is automatically recorded, including the start / end time of the computing job and the actual number of computing cores used, providing basic data for subsequent performance testing.

[0064] In one embodiment, S103 described above can be implemented according to the following steps: S103-1: For any instantiated script, submit the instantiated script to the job scheduling system via the job submission command, and run the instantiated script if the submission is successful.

[0065] Here, the job submission command is used to submit the instantiated script to the job scheduling system. For example, in the Slurm scheduling system, the job submission command is sbatch; in the PBS scheduling system, the job submission command is qsub.

[0066] In practice, for each generated instantiated script, the central control scheduler selects the corresponding job submission command based on the job scheduling system used by the target parallel computing cluster type. Subsequently, the central control scheduler invokes this job submission command, passing the currently processed instantiated script as a command parameter, thereby submitting the computation job to the target job scheduling system. Once the job scheduling system successfully receives and returns a successful submission status message, it can internally allocate computing resources at an appropriate time based on resource allocation strategies and begin running the computational tasks defined in the instantiated script.

[0067] S103-2: By running the instantiated script, according to the test instance information corresponding to the instantiated script, schedule the parallel computing program indicated by the first path information and the computing resources in the parallel computing cluster to execute computing jobs, and collect initial performance monitoring data during job execution.

[0068] In practice, for each instantiated script, after the job scheduling system starts running the instantiated script, it schedules and starts the parallel computing program specified by the first path information according to the key instructions in the script. Simultaneously, the job scheduling system identifies resource request instructions in the script (such as Slurm's #SBATCH --ntasks) and ensures that the corresponding number of computing cores and other computing resources are allocated to this computing job. During this process, the operation of this computing job is monitored synchronously, and initial performance monitoring data generated during the complete execution process of the job is automatically collected. On one hand, a dedicated performance data collection command, pre-embedded in the target script template during the preparation phase, is automatically executed as the instantiated script runs, responsible for capturing the core runtime metrics of this computing job, such as the actual time (start) and time (end) of the job on the computing nodes, and the actual number of computing cores used during the execution of this computing job. On the one hand, the main control scheduler monitors the specific consumption of hardware resources such as memory; on the other hand, after running the instantiated script, it continuously and actively monitors the job status and collects the execution overview of the current computing job at the cluster management system level by querying the logs and status interface of the job scheduling system, such as key event points such as job submission, queuing, start, and end, as well as the final success or failure status.

[0069] Optionally, the master control scheduler is also configured to monitor the entire performance testing process in real time. When an abnormality is detected at any stage of the process (such as parameter verification, job submission, or data acquisition), the execution of the current process is automatically terminated, and information containing the specific error type and a detailed description is generated and output.

[0070] S104: Based on the initial performance monitoring data, generate the performance test results of the parallel computing program under the parallel computing cluster.

[0071] Here, performance test results refer to the collective term for the visual charts and structured reports generated to evaluate the performance of parallel computing programs. Essentially, it is a comprehensive performance evaluation conclusion. These results are used to intuitively and quantitatively demonstrate the running efficiency and resource utilization of parallel computing programs.

[0072] Specifically, performance test results may include visual charts showing how program speedup and parallel efficiency change with the number of computing cores, presented in the form of graphs, as well as structured data reports summarizing key metrics such as runtime and computational overhead.

[0073] In practice, the initial performance monitoring data collected can be automatically processed and calculated by invoking pre-defined detection logic or external detection services, thereby generating a conclusive output that comprehensively reflects the performance of the parallel computing program. Specifically, this process can calculate one or more key performance indicators from the initial performance monitoring data, based on predefined rules or configurable metrics, to evaluate the efficiency, resource utilization, and scalability of the parallel computing program. These indicators, along with their associated configuration and runtime context information, are then automatically organized into a formatted document or graphical view that is easy for users to view, compare, and archive. For example, the results of different test instances can be automatically compared, and a comprehensive detection file integrating data tables and trend charts can be generated, thus completing the transformation from raw data to performance evaluation information that can be directly used for decision-making.

[0074] In one embodiment, S104 described above can be implemented according to the following steps: S104-1: For any instantiated script, determine the performance testing parameters of the parallel computing program under the instantiated script based on the initial performance monitoring data collected when the instantiated script is run and the number of cores indicated by the test instance information corresponding to the instantiated script.

[0075] Here, the performance testing parameters are a set of key indicator data used to quantitatively evaluate the performance of parallel computing programs during the execution of computing jobs.

[0076] Specifically, performance testing parameters can include total runtime, parallel speedup, parallel efficiency, and computational cost. Total runtime (Duration) reflects the total time a parallel computing program takes from start to finish. Duration(N) specifically refers to the total time a parallel computing program uses N computing cores. Parallel speedup (SpeedUp) reflects the speed difference between using multiple computing cores and using a single core. SpeedUp(N) specifically refers to the speed increase achieved by using N computing cores compared to using a single core. Parallel efficiency (Efficiency) measures the actual effective computing power contributed by the additional computing cores. Efficiency(N) specifically refers to the ratio between the actual speedup (SpeedUp(N)) and the theoretical ideal linear speedup (N times) when using N computing cores. Computational cost (Cost) assesses the total amount of computing resources consumed to complete the computation job. Cost(N) specifically refers to the total time a parallel computing program consumes when using N computing cores. Each computing core completes the execution of a computing job, consuming a total amount of computing resources.

[0077] For example, for any parallel computing program, its performance testing parameters can be calculated based on the collected initial performance monitoring data using a preset computing logic. The preset computing logic can be implemented according to the following formulas (1) to (4): (1) (2) (3) (4) Where SpeedUp(N) is the parallel computing speedup ratio under N computing cores, N represents the number of computing cores requested, T(1) represents the total time taken for the parallel computing program to complete the running process using 1 computing core, and T(N) represents the total time taken for the parallel computing program to complete the running process using N computing cores. The computational overhead for N computing cores, This indicates the number of computing cores actually used by the parallel computing program. It can be the same as N, or it can be different from N; This represents the parallel efficiency with N computing cores. This represents the total runtime across N computing cores. Indicates the time when the parallel computing program starts running. This indicates the time when the parallel computing program finishes running.

[0078] The parallel computing performance testing method provided in this application pre-deploys a data extraction script and a performance testing module. The data extraction script extracts performance monitoring data from the initial performance monitoring data collected during job execution. The performance testing module receives the performance monitoring data, calculates performance testing parameters, and uses a primary programming tool (such as Python) to organize the performance testing results into a structured performance testing report. It then uses a visualization library (such as Matplotlib or Seaborn) as the core plotting engine to draw performance testing graphs, thereby automatically generating the performance testing report and performance testing charts.

[0079] In practice, after all instantiated scripts have run, the central control scheduler can call a pre-written data extraction script to automatically parse the log files generated by the job scheduling system or extract the performance monitoring data for each instantiated script from the initial performance monitoring data records. Specifically, this includes extracting the start and end times of the computation job, as well as the actual number of computing cores used during job execution, for each instantiated script. And the final success or failure status of the operation. Then, the performance detection module is called in conjunction with the number of application cores N specified in the test instance information corresponding to the instantiated script, and the performance detection parameters are calculated based on the extracted performance monitoring data: according to Time(start) and Time(end), the total running time Duration(N) is obtained using formula (4); then, the baseline time T(1) of the same parallel computing program under single-core operation obtained in advance is compared with the current time Duration(N), and the parallel speedup ratio SpeedUp(N) is obtained using formula (1); then, the parallel efficiency Efficiency(N) is calculated according to formula (3); finally, according to Given the total runtime Duration(N), the computational cost Cost(N) is calculated using formula (2). For example, the data extraction script parses from the logs that a job started at 10:00:00 and ended at 10:05:30, actually using 32 cores. Combining the core count N=32 specified in this test instance and the known single-core baseline time T(1)=6000 seconds, we can calculate Duration(32)=330 seconds, SpeedUp(32)≈18.18, Efficiency(32)≈56.8%, and Cost(32)=10560 cores·second. These results are the performance testing parameters of the parallel computing program.

[0080] S104-2: Generate a performance test report and / or performance test graph for the parallel computing program based on the performance test parameters of the parallel computing program under each instantiation script.

[0081] Here, a performance test report is a structured document used to systematically summarize and display the core performance metrics of a parallel computing program under various test instance information, providing users with a comprehensive and readable performance evaluation summary. Specifically, the report can be in a structured format such as tables, clearly listing key performance data for different test instances. Specific content may include the number of computing cores used in each test, the corresponding total program execution time, the calculated parallel speedup ratio, parallel efficiency, and computational overhead, among other metrics.

[0082] Optionally, the performance test report may also include: a comparison between resource requests and actual usage, such as a comparison of the difference between the requested number of cores and the actual number of cores used, by comparing N and This allows for direct diagnosis of problems and targeted performance tuning. For example, if A value significantly less than N may indicate insufficient cluster resources or inadequate parallelism in the parallel computing program; if the two are close, it indicates that the resource request is reasonable and fully utilized. Performance test reports can also include detailed resource utilization (such as average and peak CPU and memory utilization), performance bottleneck diagnostic information (such as identifying the main wait type as communication synchronization or uneven load), comparative tests across test instances (such as the trend of metric changes under different scales or configurations), and a complete record of the test configuration and environment (such as program version, input data characteristics, and cluster queue information).

[0083] For example, a performance test report could include a table of parallel speedup ratios along with a diagnostic conclusion: "When the number of cores increases to 64, the actual number of cores used is 58, the average CPU utilization drops to 70%, and the communication time accounts for more than 40%, indicating that communication overhead has become the main bottleneck at this scale," thus providing users with direct optimization directions.

[0084] Performance benchmark charts comprise graphs showing the relationship between various performance metrics and the number of cores. A performance benchmark chart illustrates how a performance metric (such as speedup and efficiency) changes with the number of computing cores. Performance benchmark charts can take the form of line graphs, bar charts, or other visually intuitive formats, helping users quickly identify performance trends in parallel computing programs, pinpoint efficiency inflection points, and make visual comparisons between different configurations. Specifically, performance benchmark charts may include, for example, a "speedup-cores graph" showing how speedup changes with the number of cores, an "efficiency-cores graph" reflecting the rise and fall of parallel efficiency with the number of cores, and a "computational overhead graph" that visually compares the total resource consumption at different core counts.

[0085] As an example, a performance test graph corresponding to parallel efficiency can be a curve, with the horizontal axis representing the number of cores (e.g., 8, 16, 32, 64) and the vertical axis representing the corresponding parallel efficiency value. Users can intuitively determine at what number of cores the scalability of the parallel computing program begins to deteriorate by observing whether the curve drops rapidly.

[0086] In practice, the central control and scheduling program calls the performance testing module to automatically generate reports and charts.

[0087] After collecting performance test parameters from all test instances, the performance testing module uses Python's Pandas library to organize all performance test parameters (including number of cores, total runtime, parallel speedup, parallel efficiency, and computational overhead) into a structured data table. Subsequently, the module directly exports this structured data table as a structured performance test report, for example, storing it as a comma-separated values ​​(CSV) file that can be directly opened by spreadsheet software, or further formatting it into a more readable PDF document. Simultaneously with report generation, the module calls the pre-defined visualization library Matplotlib to use Seaborn to plot visualizations with the number of cores as the horizontal axis. For example, it connects the speedup values ​​for each test instance into a "parallel speedup - number of cores" curve, the efficiency values ​​for each test instance into a "parallel efficiency - number of cores" curve, and the computational overhead values ​​for each test instance into a "computational overhead - number of cores" curve. Finally, the generated structured report files (such as CSV or Portable Document Format (PDF)) and visualization chart files (such as images in Portable Network Graphics (PNG) format) are automatically saved to the preset output directory.

[0088] like Figure 4 The diagram shown is a specific illustration of the generation of parallel computing performance test results according to an embodiment of this application. Figure 4 The internal data processing flow of the performance testing phase is demonstrated. First, performance monitoring data for each job is extracted from the initial performance monitoring data records, including the job's actual start time, end time, and the actual number of computing cores used. The system also includes the number of cores (N) requested for each test instance. Based on this core data, key performance testing parameters are determined, including: SpeedUp, Cost, Efficiency, and Duration. These performance testing parameters are then used to automatically generate structured performance testing reports and intuitive performance testing graphs, thus automating the transformation and output from raw monitoring data to final testing results.

[0089] S104-3: Use the performance test report and / or performance test chart as the performance test result.

[0090] In practice, the central control and scheduling program combines the structured performance test report files (such as CSV or PDF format) and visual performance test graph files (such as PNG format) generated by the performance test module, and uses them together as the final output of this performance test task, i.e., the performance test result. Specifically, the scheduling program automatically saves the generated report files, graph files, and calculation results to the output directory specified in the parameter configuration file, thereby completing the entire closed loop from job submission to result output.

[0091] In one implementation, to enhance the robustness and fault tolerance of the computation job submission process, this application also provides an automated retry scheme for failed instantiation script submissions. Specifically, the retry and recovery process after a failed instantiation script submission can be implemented according to the following steps: S1: If the instantiation script fails to be submitted, the instantiation script will be resubmitted at the preset time interval.

[0092] Here, the preset time is used to provide the job scheduling system with time to recover in the event of transient failures (such as network fluctuations or brief overload of the job scheduling system). For example, the preset time interval can be set based on experience, and this embodiment does not impose a specific limitation; for example, the preset time interval can be set to 30 seconds.

[0093] In practice, when the central control scheduler submits an instantiated script to the job scheduling system via a job submission command, if it receives a clear failure signal from the job scheduling system (e.g., the command returns a specific error code or displays "submission failed"), the central control scheduler determines that the submission has failed. At this point, the scheduler initiates a retry process: First, the scheduler accesses its internal configuration and reads a predefined waiting time, i.e., a preset time interval (e.g., 30 seconds); then, the central control scheduler enters a waiting state until the preset time interval expires, and then executes the same job submission command again to attempt to resubmit the same instantiated script.

[0094] S2: If the number of consecutive submission failures within a preset time interval reaches the first preset number, then increase the preset time interval and return to the step of resubmitting the instantiated script according to the preset time interval, until the total number of consecutive submission failures reaches the second preset number or the submission is successful.

[0095] Here, the first preset number of attempts is a threshold set beforehand to determine whether the retry submission strategy needs to be adjusted. For example, if the first preset number of attempts is 3, it means that the retry strategy adjustment will be initiated after the instantiated script fails to submit 3 times consecutively.

[0096] The second preset number of attempts is a maximum limit on the number of consecutive failures set before a task submission is deemed unrecoverable. It determines that the instantiated script cannot be successfully submitted in the current environment, and then completely abandons retries and marks the submission as failed, preventing the system from getting stuck in an infinite loop of invalid attempts.

[0097] The total number of consecutive failed commits indicates the number of failures from the start of the instantiation script to the present. For example, if the second preset number is set to 10, it means that if the total number of consecutive failed commits of the instantiation script reaches 10, all retry commit processes will be stopped and the final failure will be reported.

[0098] In practice, the central control scheduler continuously counts the number of consecutive failed submissions during the retry process. When the count reaches a first preset number (e.g., 3 times), the scheduler determines that a more conservative retry strategy is needed. At this point, it automatically increases the preset time interval according to predefined rules (e.g., increasing the waiting time from 30 seconds to 60 seconds). Afterward, the central control scheduler uses the new preset time interval to continue executing the "wait interval - resubmit" loop. It should be noted that each time a new preset time interval is used, the count of the first preset number starts from 0, while the total number of consecutive failed submissions inherits the value from the previous interval. The loop continues, meaning that consecutive failures reaching the first preset number in each preset time interval trigger an interval increase, until one of two outcomes occurs: either a resubmission succeeds, the entire retry process terminates, and the job is switched to monitoring; or the total number of consecutive failures accumulates to a larger second preset number (e.g., 10 times), at which point the scheduler determines the submission has permanently failed, stops all retry attempts, records the error, and terminates the submission process for that instantiated script.

[0099] Furthermore, the central control scheduler can also perform fault tolerance management during job execution. Specifically, during job execution, the scheduler automatically saves the intermediate calculation results, memory status, and progress markers of the parallel computing program to persistent storage according to preset time periods (e.g., 10 minutes) or critical calculation stages, forming checkpoint files. If the computing job is abnormally interrupted due to unexpected reasons such as network interruption or computing node hardware failure, the scheduler will detect the interruption event and save the intermediate calculation state. Once the scheduler detects that the running conditions have been restored (e.g., network recovery or replacement of the faulty node), it will automatically resume the subsequent calculations from the point of interruption, realizing the breakpoint resume function.

[0100] like Figure 5The diagram shows the overall flowchart of a parallel computing performance detection method provided in this application embodiment. Specifically, the method first obtains the parameter configuration file submitted by the user, then parses the file, and determines the target parallel computing cluster type based on the first parameter information. For the identified target parallel computing cluster type, a matching target script template is automatically loaded from various batch processing script templates, and the target script template is instantiated according to the parameter configuration information in the parameter configuration file to generate a specific executable instantiated script. Subsequently, the instantiated script is automatically submitted to the job scheduling system corresponding to the target parallel computing cluster. Based on the instantiated script, computing resources and parallel computing programs are scheduled to execute the computing job. During and after the job execution, the system automatically collects performance data and generates a structured performance detection report and a visualized performance detection chart based on this data. Finally, the generated detection report and charts are output as performance detection results, thereby completing the fully closed-loop automated processing of parallel computing performance, significantly improving the detection efficiency and accuracy of parallel computing program performance.

[0101] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0102] Based on the same inventive concept, this disclosure also provides a parallel computing performance testing device corresponding to the parallel computing performance testing method. Since the principle of the device in this disclosure for solving the problem is similar to the parallel computing performance testing method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0103] like Figure 6 The diagram shown is a schematic of a parallel computing performance testing device provided in an embodiment of this application, comprising: Module 601 is used to obtain the parameter configuration file for the computation job; The loading module 602 is used to load a target script template that matches the parameter configuration file from the batch processing script templates corresponding to various parallel computing cluster types, and to instantiate the target script template using the parameter configuration file to obtain an instantiated script. The scheduling module 603 is used to execute the computing job through the instantiated script, the parallel computing program indicated by the scheduling parameter configuration file, and the computing resources in the parallel computing cluster, and to collect initial performance monitoring data during the job execution process; the initial performance monitoring data includes at least the job execution status and the cluster resource usage status. The generation module 604 is used to generate the performance test results of the parallel computing program under the parallel computing cluster based on the initial performance monitoring data.

[0104] In one optional implementation, the parameter configuration file includes first parameter information and second parameter information. The first parameter information includes at least parallel computing cluster type information, first path information of the parallel computing program, second path information of the computing job, output directory information of the computing results, and runtime environment information. The second parameter information is used to indicate multiple test instance information for the parallel computing program.

[0105] In one optional implementation, the loading module 602, when loading a target script template matching the parameter configuration file from batch processing script templates corresponding to various parallel computing cluster types, and instantiating the target script template using the parameter configuration file to obtain an instantiated script, is used for: Based on the parallel computing cluster type information, determine the target parallel computing cluster type used by the computing job; Based on the job scheduling system used for the target parallel computing cluster type and the correspondence between the job scheduling system and the batch processing script template, the target script template is loaded from a variety of batch processing script templates; Multiple parameter dictionaries are generated using the test instance information indicated by the first parameter information and the second parameter information; The target script template is instantiated using each of the parameter dictionaries to obtain instantiated scripts corresponding to multiple test instance information.

[0106] In an optional implementation, the scheduling module 603, when executing the computing job through the instantiated script, the parallel computing program indicated by the scheduling parameter configuration file, and the computing resources in the parallel computing cluster, and collecting initial performance monitoring data during job execution, is used to: For any instantiated script, the instantiated script is submitted to the job scheduling system via a job submission command, and the instantiated script is run if the submission is successful. By running the instantiated script, the parallel computing program indicated by the first path information and the computing resources in the parallel computing cluster are scheduled to execute computing jobs according to the test instance information corresponding to the instantiated script, and initial performance monitoring data is collected during the job execution process.

[0107] In an optional implementation, the generation module 604, when generating the performance test results of the parallel computing program under the parallel computing cluster based on the initial performance monitoring data, is used to: For any instantiated script, the performance detection parameters of the parallel computing program under the instantiated script are determined based on the initial performance monitoring data collected when the instantiated script is run and the number of cores indicated by the test instance information corresponding to the instantiated script. Based on the performance detection parameters of the parallel computing program under each instantiation script, generate a performance detection report and / or performance detection graph corresponding to the parallel computing program. The performance test report and / or performance test graph shall be used as the performance test result.

[0108] In one optional implementation, the performance testing parameters include at least the total running time of the parallel computing program, the parallel speedup ratio, the parallel efficiency, and the computational overhead. The performance test graph includes a graph showing the relationship between each performance test parameter and the number of cores.

[0109] In an optional implementation, the scheduling module 603 is further configured to: If the instantiation script fails to be submitted, the instantiation script shall be resubmitted at a preset time interval. If the number of consecutive submission failures within a preset time interval reaches the first preset number, then the preset time interval is increased and the process returns to the step of resubmitting the instantiated script according to the preset time interval, until the total number of consecutive submission failures reaches the second preset number or the submission is successful.

[0110] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0111] Based on the same technical concept, embodiments of this application also provide a computer device. (Refer to...) Figure 7 The diagram shown is a structural schematic of a computer device provided in an embodiment of this application, comprising: The system comprises a processor 701, a memory 702, and a bus 703. The memory 702 stores machine-readable instructions executable by the processor 701. The processor 701 executes these machine-readable instructions, and when executed, performs the following steps: S101: Obtain a parameter configuration file for the computation job; S102: Load a target script template matching the parameter configuration file from batch processing script templates corresponding to various parallel computing cluster types, and instantiate the target script template using the parameter configuration file to obtain an instantiated script; S103: Through the instantiated script, schedule the parallel computing program indicated by the parameter configuration file and the computing resources in the parallel computing cluster to execute the computation job, and collect initial performance monitoring data during job execution; the initial performance monitoring data includes at least job execution status and cluster resource usage; and S104: Based on the initial performance monitoring data, generate performance test results of the parallel computing program under the parallel computing cluster.

[0112] The aforementioned memory 702 includes a main memory 7021 and an external memory 7022. The main memory 7021, also known as internal memory, is used to temporarily store the computational data in the processor 701, as well as the data exchanged with external memory such as a hard disk 7022. The processor 701 exchanges data with the external memory 7022 through the main memory 7021. When the computer device is running, the processor 701 and the memory 702 communicate through the bus 703, so that the processor 701 executes the execution instructions mentioned in the above method embodiments.

[0113] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the parallel computing performance detection method described in the above-described method embodiments. The storage medium can be a volatile or non-volatile computer-readable storage medium.

[0114] This application also provides a computer program product, which carries program code. The instructions included in the program code can be used to execute the steps of the parallel computing performance detection method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0115] The computer program product can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0116] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interface; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0119] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0120] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the user through pop-up information or by asking the user to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

[0121] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for detecting parallel computing performance, characterized in that, The method includes: Obtain a parameter configuration file for the computing job; the parameter configuration file includes first parameter information and second parameter information, the first parameter information including at least parallel computing cluster type information, first path information of the parallel computing program, second path information of the computing job, output directory information of the computing results, and runtime environment information; the second parameter information is used to indicate multiple test instance information for the parallel computing program; different test instance information is used to indicate at least different core count limits of the parallel computing program; From batch processing script templates corresponding to various parallel computing cluster types, a target script template matching the parameter configuration file is loaded, and the target script template is instantiated using the parameter configuration file to obtain an instantiated script. The batch processing script template is used to control the execution of computing jobs and collect performance data during job execution. The target script template is determined based on the target parallel computing cluster type indicated by the parallel computing cluster type information and the job scheduling system indication information. The job scheduling system indication information is determined based on the cluster operating environment of the target parallel computing cluster type. The instantiated script includes instantiated scripts corresponding to multiple test instance information. The instantiated script executes the computing job using the parallel computing program indicated by the scheduling parameter configuration file and the computing resources in the parallel computing cluster, and collects initial performance monitoring data during the job execution process; the initial performance monitoring data includes at least the job execution status and cluster resource usage. Based on the initial performance monitoring data, a performance test result of the parallel computing program under the parallel computing cluster is generated; the performance test result is determined based on the performance test parameters of the parallel computing program under different instantiation scripts, and the performance test parameters are calculated based on the initial performance monitoring data. The entire process from obtaining the parameter configuration file to generating the performance test results is completed by the central control and scheduling program. The central control and scheduling program is also used to monitor the entire process in real time, and when an abnormality is detected in any part of the entire process, it terminates the execution of the current process and generates information containing the error type and a detailed description for output.

2. The method according to claim 1, characterized in that, The process of loading a target script template that matches a parameter configuration file from batch processing script templates corresponding to various parallel computing cluster types, and instantiating the target script template using the parameter configuration file to obtain an instantiated script, includes: Based on the parallel computing cluster type information, determine the target parallel computing cluster type used by the computing job; Based on the job scheduling system used for the target parallel computing cluster type and the correspondence between the job scheduling system and the batch processing script template, the target script template is loaded from a variety of batch processing script templates; Multiple parameter dictionaries are generated using the test instance information indicated by the first parameter information and the second parameter information; The target script template is instantiated using each of the parameter dictionaries to obtain instantiated scripts corresponding to multiple test instance information.

3. The method according to claim 2, characterized in that, The process involves executing the computation job through the instantiated script, the parallel computing program indicated by the scheduling parameter configuration file, and the computing resources in the parallel computing cluster, and collecting initial performance monitoring data during job execution, including: For any instantiated script, the instantiated script is submitted to the job scheduling system via a job submission command, and the instantiated script is run if the submission is successful. By running the instantiated script, the parallel computing program indicated by the first path information and the computing resources in the parallel computing cluster are scheduled to execute computing jobs according to the test instance information corresponding to the instantiated script, and initial performance monitoring data is collected during the job execution process.

4. The method according to claim 3, characterized in that, The step of generating performance test results for the parallel computing program under the parallel computing cluster based on the initial performance monitoring data includes: For any instantiated script, the performance detection parameters of the parallel computing program under the instantiated script are determined based on the initial performance monitoring data collected when the instantiated script is run and the number of cores indicated by the test instance information corresponding to the instantiated script. Based on the performance detection parameters of the parallel computing program under each instantiation script, generate a performance detection report and / or performance detection graph corresponding to the parallel computing program. The performance test report and / or performance test graph shall be used as the performance test result.

5. The method according to claim 4, characterized in that, The performance testing parameters include at least the total running time of the parallel computing program, the parallel speedup ratio, the parallel efficiency, and the computational overhead. The performance test graph includes a graph showing the relationship between each performance test parameter and the number of cores.

6. The method according to claim 3, characterized in that, The method further includes: If the instantiation script fails to be submitted, the instantiation script shall be resubmitted at a preset time interval. If the number of consecutive submission failures within a preset time interval reaches the first preset number, then the preset time interval is increased and the process returns to the step of resubmitting the instantiated script according to the preset time interval, until the total number of consecutive submission failures reaches the second preset number or the submission is successful.

7. A device for testing parallel computing performance, characterized in that, The device includes: The acquisition module is used to acquire a parameter configuration file for the computing job; the parameter configuration file includes first parameter information and second parameter information, the first parameter information including at least parallel computing cluster type information, first path information of the parallel computing program, second path information of the computing job, output directory information of the computing results, and runtime environment information; the second parameter information is used to indicate multiple test instance information for the parallel computing program; different test instance information is used to indicate at least different core count limits of the parallel computing program; A loading module is used to load target script templates that match parameter configuration files from batch processing script templates corresponding to various parallel computing cluster types, and to instantiate the target script templates using the parameter configuration files to obtain instantiated scripts. The batch processing script templates are used to control the execution of computing jobs and collect performance data during job execution. The target script templates are determined based on the target parallel computing cluster type indicated by the parallel computing cluster type information and job scheduling system indication information. The job scheduling system indication information is determined based on the cluster operating environment of the target parallel computing cluster type. The instantiated scripts include instantiated scripts corresponding to multiple test instance information. The scheduling module is used to execute the computing job through the instantiated script, the parallel computing program indicated by the scheduling parameter configuration file, and the computing resources in the parallel computing cluster, and to collect initial performance monitoring data during the job execution process; the initial performance monitoring data includes at least the job execution status and the cluster resource usage status. A generation module is used to generate performance test results of the parallel computing program under the parallel computing cluster based on the initial performance monitoring data; the performance test results are determined based on the performance test parameters of the parallel computing program under different instantiation scripts, and the performance test parameters are calculated based on the initial performance monitoring data; The entire process from obtaining the parameter configuration file to generating the performance test results is completed by the central control and scheduling program. The central control and scheduling program is also used to monitor the entire process in real time, and when an abnormality is detected in any part of the entire process, it terminates the execution of the current process and generates information containing the error type and a detailed description for output.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1 to 6.

Images