Code data conversion method, system and electronic device

By combining pre-trained models and code correctness verification logic, the problems of low accuracy and efficiency in code conversion are solved, realizing automated conversion from old code to graphics processor code, and improving the accuracy and efficiency of conversion.

CN122285015APending Publication Date: 2026-06-26INSPUR SUZHOU INTELLIGENT TECH CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
INSPUR SUZHOU INTELLIGENT TECH CO LTD
Filing Date
2026-05-26
Publication Date
2026-06-26

AI Technical Summary

Technical Problem

Existing technologies for code conversion are inaccurate and inefficient, especially when converting older code languages ​​into code that supports graphics processors. Reliance on manual adjustments and pre-trained models cannot adapt to different forms of code conversion, resulting in low conversion efficiency.

Method used

By acquiring the source code data to be converted, the first and second pre-trained models are used for conversion and verification. Combined with code correctness verification logic and conversion rollback operation, the code conversion process is automated, improving accuracy and efficiency.

Benefits of technology

It improves the accuracy and efficiency of code conversion, and realizes the automated conversion from old code to graphics processor code, adapting to different types of code conversion needs.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122285015A_ABST
    Figure CN122285015A_ABST
Patent Text Reader

Abstract

This application discloses a code data conversion method, system, and electronic device, relating to the field of high-performance computing technology. The code data conversion method of this application uses a pre-trained model fine-tuned based on different training sets to convert code data of different forms, improving the accuracy of code conversion. Furthermore, this application provides code correctness verification logic; in the event of verification failure, a conversion rollback operation is added, enabling automatic execution of code conversion and improving efficiency. Therefore, this application can solve the technical problems of low conversion accuracy and inefficiency, achieving the technical effect of improving both the efficiency and accuracy of code conversion.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of high-performance computing technology, and in particular to a code data conversion method, system, and electronic device. Background Technology

[0002] In the field of high-performance computing, many critical scientific computing and engineering application software programs are written in older code languages. With the rapid development of computer hardware architecture, current computing platforms are shifting towards heterogeneous computing architectures consisting of central processing units (CPUs) and graphics processing units (GPUs), which provide computational acceleration for high-performance computing. However, it is necessary to convert software written in older code languages ​​into code that supports GPUs. In related technologies, the code conversion process heavily relies on manual intervention; some solutions rely on pre-trained models for code conversion, however, pre-trained models cannot adapt to different forms of code conversion, affecting the accuracy of the conversion; and when accuracy is low, manual adjustments are still required, reducing the efficiency of the code conversion. Summary of the Invention

[0003] This application provides a code data conversion method, system, and electronic device to at least solve the problems of low accuracy and low efficiency in code conversion in related technologies.

[0004] This application provides a code data conversion method, including:

[0005] Obtain the source code data to be converted;

[0006] The source code data is transformed by the first pre-trained model of the first transformation agent to obtain the first transformed data;

[0007] The first verification agent verifies the code correctness of the first converted data to obtain a first verification result.

[0008] If the first verification result is passed, the second pre-trained model of the second conversion agent identifies the parallelism of the first conversion data and converts the first conversion data to obtain the second conversion data;

[0009] If the first verification result is a failure, the first pre-trained model is updated according to the first verification result, and the first pre-trained model of the first conversion agent is returned to convert the source code data to obtain the first converted data. The source code data is then converted again until the first converted data with the first verification result is obtained, and the second converted data is obtained based on the first converted data with the first verification result being obtained.

[0010] If both the second verification result and the performance evaluation result for the second transformed data are passed, the second transformed data will be used as the target code data.

[0011] This application also provides a code data conversion system, including:

[0012] The acquisition module is used to acquire the source code data to be converted;

[0013] The first conversion module is used to convert the source code data using the first pre-trained model of the first conversion agent to obtain the first converted data;

[0014] The first verification module is used to verify the code correctness of the first converted data through a first verification agent and obtain a first verification result.

[0015] The second conversion module is used to identify the parallelism of the first conversion data and convert the first conversion data to obtain the second conversion data if the first verification result is passed;

[0016] The rollback module is used to update the first pre-trained model according to the first verification result if the first verification result is a failure, and return to the first conversion module to re-convert the source code data until the first converted data with the first verification result is a pass is obtained, and the second converted data is obtained based on the first converted data with the first verification result being a pass.

[0017] The performance optimization module is used to use the second converted data as target code data if both the second verification result and the performance evaluation result for the second converted data are passed.

[0018] This application also provides an electronic device, including a memory and a processor.

[0019] The memory stores a computer program, and the processor is configured to run the computer program to perform the code data migration method described above.

[0020] This application utilizes a pre-trained model fine-tuned based on different training sets to convert code data of various formats, thereby improving the accuracy of code conversion. Furthermore, this application provides code correctness verification logic; in the event of verification failure, a conversion rollback operation is added, enabling automatic execution of code conversion and improving efficiency. Therefore, this application can solve the technical problems of low conversion accuracy and inefficiency, achieving the technical effect of improving both the efficiency and accuracy of code conversion. Attached Figure Description

[0021] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 A flowchart illustrating a code data conversion method provided in an embodiment of this application;

[0023] Figure 2 A flowchart illustrating another code data conversion method provided in an embodiment of this application;

[0024] Figure 3 A schematic diagram illustrating the fine-tuning process of a keyword-based pre-trained model provided in this application embodiment;

[0025] Figure 4 A schematic diagram of the inference process of a pre-trained model based on prompt words provided in an embodiment of this application;

[0026] Figure 5 This is a schematic diagram of the code conversion process based on the function system provided in an embodiment of this application;

[0027] Figure 6 A schematic diagram illustrating a code conversion process based on a workflow management system, provided as an embodiment of this application;

[0028] Figure 7 This is a schematic diagram of the structure of the code conversion system provided in the embodiments of this application.

[0029] The above figures refer to the following reference numerals:

[0030] 810. Acquisition Module; 820. First Conversion Module; 830. First Verification Module; 840. Second Conversion Module; 850. Rollback Module; 860. Performance Optimization Module. Detailed Implementation

[0031] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0032] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0033] The terms used in this application include:

[0034] HPC stands for High Performance Computing.

[0035] CPU, Central Processing Unit;

[0036] GPU, Graphics Processing Unit;

[0037] FORTRAN, Formula Translation, was an early formula translation language used for scientific computing.

[0038] CESM, Community Earth System Model;

[0039] CUDA, Compute Unified Device Architecture, is a unified computing device architecture, such as a programming model for GPUs.

[0040] HIP C++, Heterogeneous-Compute Interface for Portability;

[0041] OneAPI is a cross-architecture development tool suite that unifies programming models for CPUs, GPUs, FPGAs, and more.

[0042] SYCL, an open standard programming model released by the Khronos Group;

[0043] DAG, Directed Acyclic Graph;

[0044] LLM stands for Large Language Model.

[0045] Pegasus is a workflow-based orchestration tool for HPC scientific computing.

[0046] In the field of high-performance computing (HPC), a large number of application software programs are written in the outdated Fortran language, and these programs typically have massive codebases. However, with the rapid development of computer hardware architecture, modern supercomputing platforms have generally shifted to heterogeneous computing architectures composed of central processing units (CPUs) and graphics processing units (GPUs). This new architecture can provide unprecedented computational acceleration for thousands of HPC applications, and most scientific computing software code now supports GPU-accelerated computing, including molecular dynamics simulations, drug discovery, weather forecasting, and materials simulation. Fortran code written for traditional CPU architectures cannot directly and efficiently utilize the parallel processing capabilities of GPUs. Completely rewriting this outdated Fortran code to support GPUs is an extremely time-consuming task requiring deep expertise in device parallel programming.

[0047] Based on this, this application provides a code data conversion method, system, and electronic device. By fine-tuning a pre-trained model based on different training sets, different forms of code data can be converted, improving the accuracy of code conversion. In addition, this application provides code correctness verification logic. If the verification fails, a conversion rollback operation is added to realize the automatic execution of code conversion and improve the efficiency of code conversion.

[0048] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] Reference Figure 1 and Figure 2 As shown, this application provides a code data conversion method, including:

[0050] Step S100: Obtain the source code data to be converted;

[0051] Step S200: The source code data is transformed by the first pre-trained model of the first transformation agent to obtain the first transformed data;

[0052] Step S300: The first verification agent verifies the code correctness of the first transformation data and obtains the first verification result;

[0053] Step S400: If the first verification result is passed, the second pre-trained model of the second conversion agent identifies the parallelism of the first conversion data and converts the first conversion data to obtain the second conversion data;

[0054] Step S500: If the first verification result is a failure, update the first pre-trained model according to the first verification result, and return to the step of converting the source code data through the first pre-trained model of the first conversion agent to obtain the first converted data. Then, convert the source code data again until the first converted data with the first verification result is obtained, and obtain the second converted data based on the first converted data with the first verification result being a success.

[0055] Step S600: If both the second verification result and the performance evaluation result for the second transformed data are passed, the second transformed data is used as the target code data.

[0056] This application sets up corresponding pre-trained models based on the types of the two codes to be converted, in order to adapt to the characteristics of the two codes to be converted. Specifically, refer to... Figure 3 As shown, the first pre-trained model is fine-tuned using a first training set representing the correspondence between source code data and first transformed data; the second pre-trained model is fine-tuned using a second training set representing the correspondence between the first and second transformed data. This application improves the inference accuracy of the pre-trained models by fine-tuning them with different training sets, thereby enhancing the correctness of code transformation.

[0057] This application verifies the correctness of the first converted data through first compilation verification and first runtime verification. The first compilation verification determines that the first converted data is syntactically correct and conforms to standards, while the first runtime verification verifies the functional consistency between the first converted data and the source code data. Identifying the parallelism of the first converted data involves identifying the parallelizable parts within it. The second converted data contains parallel algorithms reconstructed based on this parallelism. This application proactively identifies parallel loops in the data and reconstructs the code to match the memory hierarchy of the hardware platform through parallelism identification. Based on the identified parallelizable parts, this application performs code conversion on the first converted data to achieve parallel execution of the target code data on the hardware platform.

[0058] If the first verification result fails, the pre-trained model is updated to re-transform the source code data until a second transformed data that meets the requirements is obtained. It is understood that the re-transformation of source code data, the verification of the second transformed data, and the performance evaluation in this application are not implemented through any one of the first transformation agent, the second transformation agent, or the first verification agent. This application's embodiments achieve automatic code transformation, improve the accuracy of code transformation through a fine-tuned pre-trained model, and automate the execution of code transformation through process design, alleviating the reliance on manual intervention in related technologies and improving the efficiency of code transformation.

[0059] The embodiments of this application provide a code data conversion method, and the method is described in detail in conjunction with the execution flow of the method.

[0060] Optionally, the source code data is transformed using a first pre-trained model of the first transformation agent to obtain first transformed data, including:

[0061] The first prompt word and source code data are input into the first pre-trained model to transform the source code data, resulting in the first transformed data. The first prompt word includes one or more of the keywords, instruction information, and the desired format of the first transformed data from the source code data.

[0062] In some embodiments, refer to Figure 4 As shown, the code conversion process based on the first prompt word is as follows: the source code data is segmented and preprocessed to obtain code units; a first prompt word based on the code unit is constructed; the code unit and the corresponding first prompt word are input into the first pre-trained model to convert the code unit, resulting in the first converted data of the code unit. Specifically, before the first pre-trained model performs inference on the source code data, syntactic keywords, semantic keywords, structural information, etc., of the source code data are extracted and written into the first prompt word. That is, the first prompt word in this application includes keywords of the source code data, instruction information, and the expected format of the first converted data. Keywords in this application include syntactic keywords and semantic keywords. Syntactic keywords are used to remind the first pre-trained model of code conversion, and code conversion is performed based on these syntactic keywords. Instruction information may be requirements such as indexes in the conversion process and precision of numerical calculations. The format of the first converted data may be code conforming to a certain standard. The first prompt word in this application is not used to change the model parameters of the first pre-trained model. Of course, those skilled in the art can set the first prompt word according to actual needs to improve the prediction accuracy of the first pre-trained model and significantly improve the accuracy of translation and code quality.

[0063] Understandably, the second pre-trained model also has a corresponding first prompt word, which is the same as that of the first pre-trained model. Furthermore, the first prompt word of the second pre-trained model also includes the parallelizable part of the first transformed data. The first prompt word of the second pre-trained model improves the accuracy of its code transformation of the parallelizable part.

[0064] Optionally, before transforming the source code data using the first pre-trained model of the first transforming agent to obtain the first transformed data, the method further includes:

[0065] If the amount of source code data is greater than or equal to the first preset amount, one or more of the first conversion agent, the first verification agent, and the second conversion agent are encapsulated into an executable instruction set, and one or more of the first conversion data, the first verification result, the second verification result, the second conversion data, and the performance evaluation result are set as an executable instruction set;

[0066] If the amount of source code data is less than the first preset amount, one or more of the first transformation agent, the first verification agent, and the second transformation agent are deployed at each node of the workflow management system.

[0067] In this application, the executable instruction set can be Python functions. The processing logic between various intelligent agents is implemented through the concatenation of Python functions. Specifically, refer to... Figure 5 As shown, each agent can be encapsulated as one or more Python functions. It should be noted that the executable instruction set in this application is pure functional programming. Data transfer between agents is achieved through function parameters and return values, which can be implemented using data structures; that is, the first transformed data, the first verification result, the second transformed data, etc., can be represented by data structures. (See reference...) Figure 6 As shown, the workflow management system can be a Pegasus system, ensuring the coordination and correctness of the entire process. This application embodiment selects different methods for process processing based on different scales of source code data, which can both meet user needs and improve conversion performance.

[0068] Optionally, before using the second transformed data as the target code data, the method further includes:

[0069] Parallel points in the second transformed data are identified using a third pre-trained model in a parallel agent;

[0070] Integrate parallel calls at parallel points to enable the target code data to be executed in parallel across multiple nodes.

[0071] A parallel agent is used to expand second transformation data from a single node into target code data that can be executed in parallel across multiple nodes in a cluster. Parallel points in this application are used to characterize code data that can be executed across multiple nodes in a cluster. This application identifies parallel points in the second transformation data using a third pre-trained model. This third pre-trained model is fine-tuned using a third training set, and the fine-tuning process of the third pre-trained model based on the third training set is the same as the fine-tuning process of the first pre-trained model based on the first training set. The third training set includes a third code pair, which includes one or more of parallel communication modes, parallel algorithms, and code integration methods. The code integration methods include the integration of parallel communication modes and computational code, and the integration of parallel algorithms and computational code. Specifically, identifying parallel points in the second transformation data using the third pre-trained model in the parallel agent includes: identifying the transformation portion that can be processed in a distributed manner by analyzing the code structure and data flow of the validated second transformation data; and identifying parallel points in the transformation portion.

[0072] This application integrates parallel calls at parallel points, including: inserting first parallel points at the beginning and end of the second transformed data; determining cyclic parallel points based on the current process encoding, and determining statistical parallel points based on the total number of processes; inserting parallel functions according to a parallel strategy; and inserting non-blocking parallel points where adjacent communication is required in the second transformed data. The parallel strategy can be determined based on the proportion of cross-node communication volume in the total data flow. Parallel strategies include task parallelism and data parallelism.

[0073] In this application, the parallel agent can seamlessly integrate the parallelization logic of the message passing interface with the computation logic of the second transformation data, generating a hybrid parallel program that can utilize GPU acceleration within a single node and perform distributed computation across nodes.

[0074] Optionally, updating the first pre-trained model based on the first validation result includes:

[0075] An error handling agent records error information during code correctness verification and integrates this information into a second prompt word. The error information includes one or more of the following: error type, error location, partial source code data, and error log.

[0076] The second prompt word is provided to the first conversion agent, which then inputs the second prompt word into the first pre-trained model to adjust the parameters or code conversion strategy of the first pre-trained model, thereby updating the first pre-trained model.

[0077] In this application, error information includes all error information in code correctness verification, including alarm information. In some embodiments, the second prompt word also includes error analysis based on the error information by the error handling agent, i.e., error prompt information, so that the first conversion agent can update the first pre-trained model based on the error analysis. Of course, the second prompt word also includes error information in the second conversion data verification process, so as to update the parameters or conversion strategy of the second pre-trained model through the first prompt word, thereby improving the inference accuracy of the second pre-trained model.

[0078] Optionally, after transforming the source code data using the first pre-trained model of the first transforming agent to obtain the first transformed data, the method further includes:

[0079] If the existence of a function determines that the first transformed data contains a preset mathematical function, the preset mathematical function in the first transformed data is transformed by the fourth pre-trained model of the mathematical function library agent to obtain the first transformed data after function transformation; wherein, the preset mathematical function is a mathematical function that is not included in the source code data and the first transformed data.

[0080] In this application, the preset mathematical functions are those not included in the source code data and the first transformed data, i.e., different from the basic mathematical functions. This application uses a fourth pre-trained model of a mathematical function library agent to perform function transformation on the preset mathematical functions in the first transformed data. It is understood that the fourth pre-trained model in this application is obtained through fine-tuning a fourth training set, and the fine-tuning method is the same as that of the first pre-trained model. The fourth training set contains a fourth code pair, which can be created using a third-party mathematical library. The function library for the source code data is created using a third-party mathematical library, corresponding to the function library for the first transformed data, and the fourth code pair is formed based on these two function libraries. It is understood that the function existence detection and mathematical function library agent in this application can also be used in the code transformation process from the first transformed data to the second transformed data; of course, the corresponding fourth training set needs to be updated accordingly. This application's embodiments use a mathematical function library agent to achieve function code transformation, improving the accuracy of code transformation.

[0081] Optionally, the first verification agent verifies the code correctness of the first transformed data to obtain a first verification result, including:

[0082] The first verification agent calls the compiler to perform the first compilation verification on the first transformed data, and obtains the first compilation result.

[0083] If the first compilation result is successful, the first transformed data is run on the first hardware platform based on the unit test cases and regression test cases to obtain the first running result;

[0084] The first verification result is determined based on the comparison between the first running result and the source code running result; wherein, the source code running result is the running result obtained by running source code data on the first hardware platform based on unit test cases and regression test cases.

[0085] The first compilation verification can be implemented using a compiler corresponding to the first transformed data. Specifically, the first verification agent determines the verification compiler based on a preset configuration or the detected system environment; the preset configuration is related to user requirements and the deployed hardware platform. The first verification agent constructs compilation commands and executes them on the verification compiler to compile the first transformed data, obtaining the compilation output. The first verification agent parses the compilation output to obtain the first compilation result. If the first compilation fails, the second verification result also records error information.

[0086] If compilation is successful, the first compilation result is considered passed, and the first verification agent performs runtime verification on the first transformed data. Specifically, runtime verification includes unit testing and regression testing, using constructed test cases to achieve runtime verification of the first transformed data. The first running result of this application is the result after executing the source code data with the input data, and the source code running result is the result after executing the first transformed data using the same input data. The comparison between the first running result and the source code running result in this application includes text comparison and numerical comparison. The numerical comparison can determine the first verification result by whether the difference between the two running results is within a preset difference range. If the comparison results corresponding to all test cases are acceptable, the first verification result is considered passed. Furthermore, the first verification result is considered passed only when both the first compilation verification and the first running verification results are passed. This application can achieve automated code correctness verification, providing a strong guarantee for the functional correctness of the code, and is an important step in ensuring that the final SYCL code can correctly reproduce the original application behavior.

[0087] Optionally, before transforming the source code data using the first pre-trained model of the first transforming agent to obtain the first transformed data, the method further includes:

[0088] Obtain open-source code data; identify source code data samples and first transformed data samples that implement the same function from the open-source code data to form a first code pair;

[0089] Alternatively, extract a first code sample containing keywords and having preset performance calculation characteristics from the source code data, generate a first conversion sample corresponding to the first code sample, and combine the first code sample and the first conversion sample to form a first code pair;

[0090] Obtain the pre-trained model trained on a general dataset, and fine-tune the pre-trained model using the first code to obtain the first pre-trained model.

[0091] Keywords are syntactic and semantic keywords for the source code data. Preset performance computation features are used to characterize the first transformed data with specific features, including one or more of the following: array dimension, loop pattern, and mathematical function calls. This application improves the inference accuracy of the first pre-trained model by fine-tuning it with first code, generating first transformed data that is more consistent with domain conventions, more efficient, and more reliable.

[0092] Optionally, if both the second verification result and the performance evaluation result for the second transformed data are passed, the second transformed data is used as the target code data. The method further includes:

[0093] The second verification agent performs second compilation verification and second running verification on different hardware platforms to obtain the second verification result.

[0094] If the second verification result is passed, the performance evaluation agent performs a performance evaluation on the compilation and execution process of the second transformed data to obtain the performance evaluation result.

[0095] If the second verification result is unsuccessful, the second pre-trained model is updated based on the second verification result, and the second pre-trained model of the second conversion agent is returned to convert the first conversion data to obtain the second conversion data. The first conversion data is then converted again until the second conversion data with the second verification result is obtained.

[0096] In this application, the second pre-trained model converts the serial first transformation data into parallel second transformation data. Due to the difference between the first and second transformation data, this application verifies the code correctness of the second transformation data by compiling and running it on different hardware platforms. This application performs a second compilation verification and a second execution verification on the second transformation data; the second verification result is considered passed only if both the second compilation verification and the second execution verification are successful.

[0097] In this application, the performance evaluation agent can evaluate the second compilation verification and second runtime verification process of the second converted data, and can also evaluate the execution process of the second converted data. In some embodiments, the preset performance of the second converted data can be compared with the preset performance of source code data under the same execution conditions to obtain a performance evaluation result. The preset performance includes one or more of kernel execution time, memory bandwidth utilization, kernel utilization, and data transfer overhead. This application facilitates subsequent performance optimization through performance evaluation results, thereby improving the running performance of the code conversion system.

[0098] Optionally, a second verification agent performs second compilation verification and second runtime verification on the second transformed data on different hardware platforms to obtain a second verification result, including:

[0099] The second verification agent compiles and runs the second transformation data on the first hardware platform to obtain the first sub-verification result;

[0100] If the first sub-verification result is passed, the second verification agent compiles and runs the second transformation data on the second hardware platform to obtain the second verification result.

[0101] The first hardware platform can be a CPU. First, a second compiler corresponding to the second converted data is determined. The second compiler is used to compile and run the second converted data with the CPU as the backend, obtaining a first sub-verification result. Logical errors in the second converted data are quickly discovered and debugged using the first hardware platform. If the first sub-verification result is pass / success, the second converted data is compiled and run on the second hardware platform. The second verification result is obtained by comparing the second converted data compiled and run on the second hardware platform with the source code data. In some embodiments, multiple second hardware platforms can be set up, and the second converted data is compiled and run on different second hardware platforms. When the compilation and running results of the second converted data on all second hardware platforms are pass, the second verification result is pass. This application ensures the portability and reliability of the generated SYCL code by compiling and running the second converted data on different hardware platforms.

[0102] Optionally, the second training set includes a second code pair. Before identifying the parallelism of the first transformation data and transforming the first transformation data using the second pre-trained model of the second transformation agent to obtain the second transformation data, the method further includes:

[0103] The loop data of the first transformation data is converted into the loop kernel of the second transformation data to obtain a parallel loop code pair;

[0104] The operation data of the first transformed data is converted into the operation object of the second transformed data to obtain the reduction operation code pair;

[0105] The serial scanning algorithm data of the first converted data is converted into the parallel scanning kernel of the second converted data to obtain the scanning code pair;

[0106] The network computing mode of the first transformed data is converted into the network kernel of the second transformed data to obtain a network computing code pair;

[0107] A second code pair is generated based on one or more of the parallel loop code pair, the reduction operation code pair, the scan code pair, and the network computation code pair.

[0108] This application's embodiments fine-tune a second pre-trained model using a second code pair, enabling the second pre-trained model to learn the mode conversion from serial thinking to device parallel thinking, achieving code conversion and refactoring to generate second converted data that can be compiled and run on device parallel results. The fine-tuning process of the second pre-trained model based on the second training set in this application is the same as the fine-tuning process of the first pre-trained model based on the first training set. The second pre-training set is constructed using the second code pair, which includes a portion of the parallel computing mode for high-performance computing. In embodiments where the first converted data is C++, the loop data can be a for loop, and the operation data can be data representing operations such as summation and finding the maximum value. This application uses the second code pair to achieve supervised fine-tuning of the second pre-trained model, enabling the second pre-trained model to learn the conversion from serial thinking to parallel thinking, achieving code refactoring, and providing a foundation for subsequent performance optimization.

[0109] Optionally, before identifying the parallelism of the first transformation data and transforming the first transformation data using the second pre-trained model of the second transformation agent to obtain the second transformation data, the method further includes:

[0110] The second conversion agent performs static analysis on the first conversion data to identify whether the cyclic part in the first conversion data is data parallel, marks the data parallelizable cyclic part as hotspot information, and extracts the context information of the data parallelizable cyclic part; wherein, the context information includes one or more of the iteration range, computation logic and data structure of the cyclic part;

[0111] Hot topics and context are integrated into a third prompt word, which is then input into a second pre-trained model to identify the parallelism of the first transformation data.

[0112] This application's embodiments determine whether the loop portion of the first transformation data is data parallel by judging whether each iteration of the loop can be executed independently without interference. This can be specifically achieved through data flow analysis and dependency analysis techniques. This application uses a third prompt word to enable the second pre-trained model to identify the parallelism of the first transformation data and performs code conversion on the parallelizable portion of the first transformation data to generate the corresponding second transformation data.

[0113] In some embodiments, the first transformed data may be serial code data. The second transformed data is transformed using a second pre-trained model to obtain second transformed data. The second transformed data includes host code and a device kernel, and can be executed on a GPU. Specifically, the second transformed agent's second pre-trained model identifies the parallelism of the first transformed data and transforms the first transformed data to obtain the second transformed data, including:

[0114] The execution range of the second transformation data is determined based on the iteration space of the loop portion in the first transformation data; wherein, the execution range includes a one-dimensional parallel workspace or a multi-dimensional parallel workspace, and the workspace is the space for parallel data operations;

[0115] Map the preset data format in the first converted data to the storage space of the second converted data, and set the access mode of the storage space;

[0116] If the first transformed data includes first-cycle data that requires synchronization, the first-cycle data is converted into a group barrier or atomic operation of the second transformed data.

[0117] This application automatically transforms a serial first-transformation data, such as a C++ program, into a well-structured second-transformation data, such as a SYCL program, composed of host code and device kernel, through parallelism identification and parallelism-based code transformation, thereby realizing the computational migration from CPU to GPU.

[0118] Optionally, identifying parallel points in the second transformed data through a third pre-trained model in the parallel agent includes:

[0119] Static dependency analysis is used to identify data loop segments and calculate the computation-to-communication ratio of these segments.

[0120] Identify data access patterns and runtime hotspots through runtime instrumentation sampling;

[0121] The code abstract syntax tree is structurally matched with the parallel pattern library to obtain the parallel points.

[0122] Optionally, parallel calls are integrated at parallel points to enable the target code data to be executed in parallel across multiple nodes, including:

[0123] By calling the first parallel function, the second transformation data of the current parallel point is distributed to the other parallel points;

[0124] Alternatively, by calling the second parallel function, the second transformation data of the remaining parallel points can be collected and sent to the current parallel point;

[0125] Alternatively, by calling a third parallel function, the second transformation data from the remaining parallel points can be aggregated to the current parallel point.

[0126] This application achieves cross-node execution of the second transformation data through a parallel intelligent agent, thereby improving the efficiency and performance of code transformation. Those skilled in the art can set specific parallel strategies and parallel implementation processes according to their needs. This application does not impose detailed limitations on the identification of parallel points and the integrated parallel calling process.

[0127] Optionally, the method further includes integrating parallel calls at parallel points to enable the target code data to be executed in parallel across multiple nodes.

[0128] The performance optimization agent calls performance analysis tools to identify performance bottlenecks in the parallel process;

[0129] When the performance bottleneck is that the memory access rate of the hardware platform is less than the preset access rate, the performance optimization agent executes optimization strategies such as memory merging or memory sharing.

[0130] Alternatively, if the performance bottleneck is that the execution efficiency of the third pre-trained model is less than the preset execution efficiency, the algorithm or data structure of the third pre-trained model can be updated through a performance optimization agent.

[0131] Performance bottlenecks include one or more of the following: computational bottlenecks, memory bottlenecks, and communication bottlenecks. These bottlenecks are identified by a performance optimization agent that invokes performance analysis tools during parallel processing.

[0132] The execution data of each kernel is obtained for the second conversion data. The execution data is analyzed to identify computational bottlenecks. The execution data includes instruction execution efficiency and thread divergence data.

[0133] Obtain the memory access pattern of the second hardware platform. If a preset access behavior is identified based on the memory access pattern and the memory bandwidth utilization is greater than or equal to the utilization threshold, a memory bottleneck is detected. The preset access behavior includes non-merging access and excessive access.

[0134] Obtain the execution time of the preset communication behavior. If the execution time is greater than the preset time threshold, send the communication threshold. The preset time threshold is related to the total execution time of the system. The preset communication behavior includes one or more of the following: communication hotspot, message distribution, and the overlap between communication and computation.

[0135] After optimizing the system's performance, this application implements optimization suggestions and then calls various intelligent agents within the application to execute code conversion, verification, performance evaluation, and performance optimization processes until the performance reaches the preset target or continuous optimization fails to converge. This application's embodiments improve the execution efficiency of target code data through multi-level optimization.

[0136] Optionally, the error message can be integrated into a second prompt word, including:

[0137] By associating error messages with corresponding portions of source code data, we obtain associated information.

[0138] Error messages are obtained by analyzing error information through an error handling agent;

[0139] By integrating related information and error message information, a second prompt word is obtained.

[0140] Optionally, if the first compilation result is successful, before running the first transformed data on the first hardware platform based on unit test cases and regression test cases to obtain the first running result, the method further includes:

[0141] Obtain the first test case provided by the user; the first test case and the source code data are kept synchronized.

[0142] Alternatively, if the user does not provide the first test case, the test case generation agent can generate the second test case based on the input / output interfaces and code logic of the source code data.

[0143] Generate unit test cases and regression test cases based on the first test case or the second test case.

[0144] Optionally, the method further includes integrating parallel calls at parallel points to enable the target code data to be executed in parallel across multiple nodes.

[0145] The communication pattern of the second transformed data after integrated parallel invocation is analyzed by a parallel intelligent agent to obtain the communication results, and parallel optimization is performed based on the communication results, including:

[0146] Overlapping non-blocking parallel points and computational parallel points;

[0147] If the communication rate represented by the communication mode is greater than or equal to the preset rate, aggregate the parallel points corresponding to the communication mode;

[0148] Load balancing is performed on each parallel process based on its computational and data volume.

[0149] In this application, the parallel computing points are generated by a parallel agent for data computation. The preset rate is a set value, which can be adjusted according to actual needs. Load balancing can be achieved through a general load balancing strategy. This application's embodiments, through parallel optimization, ensure that the second transformed data not only functions correctly but also achieves superior performance in parallel execution, providing technical support for large-scale parallel computing.

[0150] The code data conversion method and detection method provided in this application are described in detail below with specific embodiments:

[0151] 1.1 Related industry technologies.

[0152] 1.1.1 Requirements for GPU acceleration and SYCL programming model.

[0153] To address the challenges of heterogeneous computing, the industry needs a programming model that can leverage GPU acceleration performance while maintaining good cross-platform portability. Common models include OpenACC, the open-source OpenCL, and SYCL. However, these models have not gained widespread adoption due to limitations in target audience and programming barriers. Among them, SYCL, with its development language and direct hardware-level support, is based on the open C++ standard and provides an ideal solution for application development across GPU architecture platforms. SYCL allows developers to write a single code file in modern C++ that can execute efficiently on various heterogeneous devices (including CPUs, GPUs, and FPGAs), thus breaking free from hardware vendor lock-in. Despite SYCL's powerful abstraction capabilities and performance potential, manually migrating millions of lines of legacy Fortran code to SYCL remains a daunting task. This requires not only proficiency in both Fortran and C++ but also a deep understanding of the original code's algorithmic logic, data structures, parallelization potential, and SYCL's programming paradigm. Therefore, developing a tool or method that can automate or semi-automate this transformation process is of vital strategic importance for unlocking the value of existing HPC application software, accelerating its application on modern GPU platforms, and improving research efficiency.

[0154] 1.1.2 Limitations of manual code porting and shortcomings of existing tools.

[0155] In related technologies, porting Fortran code to new platforms or languages ​​mainly relies on manual rewriting. This process is costly, time-consuming, and prone to errors. Some code conversion tools, often rule-based static converters, cannot handle the deep logic and parallel patterns inherent in HPC code.

[0156] 1.2 Prior art related to this invention.

[0157] 1.2.1 Related Technology 1: General Code Conversion Technology Scheme Based on LLM and Its Disadvantages.

[0158] One embodiment utilizes LLM to convert legacy code such as COBOL and Sybase into modern languages ​​like Python and Java. This embodiment uses the general idea of ​​LLM for code conversion, but it doesn't address specific challenges in the HPC field, such as the complexity of the Fortran language, GPU parallelization, and the uniqueness of the SYCL programming model. Another embodiment conveniently converts solid mechanics models written in Fortran into C++ code, enabling parallel execution on CPUs and GPUs. This embodiment is essentially a programming library or framework, requiring programmers to manually rewrite the code to use MATAR data structures, rather than a fully automated code conversion tool. Another embodiment proposes an AI workflow based on autonomous agents for converting Fortran code into Kokkos C++ code. This embodiment targets Kokkos output, not SYCL, and doesn't perform intermediate state decomposition or agent fine-tuning during the conversion process. Yet another embodiment proposes a multi-agent LLM-based approach to automate the Fortran-to-C++ conversion. These examples demonstrate the feasibility of using AI technology for Fortran to C++ conversion, but they do not cover subsequent conversion steps from C++ to SYCL, nor do they involve MPI parallelization and workflow-based system integration.

[0159] 1.2.2 Related Technology 2: Technical solutions and their disadvantages related to SYCL code conversion and HPC migration.

[0160] One embodiment describes how to migrate CUDA code to Data Parallel C++. Another embodiment focuses on how the compiler enables hardware acceleration resources by initiating tile replacement, which is related to SYCL's underlying optimizations. This tool takes CUDA code as input and cannot directly process Fortran source code. Regarding workflow management, Pegasus WMS (Workflow Management System) is a scientific workflow management system widely used in the HPC field, which can be used to orchestrate complex computational tasks. One embodiment proposes a source-to-source compiler and a domain-specific language, which together constitute a semi-automated performance engineering framework. This approach does not integrate LLM technology, nor does it provide an end-to-end conversion solution from Fortran to SYCL.

[0161] To address this, this application constructs an automated pipeline based on multi-agent and large language models (LLM) to convert HPC applications implemented in legacy Fortran code into SYCL C++ code, thus overcoming the following key limitations of related technical solutions: 1. Imbalance between generality and domain specificity: Addressing the specific needs of the HPC domain, such as parallelism identification and performance optimization. 2. Mismatch between source language and target model: Providing a crucial conversion path from Fortran to SYCL. 3. Lack of end-to-end integrated solution: Integrating multiple stages, including LLM-based Fortran to C++ conversion, C++ to SYCL conversion, MPI parallelization, performance optimization, and workflow-based orchestration, into a complete, automated pipeline.

[0162] The embodiments of this application address LLM fine-tuning strategies, Prompt projects based on syntax keywords, multi-agent collaborative pipeline architectures, iterative error handling and rollback mechanisms, and Pegasus-based HPC workflow orchestration in the HPC field. These features improve the automation and accuracy of the transformation, enhance the reliability of the generated SYCL code in terms of functionality and performance, and provide a practical path for the modernization of legacy HPC software assets.

[0163] 2.1 Overview of Multi-Agent Pipeline Architecture

[0164] 2.1.1 System overall design concept.

[0165] This application provides an automated pipeline architecture based on a multi-agent intelligent system, as shown in the attached figure. Figure 2 As shown, this application decomposes the code porting task into a series of smaller, more manageable subtasks, each handled by a dedicated, highly specialized Agent. The advantages of this architecture lie in its modularity, scalability, and robustness. Modularity allows each Agent to be developed, tested, and optimized independently, reducing the overall system complexity. Scalability allows for easy addition of new Agents in the future to support more programming models or optimization strategies. Robustness is ensured through Agent collaboration and error handling mechanisms; when a problem occurs at any stage, the system can intelligently roll back and retry instead of failing outright, thus significantly improving the success rate of the entire automated process.

[0166] First, the subtasks include syntax conversion, semantic preservation, parallelization identification, and performance optimization. Each agent focuses on solving a problem specific to a particular domain. For example, the Fortran-to-C++ agent focuses on resolving syntactic and fundamental semantic differences between the two languages, while the C++-to-SYCL agent focuses on identifying parallelizable code structures and mapping them to the SYCL programming model. Second, these agents do not work in isolation but are organically linked through a carefully designed central control and orchestration mechanism, forming a collaborative pipeline. Data (i.e., code) flows between agents, with each agent's output serving as the input for the next. More importantly, the system introduces feedback and iteration mechanisms. When an agent (such as the verification agent) detects a problem, the error handling agent intervenes, triggering rollback and retry processes, and can even provide feedback to upstream agents to guide their corrections. This closed-loop control design ensures the system's robustness and continuous improvement capabilities when facing complex and ever-changing real-world code.

[0167] 2.1.2 Central control and scheduling mechanism.

[0168] To effectively manage and coordinate the execution of multiple agents, the system requires a robust central control and orchestration mechanism. This invention proposes two implementation methods to adapt to different use cases and complexity requirements.

[0169] The first approach is functional chaining based on Python scripts. In this model, each Agent is encapsulated as an independent Python function or class. A master Python script is responsible for calling these functions sequentially and managing data transfer between them. This approach is simple, flexible, and easy to deploy and debug on a single machine or a small-scale cluster. Data can be transferred between Agents via function parameters, return values, or shared memory. Error handling is implemented using Python's exception handling mechanism; when a function throws an exception, the master script can catch the exception and decide whether to retry or rollback.

[0170] The second approach is the more powerful and scalable Pegasus workflow management system. Pegasus is a system specifically designed for executing complex scientific workflows in distributed computing environments such as HPC clusters and the cloud. Using Pegasus, the entire transformation process can be defined as a directed acyclic graph (DAG), where each node represents an agent's execution task, and edges represent dependencies between tasks. Pegasus handles task scheduling, resource allocation, data management, and fault tolerance. It intelligently distributes tasks to available compute nodes, handles data transfer between nodes, and automatically retryes tasks that fail. This approach is particularly suitable for handling large-scale codebases because it fully leverages the parallel processing capabilities of HPC clusters and provides robust fault tolerance and monitoring to ensure the successful completion of long-running transformation tasks.

[0171] 2.2 Detailed Explanation of Core Workflow

[0172] 2.2.1 Phase 1: Conversion and verification from Fortran to C++.

[0173] This phase is designed to convert the input Fortran source code into functionally equivalent C++ code (first conversion data). This phase is accomplished collaboratively by two agents: a Fortran-to-C++ conversion agent (first conversion agent) and a C++ code correctness verification agent (first verification agent). The conversion agent integrates a specially processed large language model (LLM, i.e., the first pre-trained model). This LLM is not only pre-trained on massive amounts of general-purpose code data but also fine-tuned using numerous Fortran and C++ code pairs (i.e., the first code pairs). These code pairs are reinforced with Fortran grammar keywords to learn the complex grammatical and semantic mappings between the two languages. The first conversion agent also employs Prompt engineering techniques, explicitly adding key Fortran grammar keywords (such as COMMON, EQUIVALENCE, DATA, GOTO, etc.) to the prompts provided to the LLM, in addition to the Fortran code snippet to be converted, to enhance the model's understanding and conversion capabilities for specific language structures. The C++ code generated by the conversion agent is then immediately fed into the verification agent. The primary task of the verification agent is compilation verification. It calls an industry-standard C++ compiler to compile the generated code, ensuring it is free of syntax errors. After successful compilation verification, the code enters the runtime verification phase. In this phase, the system automatically generates or utilizes existing unit and regression test cases to execute the newly generated C++ program on the CPU, comparing its output bit-by-bit with the output of the original Fortran program under the same input. Only when the functionality is completely identical is the conversion at this stage considered successful, and the generated C++ code is marked as "verified" and passed to the next stage. This closed-loop "conversion-verification" design ensures the quality of output at each step, laying a solid foundation for subsequent, more complex parallel conversions.

[0174] 2.2.2 Phase Two: Conversion and Verification from C++ to SYCL

[0175] After successfully obtaining functionally correct C++ code, the pipeline enters the second stage, converting this serial C++ code into SYCL code that can be executed in parallel on the GPU. This stage is handled by three closely cooperating agents: the C++-to-SYCL conversion agent (the second conversion agent), the SYCL code verification agent (the second verification agent), and the performance evaluation agent. The C++-to-SYCL conversion agent also integrates a specially optimized LLM. Unlike the LLM in the first stage, this model needs to be able to identify potential parallelism in the C++ code, such as identifying for loops that can be parallelized and data-parallel computation patterns. To this end, the LLM needs to be fine-tuned using a large number of C++ and SYCL code pairs (i.e., the second code pairs), learning how to map the serial structure of C++ to the parallel kernel of SYCL. The fine-tuning data comes from two main sources: existing open-source code containing both C++ and SYCL code, and other code from relevant platforms that implements common functionality using both C++ and SYCL. Then, the C++ and SYCL implementations that share common functionality are identified. These are segmented and mapped using scripting programs like Python, and then manually reviewed. Another source is given specific code functions, such as loop accumulation, reduction calculation, and matrix multiplication. Existing models are used to generate C++ and SYCL code respectively, which is then manually reviewed and used as a fine-tuning training dataset. These datasets are then used to perform full fine-tuning training on a pre-trained general-purpose LLM model. This allows the model to learn the C++ to SYCL mapping while maximizing the retention of the original model's general language capabilities. For example, a computationally intensive for loop might be converted into a parallel_for kernel, while data access patterns may need to be managed through SYCL's buffer and accessor mechanisms. For instance, a three-layer for loop in the code can be automatically converted into kernel code (parallel_for) with local_accessor optimization through the fine-tuned model.

[0176] The SYCL code generated by the conversion agent is then sent to the verification agent. This agent compiles and runs the SYCL code on both CPU and GPU devices to ensure that it produces correct results consistent with the original C++ code on different hardware backends. Once the SYCL code passes correctness verification, it is sent to the performance evaluation agent, which uses performance analysis tools to measure key performance indicators such as execution time, memory bandwidth utilization, and kernel execution efficiency of the SYCL code on the GPU. This performance data is recorded and compared with preset performance baselines or targets. Only when the code meets the requirements in both functionality and performance is this stage of conversion considered successful, preparing for the next stage of MPI parallelization and deep optimization.

[0177] 2.2.3 Phase Three: MPI Parallelization and Performance Optimization.

[0178] After obtaining functional SYCL code with GPU acceleration capabilities, the third stage of the pipeline focuses on achieving distributed parallel computing across multiple compute nodes and deeply optimizing overall performance. This stage is primarily accomplished by the MPI Parallelization Agent and the Performance Optimization Agent. The goal of the MPI Parallelization Agent is to extend the single-node SYCL application to a multi-node application. It analyzes the code structure and data flow, integrates MPI calls into the SYCL code to achieve multi-node parallelism, and finally identifies the parts that can be processed in a distributed manner.

[0179] In some embodiments, the parallel identification process of this application adopts a three-layer architecture of static analysis, dynamic sampling, and domain knowledge fusion: First, static dependency analysis identifies data-parallel loops without loop-carried dependencies and calculates the computation / communication ratio of each code segment; second, for areas uncertain in static analysis, lightweight runtime instrumentation sampling (i.e., injecting conditional compilation probes into critical execution paths to dynamically capture data access patterns and execution hotspots with less than 5% performance overhead) is used to obtain actual data access patterns and execution hotspots; finally, the code abstract syntax tree is structurally matched with a pre-built parallel pattern library. The Agent further constructs a cross-kernel data flow dependency graph and executes a graph partitioning algorithm. If the cross-node communication volume is less than 20% of the total data flow volume, it is marked as graph-partitionable, and a task parallelism strategy is preferred over a data parallelism strategy. The identification results are output as a feasibility score (0-100), and an MPI process topology mapping suggestion and load balancing prediction report are automatically generated.

[0180] For example, for large-scale data parallel problems, the agent can automatically insert MPI (Message Passing Interface) calls at critical loops or data partitioning points in the code, such as calling MPI_Scatter (the first parallel function) to distribute data to each node, or calling MPI_Gather (the second parallel function) to collect data, or calling MPI_Reduce (the third parallel function) to summarize the computation results of each node.

[0181] The agent also needs to consider load balancing and communication optimization between nodes to minimize communication overhead and maximize parallel efficiency. After MPI parallelization, the performance optimization agent will perform a comprehensive performance profiling and optimization of the entire application, proposing and implementing optimization suggestions by analyzing performance bottlenecks. The agent first uses a performance analysis tool (profiler) to identify performance bottlenecks in the application, which may exist in multiple aspects such as computation, memory access, and communication. For the identified bottlenecks, the agent will take a series of optimization measures. For example, if it finds that the GPU kernel's memory access pattern is poor, the agent may suggest and implement optimization strategies such as memory coalescing or utilizing shared memory. If it finds that the algorithm itself has efficiency problems, the agent may even leverage the capabilities of LLM to propose more efficient algorithm or data structure replacement schemes. The ultimate goal of this stage is to generate a high-performance SYCL application that can run efficiently on a single GPU and achieve good scalability across thousands of GPUs through MPI.

[0182] 2.2.4 Iteration and rollback mechanism.

[0183] To ensure the robustness of the entire conversion pipeline and the high quality of the final output, this application provides an iteration and rollback mechanism. While the data flow is unidirectional, a reverse feedback flow is introduced during error handling. This mechanism is uniformly managed and executed by the error handling and iterative optimization agent (error handling agent), which continuously monitors the execution status and output of each agent. When any agent encounters an error or failure during execution, the error handling agent immediately captures the error signal. Subsequently, it initiates a pre-defined rollback process. The goal of the rollback is to restore the current task's state to the previous known, successful stable state. For example, if the C++-to-SYCL agent fails to convert, the system will roll back to the C++ code successfully verified by the C++ Verification Agent. During the rollback, the error handling agent records detailed error information, including the error type, location, relevant input code snippets, and system logs. These error logs are crucial for subsequent iterative optimization. After rolling back to a stable state, the system does not simply give up but can attempt self-repair. For example, the error handling agent can dynamically adjust the prompt or LLM parameters for subsequent attempts based on error logs, or select different transformation strategies. For instance, in the above embodiment, the triple for loop is converted to SYCL code using local_accessor acceleration. It's possible that compilation of the converted SYCL might fail due to platform incompatibility with the local_accessor attribute (e.g., an outdated compiler version). The LLM can then regenerate the prompt based on this information: "...When compiling the SYCL optimized based on local_accessor, the system reported an error indicating that local_accessor is not recognized, suggesting an older compiler version. I need to revert to SYCL code that does not use local_accessor...". Then, the failed agent is restarted. This iterative cycle of "try-failure-revert-try again" allows the system to learn from errors and gradually converge to a successful solution. This mechanism greatly enhances the system's automation and success rate, reducing the risk of the entire transformation project being interrupted due to a single step failure.

[0184] 2.3 Design and implementation of the core Agent module.

[0185] 2.3.1 Fortran-to-C++ Agent conversion.

[0186] 2.3.1.1 LLM-based code translation core.

[0187] The underlying architecture of the first pre-trained model in this application can be a Transformer-based model. These general-purpose models have been pre-trained on a large amount of code data and already possess basic code understanding and generation capabilities. Based on the differences between Fortran and C++ in paradigms, memory models, and programming habits, as well as the differences in handling data structures (such as multidimensional arrays and common blocks) and computational modes (such as vectorized operations) specific to high-performance computing (HPC), this application enhances the translation capabilities of the first pre-trained model in a specific domain through fine-tuning and prompt engineering.

[0188] The workflow of the first translation agent is as follows: First, it divides and preprocesses the input Fortran source code, for example, splitting large files into function or subroutine-level code units to facilitate LLM processing. Then, for each code unit, the system constructs a carefully designed Prompt. This Prompt not only contains the Fortran code to be translated but also a series of instructions and contextual information to guide the LLM in generating the desired C++ code. For example, the Prompt might explicitly state, "Please convert XX code to C++ code conforming to the XX standard." In this way, the LLM translation process is placed within a clear framework, greatly improving the quality and consistency of the output code. After translation, the agent performs preliminary post-processing on the generated C++ code, such as formatting the code and checking and fixing obvious syntax inconsistencies, before passing it to the next verification agent.

[0189] 2.3.1.2 LLM fine-tuning strategy for HPC field.

[0190] Fine-tuning of the first pre-trained model was achieved using a dataset of Fortran-C++ code pairs, i.e., the first training set. This dataset needed to cover various typical patterns and structures of HPC applications. This dataset should primarily come from the following sources: First, collect and organize open-source scientific computing libraries and applications. These projects typically provide both Fortran and C / C++ versions, or high-quality parallel corpora (i.e., multiple possible code pairs generated based on Fortran syntax keywords) can be obtained through manual porting. Second, a large number of synthetic code pairs can be generated based on Fortran syntax keywords, such as `do` in Fortran paired with `for` in C++. Fortran code categorized by Fortran syntax keywords and possessing specific HPC characteristics (e.g., including arrays of different dimensions, various loop patterns, mathematical function calls, etc.) is automatically generated by writing programs. This Fortran code is then manually or semi-automatically converted into equivalent, optimized C++ code by experts in the HPC field. This synthetic data effectively covers various boundary cases and complex syntactic structures. During fine-tuning, a supervised learning method is used, with Fortran code as input and the corresponding C++ code as the target output to train the LLM. The training objective is to minimize the difference between the generated code and the target code. In this way, LLM can learn the precise correspondence between Fortran and C++ in the HPC context, thereby generating more domain-compliant, efficient, and reliable C++ code during translation.

[0191] 2.3.1.3. Enhancement of Prompt project based on Fortran syntax keywords.

[0192] As attached Figure 3 As shown, Prompt engineering is a technique that guides a model to produce better output by designing input prompts without changing the model parameters. For code translation tasks, this means that before Fortran code is input into the LLM, the system automatically analyzes the code, extracts key syntactic and semantic information, and incorporates this information into the Prompt, thus providing the LLM with richer context and more explicit translation instructions. This method is particularly suitable for handling parts of the Fortran language that differ significantly from C++ and are prone to translation errors.

[0193] Specifically, when the system processes a piece of Fortran code, it performs lexical and syntactic analysis to identify specific keywords and structures. For example, when encountering a DIMENSION statement, a prompt will be added, such as "Note: The following code contains a DIMENSION statement. Please implement it in C++ using XX or XX equivalents." For DO loops, its iteration mode can be suggested so that the LLM can generate more modern C++ for loops. In this way, the translation difficulty of the LLM is reduced, enabling it to more accurately grasp the intent of the code, thereby generating C++ code that is superior in both structure and performance, significantly improving translation accuracy and code quality.

[0194] 2.3.1.4 Math-Function Agent, which handles calls to the mathematical function library.

[0195] Typically, HPC software for scientific and engineering applications requires calling various mathematical functions to perform necessary calculations, such as trigonometric functions, matrix operations, integration, solving differential equations, and interpolation. Generally, both Fortran and C++ have built-in basic mathematical functions, enabling conversion from Fortran to C++ code. However, for more complex matrix operations, third-party mathematical libraries are needed. In this application, an optional Math-Function conversion agent (a mathematical function library agent) is set after the Fortran-to-C++ conversion agent.

[0196] The Math-Function conversion agent is an optional agent. After the code is converted from Fortran to C++, a mathematical function existence check will be performed. If the converted code does not contain any third-party mathematical functions, the execution of the Math-Function conversion agent will be skipped. Otherwise, the agent will be called to complete the conversion of the third-party mathematical functions.

[0197] The Math-Function Conversion Agent is also an LLM-based agent. Commonly used third-party mathematical libraries include Fortran and C / C++ implementations, making it very convenient to create datasets mapping Fortran function libraries to their corresponding C / C++ function libraries. The Math-Function Agent is a dedicated agent based on this dataset, using the same fine-tuning method as the Fortran-to-C++ Conversion Agent, effectively converting commonly used third-party mathematical functions in Fortran format to C++ functions.

[0198] 2.3.2 C++ code correctness verification agent.

[0199] 2.3.2.1 Compilation and Verification: Integrate the relevant compilers.

[0200] The C++ Code Verification Agent verifies that the C++ code generated by the upstream agent is syntactically correct and conforms to standards. This agent integrates seamlessly with C++ compilers, providing an automated process involving multiple steps. First, the agent selects the appropriate compiler version based on preset configurations or dynamically detected system environments. Second, the agent constructs a comprehensive compilation command, which includes not only source file paths but also a series of key compilation options.

[0201] Once the compilation command is executed, the Agent captures all compiler output, including standard output (stdout) and standard error (stderr). It intelligently parses this output to determine if compilation was successful. If compilation fails, the Agent extracts all error and warning messages, associates them with line numbers in the source code, and generates a structured error report. This report not only contains the original compiler error messages but may also include the Agent's own analysis, such as indicating that a particular error might be caused by improper handling of array indices during the Fortran-to-C++ conversion. This detailed report is then passed to the Error Handling Agent, providing precise guidance for subsequent iterative fixes. In this way, a large number of syntax and type errors are effectively filtered out early in the process, ensuring the code quality that proceeds to later stages.

[0202] 2.3.2.2 Runtime verification: functional consistency and regression testing.

[0203] The runtime verification of the C++ Code Verification Agent is primarily achieved through functional consistency testing and regression testing. First, the Agent requires a reliable set of test cases. These test cases can come from multiple sources: existing test suites provided by users and maintained alongside the original Fortran code; or, in the absence of readily available test cases, they can be automatically generated by the system's "Test Case Generation Agent" based on the input / output interfaces and core logic of the Fortran code.

[0204] After obtaining the test cases, the Agent executes both the original Fortran program and the newly generated C++ program in a controlled environment using the same input data. Upon completion, the Agent captures the output of both programs and performs a detailed comparison. This comparison goes beyond simple textual comparison; it takes into account floating-point errors that may occur in numerical computations. The Agent sets an acceptable error threshold (e.g., relative error less than 1e-6 for single-precision calculations; relative error less than 1e-16 for double-precision calculations). If the outputs of the two programs are consistent within this threshold, the test is considered passed. If all test cases pass, the Agent reports successful verification. If any test case fails, the Agent records detailed failure information, including input data, expected output, actual output, and discrepancy analysis, and feeds this information back to the Error Handling Agent, triggering the upstream transformation Agent to make corrections. This automated runtime verification mechanism provides strong assurance for the functional correctness of the code and is a crucial step in ensuring that the final SYCL code correctly reproduces the original application behavior.

[0205] 2.3.3. Converting the Agent from C++ to SYCL.

[0206] 2.3.3.1 Fine-tuning of LLM for Device-Oriented Parallel Computing

[0207] At the core of the C++-to-SYCL conversion agent is a large language model (LLM, i.e., a second pre-trained model) specifically fine-tuned for device-side parallel computing and the SYCL programming model. The second pre-trained model identifies parallelism in the code and refactors it into efficient parallel algorithms, while ensuring correct mapping and migration of data between host-side and device-side memory. The corresponding dataset for fine-tuning (the second training set) consists of numerous C++ and SYCL code pairs (second code pairs), specifically designed to cover common parallel computing patterns in HPC. For example, the dataset might include: Data-parallel loops: converting C++ for loops to the SYCL parallel_for kernel and demonstrating how to define range or nd_range. Reduction operations: converting C++ summation, maximum finding, and other operations to SYCL reduction objects and demonstrating their usage in parallel_for. Scan and prefix sum: converting C++ serial scan algorithms to the SYCL workgroup shared memory-based parallel scan kernel. Stencil Computation: This section converts common grid computing patterns in C++ to a SYCL kernel and demonstrates how to handle boundary conditions and data dependencies. Memory Management: This section demonstrates how to convert C++ std::vector or native arrays to SYCL buffers or Unified Shared Memory (USM) and manage their access permissions.

[0208] By supervising the fine-tuning of LLM on this specialized dataset, LLM can learn to switch from serial thinking to device-parallel thinking, enabling higher-level code refactoring based on an understanding of the algorithm's intent.

[0209] 2.3.3.2 Automatic identification and conversion of parallelized code segments.

[0210] Building upon the fine-tuning of the LLM, the C++-to-SYCL conversion agent implements an automated process for identifying parallelizable portions of C++ code and converting them into SYCL code. This process primarily consists of two steps: static analysis and hotspot identification, and LLM-driven code refactoring.

[0211] First, the agent performs static analysis on the input C++ code. It traverses the Abstract Syntax Tree (AST) to find computationally intensive code regions, especially for loops containing numerous iterations. The agent uses data flow analysis and dependency analysis techniques to determine whether a loop is data-parallel, i.e., whether each iteration of the loop can be executed independently without interference. For identified parallel "hot spots," the agent marks them and extracts relevant contextual information, such as the iteration range of the loop, the computational logic within the loop body, and the data structures involved.

[0212] The Agent then inputs these marked parallel code segments, along with their context information, into the fine-tuned LLM via the Prompt project. The LLM's task is to generate equivalent SYCL kernel code based on this input. This process is intelligent; the LLM needs to make a series of decisions, which are internal processes reflected in the transformed SYCL code. For example: choosing the execution range: deciding whether to use a one-dimensional range or a multi-dimensional nd_range based on the loop's iteration space; managing memory access: mapping C++ arrays or containers to SYCL buffers / accessors or USMs and determining the access mode (read, write, read_write); handling synchronization: if there are operations requiring synchronization within the loop body, the LLM needs to convert them into SYCL group barriers or atomic operations, etc.

[0213] In this way, the Agent can automatically transform a serial C++ program into a well-structured SYCL program consisting of host code and device kernels, thus achieving the computing migration from CPU to GPU.

[0214] 2.3.4 SYCL Code Verification and Performance Evaluation Agent.

[0215] 2.3.4.1 Cross-platform (CPU / GPU) functionality verification.

[0216] The SYCL Code Verification Agent (the second verification agent) is responsible for ensuring that the SYCL code generated by the upstream Agent is not only syntactically correct, but more importantly, functionally consistent with the original code and can run correctly on different hardware platforms, performing cross-platform verification. First, the Agent uses a SYCL-compatible compiler to compile and run the code on a CPU backend. The CPU backend typically acts as the host device, and its execution environment is relatively simple, facilitating the quick discovery and debugging of basic logical errors. If the code runs correctly on the CPU, the Agent proceeds to the second step: verification on the target GPU backend. This step is crucial because the parallel execution model and memory hierarchy of the GPU differ significantly from those of the CPU. Many issues that are not apparent on the CPU (such as race conditions and memory access violations) may arise on the GPU. The Agent compiles and runs the program on the actual GPU hardware and compares its output with the output of the original Fortran code. Only when the code passes functional verification on all target platforms will the Agent report success, ensuring that the generated SYCL code possesses true portability and reliability.

[0217] 2.3.4.2 Performance benchmark testing and evaluation.

[0218] After functional verification is passed, another key responsibility of the SYCL Code Verification Agent is to conduct performance benchmarking and evaluation. This agent utilizes specialized performance analysis tools to perform in-depth analysis of the SYCL program's execution on the GPU. It collects a series of key performance metrics, including: Kernel execution time: measuring the actual runtime of each SYCL kernel on the GPU to identify computational hotspots. Memory bandwidth utilization: analyzing the program's access efficiency to the GPU's global memory to determine if there are memory bandwidth bottlenecks. Kernel utilization: assessing the workload of the GPU's compute units (SMs or EUs) to determine if the kernels are sufficiently "fully utilized" to fully leverage hardware resources. Data transfer overhead: measuring the data copy time between the host and the device to determine if data transfer is becoming a performance bottleneck.

[0219] The Agent compares this performance data with the performance of the original Fortran code on the CPU to quantify the performance improvement brought by GPU acceleration. Simultaneously, these detailed performance reports are recorded and passed to the downstream Performance Optimization Agent, providing it with precise optimization directions and targets.

[0220] 2.3.5, MPI Parallelization Agent.

[0221] 2.3.5.1 MPI code generation and integration based on LLM.

[0222] The core task of the MPI Parallelization Agent is to scale a single-node SYCL application into a distributed parallel application that can run on a large-scale HPC cluster. To achieve this, the Agent includes a fine-tuned large language model (LLM, a third pre-trained model). The training data for this LLM contains a large number of MPI communication patterns, parallel algorithms, and how they are integrated with computational code. Upon receiving a validated SYCL program, the Agent first analyzes its code structure and data flow to identify parts that can be processed in a distributed manner. For example, for a large-scale data parallel problem, the Agent will look for loops or data structures that can be domain-decomposed. After identifying the parallelization strategy, the Agent uses its LLM core to automatically generate and insert MPI calls at appropriate locations in the code. This includes initialization and cleanup: inserting MPI_Init and MPI_Finalize (i.e., the first parallelization point) at the beginning and end of the program. Process Information Management: Obtain the current process ID (MPI_Comm_rank, i.e., the cyclic parallel point) and the total number of processes (MPI_Comm_size, i.e., the statistical parallel point). Data Distribution and Collection: Based on the parallel strategy, insert collection communication functions such as MPI_Scatter, MPI_Gather, and MPI_Bcast to achieve data distribution and result aggregation between processes. Boundary Data Exchange: For algorithms requiring adjacency communication (such as Stencil computation), the Agent automatically inserts non-blocking communication code such as MPI_Send, MPI_Recv, or more efficient MPI_Isend and MPI_Irecv to exchange boundary data between computation steps.

[0223] In this way, the Agent can intelligently and seamlessly integrate the MPI parallelization logic with the original SYCL computation logic to generate a hybrid parallel program that can utilize GPU acceleration within a single node and perform distributed computation across nodes.

[0224] 2.3.5.2 Optimization of inter-node communication and task partitioning.

[0225] MPI parallelization also requires optimization of inter-node communication and task partitioning. After completing basic code generation, the MPI ParallelizationAgent performs an optimization analysis to minimize communication overhead and maximize load balancing. Regarding communication optimization, the agent analyzes communication patterns and attempts to apply a series of optimization strategies. For example, it prioritizes non-blocking communication (MPI_Isend / MPI_Irecv) to overlap with computation, thereby hiding communication latency. For patterns with frequent communication, the agent may suggest and implement communication aggregation, merging multiple small messages into a single large message for transmission. In terms of task partitioning, the agent strives to ensure that each MPI process undertakes approximately equal workloads based on computational load and data distribution, avoiding situations where some processes complete their tasks early and remain idle (i.e., load imbalance). For complex unstructured grids or dynamic load problems, the agent can integrate more advanced load balancing libraries or implement dynamic task scheduling mechanisms. Through these intelligent optimizations, the MPI code generated by the agent is not only functionally correct but also achieves high performance, providing a solid foundation for large-scale parallel computing.

[0226] 2.3.6 Performance Optimization Agent.

[0227] 2.3.6.1 Automatic analysis of performance bottlenecks.

[0228] The Performance Optimization Agent is used to automatically analyze performance bottlenecks in the final code (typically a hybrid MPI+SYCL program) generated by the upstream Agent. This agent invokes a series of professional HPC performance analysis tools to perform end-to-end analysis of the entire application. This process is systematic and multi-dimensional, aiming to comprehensively identify various factors affecting performance. The analysis mainly includes:

[0229] Computational bottlenecks: Kernel performance reports generated by analysis tools identify the SYCL kernels with the longest execution time and the lowest computational unit utilization. The Agent will conduct in-depth analysis of the instruction execution efficiency and thread dispersion of these kernels to determine whether the bottleneck stems from the algorithm itself or from instruction-level inefficiency.

[0230] Memory bottleneck: Analyze the GPU's memory access patterns to check for non-coalesced access, bank conflicts (in shared memory), or excessive access to global memory. The agent uses performance counters to measure actual memory bandwidth utilization and compares it to theoretical peak values ​​to determine if memory access is the primary performance limiting factor.

[0231] Communication bottlenecks: For MPI programs, the agent analyzes inter-process communication patterns and timing. It uses MPI performance analysis tools to visualize communication behavior, identifying communication hotspots, message size distribution, and the degree of overlap between communication and computation. If a significant amount of time is spent on communication, the agent identifies it as a communication bottleneck.

[0232] Through this series of automated analyses, the Agent can generate a detailed performance bottleneck report, providing clear goals and directions for subsequent optimization.

[0233] 2.3.6.2 Algorithm and data structure optimization suggestions.

[0234] After identifying performance bottlenecks, the Performance Optimization Agent can propose and attempt to implement a series of optimization suggestions based on the analysis results. These suggestions are multi-layered, ranging from low-level code fine-tuning to high-level algorithm and data structure replacements. The Agent utilizes its internally integrated LLM and a predefined set of optimization rules to generate these suggestions.

[0235] Code-level optimization: The agent provides specific code modification suggestions to address computational and memory bottlenecks. For example, for kernels with poor memory access patterns, it might suggest adjusting the data layout or using shared memory to cache frequently accessed data. For computational bottlenecks, it might recommend kernel merging, combining multiple small kernels into a larger kernel to reduce kernel startup overhead and intermediate data write-back.

[0236] Algorithm and Data Structure Level Optimization: In some cases, performance bottlenecks may stem from inappropriate algorithm selection. In such situations, the Agent's LLM leverages its powerful knowledge base to offer higher-level optimization suggestions. For example, if a sorting operation becomes the bottleneck, the Agent might suggest replacing the currently used simple sorting algorithm with a more efficient parallel sorting algorithm (such as radix sort or bitonic sort). If a data structure leads to frequent memory allocation and deallocation, the Agent might suggest using a memory pool or a more efficient container type.

[0237] The agent not only generates optimization suggestions but also attempts to automatically implement them, modifying the source code and then re-invoking agents like the SYCL Code Verification Agent to conduct performance tests and verify the effectiveness of the optimizations. This process can be iterative until the performance reaches the preset target or the optimization potential is exhausted. Through this intelligent, multi-layered optimization, the agent can significantly improve the execution efficiency of the final code.

[0238] 2.3.7 Error handling and iterative optimization of the Agent.

[0239] 2.3.7.1 Error detection and logging.

[0240] The Error Handling and Iteration Optimization Agent is used to establish a comprehensive and sophisticated error detection and logging system. Every agent in the system, whether a transformation agent or a verification agent, must report its operational status, key decisions, performance metrics, and any anomalies or errors to the Error Handling Agent in a standardized format when executing tasks. This includes successful operations (e.g., "C++ code compiled successfully"), warnings (e.g., "Potential performance bottleneck detected"), and fatal errors (e.g., "SYCL kernel crashed while running on GPU").

[0241] After receiving this information, the Error Handling Agent integrates it into a central log database. This log database system is not just simple text records, but a structured data storage system. Each log record contains a timestamp, source agent, task ID, error type, error code, related code snippets, complete compiler or runtime output, and the system's context state at that time (such as environment variables and hardware information). This structured logging greatly facilitates subsequent analysis and debugging.

[0242] 2.3.7.2 Automatic rollback and retry mechanism.

[0243] The Error Handling Agent also provides automatic rollback and retry mechanisms to enable the system to recover from failures and eventually succeed. When a downstream agent (such as a verification agent) reports an error that cannot be resolved locally, the Error Handling Agent immediately initiates a rollback process. The goal of the rollback is to return to a known, stable state and return the problem, along with its context information, to the upstream agent capable of handling it. Simultaneously with the rollback, the Error Handling Agent triggers a retry mechanism. It doesn't simply request the upstream agent to re-execute the same task; instead, it provides rich feedback to guide the retry. This feedback includes a detailed error report detected by the downstream agent. In LLM-based agents, this error report is integrated into a new prompt. For example, the new prompt might be: "The XX code you previously generated produced an error when run on XX, with the following error message: [...]. Please analyze the cause and correct the code." This type of prompt with specific error feedback greatly helps the LLM understand the problem and generate a more accurate fix. This process can be repeated multiple times, forming an iterative optimization loop. The system sets a maximum number of iterations for each transformation task to prevent infinite loops. If the problem remains unresolved after reaching the maximum number of iterations, the system marks the task as "requiring manual intervention" and records all relevant contextual information so that developers can quickly locate the problem. This iterative and rollback mechanism gives the system strong fault tolerance and continuous learning capabilities.

[0244] 2.4 System Integration and Workflow Orchestration.

[0245] 2.4.1. Chaining based on Python functions.

[0246] 2.4.1.1 Functional programming model.

[0247] For smaller-scale or relatively fixed code conversion tasks, implementation is achieved through concatenation of Python functions. (See attached image.) Figure 4As shown in the diagram. In this model, the functionality of each core Agent is encapsulated into one or more independent Python functions. These functions adhere to the principles of pure functional programming, meaning that for the same input, they always return the same output and do not produce side effects (such as modifying the global state). This design makes each function easy to test and debug. A master Python script (or a main function) is responsible for defining the logic of the entire transformation process. It calls these Agent functions sequentially in a predefined order, using the output of one function as the input of the next. This functional chaining approach is simple to implement, logically clear, and well-suited for rapid prototyping and development in single-machine environments or small-scale clusters.

[0248] 2.4.1.2 Data Transmission and Status Management.

[0249] In the Python function-based concatenation model, data transfer and state management are achieved through function parameters and return values. Each Agent function receives a data structure containing all necessary inputs (e.g., a dictionary or a custom Python object), which may include the code to be processed, configuration parameters, and metadata passed from the previous Agent. After execution, the function returns a data structure containing the processing result and newly generated metadata. This approach achieves loose coupling between Agents, as each function does not need to be concerned with the specific implementation of its upstream and downstream processes. For states that need to be shared across functions (such as global configurations and loggers), dependency injection can be used to pass these states as parameters to the functions that need them, instead of using global variables, thus maintaining the purity and testability of the functions. Error handling can be implemented using Python's try…except mechanism. When an Agent function fails and throws an exception, the master script can catch the exception and call the Error Handling Agent function to decide, based on the exception type and policy, whether to retry, fall back to the previous Agent, or terminate the entire process.

[0250] 2.4.2. Orchestration based on Pegasus workflow.

[0251] 2.4.2.1 Introduction to the Pegasus workflow system.

[0252] For large-scale, complex code transformation tasks, especially those requiring the powerful computing capabilities of HPC clusters, this invention employs the Pegasus workflow management system for task orchestration. (See attached document) Figure 5As shown, Pegasus significantly improves the portability and scalability of scientific applications by decoupling workflow tasks from execution sites, data, and storage systems. Users only need to describe the logical dependencies of tasks, and Pegasus handles the generation of executable workflows and task scheduling and execution using HTCondor's DAGMan component. This "abstraction-mapping-execution" model allows workflows designed in local development environments to be seamlessly migrated to large HPC clusters or the cloud.

[0253] 2.4.2.2 Workflow definition and task dependencies.

[0254] In the system of this invention, the entire conversion process from Fortran to SYCL is defined as a Pegasus workflow. This workflow consists of multiple jobs, each corresponding to the functionality of one or more agents. The dependencies between tasks are explicitly described using a directed acyclic graph (DAG), ensuring that the conversion process is executed in a predetermined logical order. For example, the execution of the C++ code correctness verification agent depends on the successful completion and output of the Fortran to C++ conversion agent. Similarly, the C++ to SYCL conversion agent must wait for the C++ code to pass all verifications before it can start. This explicit definition of dependencies is the core of the Pegasus workflow, ensuring the coordination and correctness of the entire process.

[0255] Reference Figure 6As shown, a typical conversion workflow can be defined as follows: Task 1 (T1): Fortran-to-C++ conversion. Input: Original Fortran source code file. Execution: Call the Fortran to C++ conversion agent. Output: Generated C++ source code file. Task 2 (T2): C++ compilation and verification. Input: C++ source code generated by T1. Execution: Call the C++ verification agent. Output: Compilation log (success or failure information). Task 3 (T3): C++ runtime verification. Input: C++ source code and test cases generated by T1. Execution: Call the C++ verification agent, execute the generated executable file, and perform functional tests. Output: Runtime test report. Task 4 (T4): C++-to-SYCL conversion. Input: C++ source code generated by T1. Dependency: Successful completion of tasks T2 and T3. Execution: Call the C++ to SYCL conversion agent. Output: Generated SYCL C++ source code. Task 5 (T5): SYCL compilation, verification, and optimization. Input: SYCL code generated by T4. Execution: Call the SYCL verification agent to compile and run tests on CPU and GPU. Output: SYCL verification optimization report. Task 6 (T6): MPI Parallelization. Input: SYCL code generated in T4. Dependency: Successful completion of task T5. Execution: Call the MPI parallelization agent. Output: SYCL code integrated with MPI. Task 7 (T7): Final Code Verification and Optimization. Input: Final SYCL code integrated with MPI generated in T6. Execution: Correctness verification and performance analysis and optimization of the code after MPI integration. Output: Final optimized MPI+SYCL code.

[0256] Pegasus' Python API allows users to easily define Directed Acyclic Graphs (DAGs) using code, specifying the execution environment, resource requirements, and data inputs and outputs for each task. Pegasus then automatically generates a specific execution plan based on this definition and submits it to the HPC cluster's scheduler for execution.

[0257] 2.4.2.3 Deployment and execution in an HPC environment.

[0258] Pegasus can also deploy the code transformation system described in this application within an HPC environment. Pegasus itself does not directly execute tasks; instead, it generates a specific workflow managed by HTCondor's DAGMan. DAGMan is responsible for task submission, monitoring, and retries. On an HPC cluster, HTCondor is typically configured to integrate with a local batch scheduler. Once the workflow generated by Pegasus is submitted, HTCondor transforms each task into a standard batch job and distributes it to the cluster's compute nodes for execution via the scheduler. This architecture allows the system to fully utilize the massively parallel computing capabilities of the HPC cluster, processing multiple code transformation projects simultaneously or performing parallel transformations of different modules within a single large project.

[0259] Pegasus offers flexible configuration options to adapt to different HPC environments. For example, during deployment, you need to configure the Pegasus site catalog, defining the properties of the local execution environment and the remote HPC cluster (condorpool), including file system paths, data transfer methods, and job submission parameters. For tasks requiring access to GPU resources (such as SYCL compilation and performance testing), you can specify the corresponding resource requirements in the task definition, and Pegasus will ensure that these tasks are scheduled to nodes equipped with GPUs. Furthermore, Pegasus supports accessing remote HPC clusters via SSH, which is particularly useful for code migration scenarios across data centers or cloud platforms. The `condor_remote_cluster` tool allows you to configure remote clusters as execution sites, enabling automated cross-platform deployment.

[0260] 2.4.3 Control Logic and Process Management.

[0261] 2.4.3.1 Responsibilities of the Central Control Agent.

[0262] Whether using Python function chaining or Pegasus workflow orchestration, the core control logic of the system can be abstracted into a central control agent. Its main responsibilities include: Workflow parsing and initialization: reading and parsing user-defined workflow configuration files (whether JSON, YAML, or Pegasus DAX files) to construct the execution order and dependency graph (DAG) of the agents. Task scheduling and triggering: based on the DAG logic, determining which agent(s) should be activated to execute tasks at the current moment. It checks whether the preconditions of each agent are met; once met, it submits the agent's task to the execution environment. Status monitoring and lifecycle management: continuously monitoring the execution status of each agent (e.g., waiting, running, successful, failed) and maintaining the global state of the entire pipeline. It is responsible for starting, stopping, and monitoring the execution of each agent. Error handling and decision-making: when an agent fails, the central controller makes a decision based on a preset strategy. This may include triggering an "error handling agent" to log, or initiating a "rollback mechanism" to revert the task to the previous successful stage and re-execute it. Resource management: In an HPC environment, computing resources (such as CPU cores, GPU devices, and memory) are allocated reasonably to different agents to improve overall execution efficiency.

[0263] Through centralized control and orchestration, the system can autonomously handle various situations that arise during the conversion process without human intervention, thus ensuring the robustness of the entire conversion process and the final success rate.

[0264] 2.4.3.2 Status monitoring and dynamic adjustment.

[0265] The central control agent monitors and dynamically adjusts the pipeline state in real time through a global state machine or context. The context records the current code conversion progress, the execution history of each agent, the versions of intermediate artifacts generated, and encountered errors and warnings. This state information is persisted to a database or file system to support long-running tasks and fault recovery. Based on this real-time state information, the central control agent can implement advanced control logic. For example, if an agent repeatedly fails on the same task, the controller can dynamically adjust its retry strategy, such as increasing the retry interval or marking it as requiring manual intervention after multiple failures. Furthermore, the system can dynamically adjust the process based on feedback from performance evaluation agents. For example, if a specific Fortran code pattern consistently performs poorly after conversion to SYCL, the controller can record this pattern and automatically trigger a more aggressive optimization strategy or prompt upstream conversion agents to use different conversion methods when encountering similar patterns later. This dynamic adjustment capability based on real-time monitoring enables the system to learn and adapt, continuously optimizing its conversion strategy to improve overall success rate and output quality.

[0266] It should be noted that the above-described conversion from Fortran to SYCL code is merely an example, and this application does not limit the specific data type of the code data conversion. Those skilled in the art can use the code data conversion method provided in the embodiments of this application to achieve the conversion from any source language one (including scripts, logical literals, etc.) to a target language two (including scripts, logical literals, etc.).

[0267] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0268] Reference Figure 7 Embodiments of this application also provide a code data conversion system, including:

[0269] The acquisition module 810 is used to acquire the source code data to be converted;

[0270] The first conversion module 820 is used to convert the source code data through the first pre-trained model of the first conversion agent to obtain the first converted data;

[0271] The first verification module 830 is used to verify the code correctness of the first transformation data through the first verification agent and obtain the first verification result.

[0272] The second conversion module 840 is used to identify the parallelism of the first conversion data and convert the first conversion data to obtain the second conversion data if the first verification result is passed;

[0273] The rollback module 850 is used to update the first pre-trained model according to the first verification result if the first verification result is failed, and return to the first conversion module to re-convert the source code data until the first converted data with the first verification result is passed is obtained, and the second converted data is obtained based on the first converted data with the first verification result passed.

[0274] The performance optimization module 860 is used to use the second transformation data as target code data if both the second verification result and the performance evaluation result for the second transformation data are passed.

[0275] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described code data conversion method embodiments.

[0276] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described code data conversion method embodiments at runtime.

[0277] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0278] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described code data conversion method embodiments.

[0279] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the code data conversion method embodiments described above.

[0280] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0281] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0282] The foregoing has provided a detailed description of a code data conversion method, system, and electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A code data conversion method, characterized in that, The code data conversion method includes: Obtain the source code data to be converted; The source code data is transformed by the first pre-trained model of the first transformation agent to obtain the first transformed data; The first verification agent verifies the code correctness of the first converted data to obtain a first verification result. If the first verification result is passed, the second pre-trained model of the second conversion agent identifies the parallelism of the first conversion data and converts the first conversion data to obtain the second conversion data; If the first verification result is a failure, the first pre-trained model is updated according to the first verification result, and the first pre-trained model of the first conversion agent is returned to convert the source code data to obtain the first converted data. The source code data is then converted again until the first converted data with the first verification result is obtained, and the second converted data is obtained based on the first converted data with the first verification result being obtained. If both the second verification result and the performance evaluation result for the second transformed data are passed, the second transformed data will be used as the target code data.

2. The code data conversion method according to claim 1, characterized in that, The process of converting the source code data using a first pre-trained model of a first conversion agent to obtain first converted data includes: The first prompt word and the source code data are input into the first pre-trained model to convert the source code data to obtain first converted data; the first prompt word includes one or more of the keywords, instruction information and the desired format of the first converted data in the source code data.

3. The code data conversion method according to claim 1, characterized in that, Before converting the source code data using the first pre-trained model of the first conversion agent to obtain the first converted data, the method further includes: If the amount of source code data is greater than or equal to the first preset amount, one or more of the first conversion agent, the first verification agent, and the second conversion agent are encapsulated into an executable instruction set, and one or more of the first conversion data, the first verification result, the second verification result, the second conversion data, and the performance evaluation result are set as an executable instruction set; If the amount of source code data is less than the first preset amount, one or more of the first conversion agent, the first verification agent, and the second conversion agent are deployed at each node of the workflow management system.

4. The code data conversion method according to claim 1, characterized in that, Before using the second converted data as target code data, the method further includes: Parallel points in the second transformed data are identified by a third pre-trained model in a parallel agent; Parallel calls are integrated at the parallel points to enable the target code data to be executed in parallel across multiple nodes.

5. The code data conversion method according to claim 1, characterized in that, Updating the first pre-trained model based on the first verification result includes: An error handling agent records error information during code correctness verification and integrates this error information into a second prompt word; wherein, the error information includes one or more of the following: error type, error location, partial source code data, and error log; The second prompt word is provided to the first conversion agent, which then inputs the second prompt word into the first pre-trained model to adjust the parameters or code conversion strategy of the first pre-trained model, thereby updating the first pre-trained model.

6. The code data conversion method according to claim 1, characterized in that, After converting the source code data using a first pre-trained model of a first conversion agent to obtain first converted data, the method further includes: If the existence of a function determines that the first transformed data contains a preset mathematical function, the preset mathematical function in the first transformed data is transformed by the fourth pre-trained model of the mathematical function library agent to obtain the first transformed data after function transformation; wherein, the preset mathematical function is a mathematical function that is not included in the source code data and the first transformed data.

7. The code data conversion method according to claim 1, characterized in that, The step of verifying the code correctness of the first converted data through a first verification agent to obtain a first verification result includes: The first verification agent calls the compiler to perform a first compilation verification on the first transformed data, and obtains a first compilation result. If the first compilation result is successful, the first converted data is run on the first hardware platform based on unit test cases and regression test cases to obtain the first running result; Based on the comparison between the first running result and the source code running result, a first verification result is determined; wherein, the source code running result is the running result obtained by running the source code data on the first hardware platform based on the unit test cases and the regression test cases.

8. The code data conversion method according to claim 1, characterized in that, Before converting the source code data using the first pre-trained model of the first conversion agent to obtain the first converted data, the method further includes: Obtain open-source code data; identify source code data samples and first converted data samples that implement the same function from the open-source code data to form a first code pair; Alternatively, extract a first code sample containing keywords and having preset performance calculation characteristics from the source code data, generate a first conversion sample corresponding to the first code sample, and form a first code pair by combining the first code sample and the first conversion sample. Obtain a pre-trained model trained on a general dataset, and fine-tune the pre-trained model using the first code to obtain a first pre-trained model.

9. The code data conversion method according to claim 1, characterized in that, If both the second verification result and the performance evaluation result for the second transformed data are passed, before using the second transformed data as target code data, the method further includes: The second verification agent performs second compilation verification and second runtime verification on the second transformed data on different hardware platforms to obtain the second verification result. If the second verification result is passed, the performance evaluation agent performs a performance evaluation on the compilation and execution process of the second transformed data to obtain the performance evaluation result. If the second verification result is unsuccessful, the second pre-trained model is updated according to the second verification result, and the second pre-trained model of the second conversion agent is returned to convert the first conversion data to obtain the second conversion data. The first conversion data is then converted again until the second conversion data with the second verification result is obtained.

10. The code data conversion method according to claim 9, characterized in that, The second verification result is obtained by performing second compilation verification and second runtime verification on the second converted data on different hardware platforms through a second verification agent, including: The second verification agent compiles and runs the second transformation data on the first hardware platform to obtain the first sub-verification result; If the first sub-verification result is passed, the second verification agent compiles and runs the second conversion data on the second hardware platform to obtain the second verification result.

11. The code data conversion method according to any one of claims 1 to 10, characterized in that, The second training set includes a second code pair. Before the second pre-trained model of the second conversion agent identifies the parallelism of the first conversion data and converts the first conversion data to obtain the second conversion data, the code data conversion method further includes: The loop data of the first transformed data is converted into the loop kernel of the second transformed data to obtain a parallel loop code pair; The operation data of the first transformed data is converted into the operation object of the second transformed data to obtain a reduction operation code pair; The serial scanning algorithm data of the first converted data is converted into the parallel scanning kernel of the second converted data to obtain a scan code pair; The network computing mode of the first converted data is converted into the network kernel of the second converted data to obtain a network computing code pair; A second code pair is generated based on one or more of the parallel loop code pair, the reduction operation code pair, the scan code pair, and the network computation code pair.

12. The code data conversion method according to claim 11, characterized in that, Before the second pre-trained model of the second conversion agent identifies the parallelism of the first conversion data and converts the first conversion data to obtain the second conversion data, the code data conversion method further includes: The second conversion agent performs static analysis on the first conversion data to identify whether the cyclic part in the first conversion data is data parallel, marks the data parallelizable cyclic part as hotspot information, and extracts the context information of the data parallelizable cyclic part; wherein, the context information includes one or more of the iteration range, computation logic and data structure of the cyclic part; The hotspot information and the context are integrated into a third prompt word, which is then input into the second pre-trained model to identify the parallelism of the first conversion data.

13. The code data conversion method according to claim 4, characterized in that, The step of identifying parallel points in the second transformed data through a third pre-trained model in a parallel agent includes: Static dependency analysis is used to identify data loop segments and calculate the computation-to-communication ratio of these segments. Identify data access patterns and runtime hotspots through runtime instrumentation sampling; The code abstract syntax tree is structurally matched with the parallel pattern library to obtain the parallel points.

14. The code data conversion method according to claim 4, characterized in that, The integration of parallel calls at the parallel points, enabling the target code data to be executed in parallel across multiple nodes, includes: By calling the first parallel function, the second transformation data of the current parallel point is distributed to the other parallel points; Alternatively, by calling the second parallel function, the second transformation data of the remaining parallel points can be collected and sent to the current parallel point; Alternatively, by calling a third parallel function, the second transformation data from the remaining parallel points can be aggregated to the current parallel point.

15. The code data conversion method according to claim 4, characterized in that, The method further includes, after integrating parallel calls at the parallel points to enable the target code data to be executed in parallel across multiple nodes: The performance optimization agent calls performance analysis tools to identify performance bottlenecks in the parallel process; When the performance bottleneck is that the memory access rate of the hardware platform is less than the preset access rate, the performance optimization agent executes optimization strategies such as memory merging or memory sharing. Alternatively, if the performance bottleneck is that the execution efficiency of the third pre-trained model is less than the preset execution efficiency, the algorithm or data structure of the third pre-trained model is updated by the performance optimization agent.

16. The code data conversion method according to claim 5, characterized in that, The step of integrating the error information into a second prompt word includes: The error message and the corresponding portion of the source code data are associated to obtain association information; The error processing agent analyzes the error information to obtain error message information; By integrating the associated information and the error message information, a second prompt word is obtained.

17. The code data conversion method according to claim 7, characterized in that, If the first compilation result is successful, before running the first transformed data on the first hardware platform based on unit test cases and regression test cases to obtain the first running result, the method further includes: Obtain the first test case provided by the user; wherein the first test case and the source code data are maintained in sync. Alternatively, if the user does not provide a first test case, a second test case can be generated by generating an intelligent agent based on the input / output interfaces and code logic of the source code data. The unit test case and the regression test case are generated based on the first test case or the second test case.

18. The code data conversion method according to claim 4, characterized in that, The method further includes, after integrating parallel calls at the parallel points to enable the target code data to be executed in parallel across multiple nodes: The communication pattern of the second transformed data after integrated parallel invocation is analyzed by a parallel intelligent agent to obtain the communication results, and parallel optimization is performed based on the communication results, including: Overlapping non-blocking parallel points and computational parallel points; If the communication rate represented by the communication mode is greater than or equal to the preset rate, aggregate the parallel points corresponding to the communication mode; Load balancing is performed on each parallel process based on its computational and data volume.

19. A code data conversion system, characterized in that, The code data conversion system includes: The acquisition module is used to acquire the source code data to be converted; The first conversion module is used to convert the source code data using the first pre-trained model of the first conversion agent to obtain the first converted data; The first verification module is used to verify the code correctness of the first converted data through a first verification agent and obtain a first verification result. The second conversion module is used to identify the parallelism of the first conversion data and convert the first conversion data to obtain the second conversion data if the first verification result is passed; The rollback module is used to update the first pre-trained model according to the first verification result if the first verification result is a failure, and return to the first conversion module to re-convert the source code data until the first converted data with the first verification result is a pass is obtained, and the second converted data is obtained based on the first converted data with the first verification result being a pass. The performance optimization module is used to use the second converted data as target code data if both the second verification result and the performance evaluation result for the second converted data are passed.

20. An electronic device, characterized in that, Including memory and processor, The memory stores a computer program, and the processor is configured to run the computer program to perform the code data conversion method as described in any one of claims 1 to 18.