Code data migration method, system and electronic device

Abstract

This application discloses a method, system, and electronic device for code data migration, relating to the field of integrated circuit technology. Based on migration project data, this application constructs a task graph, which represents each task in the code data migration process, facilitating control of the migration progress based on the state of each node in the task graph. This application also establishes a shared space through which various tool agents transfer data, decoupling the individual tool agents and improving the portability of the data migration. Furthermore, this application updates the task graph based on the execution results of each node, enabling adjustments to the migration logic and improving the efficiency of code migration. Therefore, this application can solve the technical problem of low code migration efficiency and achieve the technical effect of highly efficient code migration.

Description

Technical Field

[0001] This application relates to the field of high-performance computing technology, and in particular to a method, system, and electronic device for migrating code data. 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. However, these older languages ​​are incompatible with new supercomputing platforms, resulting in a waste of computing resources and potential. Meanwhile, with ever-increasing demands, the industry urgently needs a programming model that can leverage hardware acceleration while maintaining good cross-platform portability. How to migrate older code languages ​​to new programming models has become a crucial solution. Current technologies often fail to automate code migration during the conversion process, relying heavily on manual intervention. Some solutions have designed automated processes, but logical adjustments require rebuilding the process, reducing the efficiency of code migration. Summary of the Invention

[0003] This application provides a method, system, and electronic device for migrating code data, in order to at least solve the problem of low code migration efficiency in related technologies.

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

[0005] Acquire migration project data, and construct a task graph in a shared space based on the migration project data; wherein, the task graph includes multiple nodes, and each node corresponds to one or more tasks; the migration project data includes source code data and migration targets;

[0006] According to the task graph, a first task to be executed is determined, one or more target tool agents in the tool agent set are invoked to execute the first task, an execution result is obtained for the source code data, and the execution result is written to the shared space through the target tool agent;

[0007] Based on the execution results in the shared space, the task graph is continuously updated. Based on the updated task graph and the state of each node, a new target tool agent is invoked to execute a new first task based on the execution results until a target execution result that satisfies the migration objective is obtained. The migration code data in the target execution result is then used as the target code data corresponding to the source code data.

[0008] This application also provides a code data migration system, including:

[0009] The acquisition module is used to acquire migration project data and construct a task graph in the shared space based on the migration project data; wherein, the task graph includes multiple nodes, each node corresponding to one or more tasks; the migration project data includes source code data and migration targets;

[0010] The calling module is used to determine the first task to be executed according to the task graph, call one or more target tool agents in the tool agent set to execute the first task, obtain the execution result for the source code data, and write the execution result into the shared space through the target tool agent;

[0011] The migration module is used to continuously update the task graph based on the execution results in the shared space, and based on the updated task graph and the state of each node, call a new target tool agent to execute a new first task based on the execution results until a target execution result that satisfies the migration target is obtained, and the migration code data in the target execution result is used as the target code data corresponding to the source code data.

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

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

[0014] This application constructs a task graph based on migration project data. This task graph represents the various tasks in the code data migration process, facilitating control of the migration progress based on the status of each node. This application also establishes a shared space through which various tool agents transfer data, decoupling them and improving the portability of the data migration. Furthermore, this application updates the task graph based on the execution results of each node, enabling adjustments to the migration logic and improving the efficiency of code migration. Therefore, this application can solve the technical problem of low code migration efficiency and achieve highly efficient code migration. Attached Figure Description

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

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

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

[0018] Figure 3 A flowchart illustrating the process of understanding the code data provided in the embodiments of this application;

[0019] Figure 4 A flowchart illustrating the dynamic replanning process based on a task graph, provided for an embodiment of this application;

[0020] Figure 5 A flowchart illustrating the code data migration process based on function processing provided in this application embodiment;

[0021] Figure 6 A flowchart illustrating the code data migration process based on the management system provided in this application embodiment;

[0022] Figure 7 This is a schematic diagram of the structure of a code data migration system provided in an embodiment of this application.

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

[0024] 810. Acquisition module; 820. Calling module; 830. Migration module. Detailed Implementation

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

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

[0027] Based on the above background, this application provides a method, system, and electronic device for migrating code data, so as to at least solve the problem of low code migration efficiency in related technologies.

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

[0029] Reference Figure 1 As shown, this application provides a method for migrating code data, including:

[0030] Step S100: Obtain migration project data and construct a task graph in the shared space based on the migration project data; wherein, the task graph includes multiple nodes, and each node corresponds to one or more tasks; the migration project data includes source code data and migration targets;

[0031] Step S200: Based on the task graph, determine the first task to be executed, call one or more target tool agents in the tool agent set to execute the first task, obtain the execution result for the source code data, and write the execution result into the shared space through the target tool agent;

[0032] Step S300: Based on the execution results in the shared space, continuously update the task graph, and based on the updated task graph and the state of each node, call the new target tool agent to execute the new first task based on the execution results until the target execution result that meets the migration target is obtained, and use the migration code data in the target execution result as the target code data corresponding to the source code data.

[0033] The migration project data in this application includes the source code data to be migrated, migration targets indicating migration requirements, and other information. Based on the migration project data, a task graph is constructed in a shared space. The source code data in this application can be code based on a specific programming / translation language, compiled data, or script data, logical data, or other types of data representing different data types, such as language data for language translation or image data for image recognition. This application does not limit the specific type of source code data or the specific application scenario of this method. (See reference...) Figure 2 The shared space stores information such as the task graph, the state of each node in the task graph, and the execution results of the tool agents. Each tool agent calls / retrieves the required input information from the shared space and stores the output execution results in the shared space for subsequent use by other tool agents. The shared space decouples the tool agents, improving the system's scalability and execution efficiency. The first task in this application is the task corresponding to the node to be executed, determined based on the task graph. Specifically, the first task is selected based on the state of each node in the task graph. It can be understood that after the task graph is constructed, the first task can be the initial migration task determined based on the task graph. In subsequent task graph updates and execution processes, the first task can also be an executable migration task determined based on the task graph. This application calls tool agents through tasks corresponding to nodes in the task graph. Each tool agent can serve multiple task graphs or multiple nodes. When new business requirements arise, corresponding tool agents can be added directly, facilitating the expansion of the migration system's functionality.

[0034] It should be noted that the entity executing steps S100 to S300 above is the planning agent / main agent, such as... Figure 2 As shown, the planning agent manages the task graph in a unified manner. The planning agent is used to analyze migration targets, perceive the state of each node, construct and update the task graph, and schedule various tool agents. In this application, the task graph can be structured and stored in a shared space, and the task graph can be a directed acyclic graph. Updating the task graph in this application includes: adding new task nodes, modifying task dependencies, and falling back to upstream nodes and replacing one or more of the tool agents used.

[0035] In this embodiment, the system dynamically adjusts the structure and node status of the task graph based on the real-time updated execution results in the shared space, intelligently triggering the execution of subsequent tasks at opportune moments, forming a closed-loop feedback and multi-path parallel exploration mechanism, continuously iterating until a target execution result that meets the migration objective is generated. This process realizes the autonomous evolution of migration paths, multi-scheme collaborative exploration, and intelligent decision convergence, thereby effectively solving the problems of lacking dynamic planning, multi-path exploration, and intelligent collaboration mechanisms during code migration in related technologies, and significantly improving the automation, adaptability, and success rate of the migration process.

[0036] Optionally, based on migration project data, a task graph is constructed in the shared space, including:

[0037] Based on one or more of the project size, domain type, and code structure in the migration project data, construct a search query and perform a search in the experience base based on the search query;

[0038] If historical cases similar to the current migration project data are found in the experience base, a task graph is constructed based on the historical cases;

[0039] If no historical cases similar to the current migration project data are found in the experience base, a task graph is constructed based on the project structure summary and migration goals in the migration project data.

[0040] This application also includes an experience base in the migration system. The experience base contains data from previous code migration processes and can be used in the current code migration process. Of course, the experience base can also be used for task graph creation and updating. In one embodiment, historical cases similar to the current migration project data are retrieved from the experience base based on one or more of the following: project size, domain type, and code structure. The task graphs from these historical cases are then adapted and trimmed to construct the task graph for the current migration project data. If no similar historical cases are found in the experience base, the task graph is constructed based on the project structure summary and migration goals in the current migration project data. This application achieves rapid construction and updating of the task graph through the experience base, which helps improve the efficiency of code migration.

[0041] Optionally, the execution results include migration code data, test data on the migration code data, and performance data based on the migration process. The task graph is continuously updated based on the execution results in the shared space, including:

[0042] Step S301: If the performance data does not meet the performance constraints in the migration target, insert a performance tuning node in the task graph;

[0043] Alternatively, in step S302, if the number of consecutive failures in the continuous test is greater than or equal to the first consecutive number of failures, the node representing the new task replaces the node of the first task, and the task graph is updated.

[0044] Alternatively, in step S303, if preset conditions are met, delete the task graph and regenerate a new task graph; wherein the preset conditions include one or more of the following four conditions: the number of consecutive test failures in consecutive tests is greater than or equal to the second consecutive number; the number of consecutive compilation failures in consecutive compilations is greater than or equal to the third consecutive number; the performance of the code migration process cannot converge; and the number of consecutive resource limits in the consecutive migration process is greater than or equal to the fourth consecutive number, wherein the second consecutive number is greater than the first consecutive number.

[0045] It is understandable that tool agents with different functions will have different data types represented by their execution results. In this application, the execution results include migration code data, test data, and performance data. Of course, the data types contained in the target execution results are the same as the execution results themselves. The target in the target execution results is used to correspond to the migration project data, representing an acceptable and recognized execution result. Migration code data refers to intermediate / conversion data used to transform source code data, and test data refers to data obtained by testing the obtained migration code, including compilation and execution. Performance data is used to characterize the system's performance during code migration. Different task graph update strategies are executed for different representations of the execution results. In some embodiments, the correctness constraint is that the simulation result of the migrated or optimized code is the same as or physically equivalent to the source code. Performance constraints are used to characterize user needs; for example, if a user wants to achieve a 20% performance improvement, this goal is written into the performance constraint. Quality and resource constraints refer to the cluster resources that can be occupied during code migration, mainly for resource management and system security considerations. All constraints are hard constraints that must be met, and the above constraints need to be comprehensively considered when the planning agent makes decisions. The performance failure of the code migration process is used to characterize the fact that the performance of multiple consecutive code migration processes does not meet the performance expectations, and the gap between the performance and the performance expectations widens. Resource exceeding the migration process limit is defined as the resource consumption of the migration process being greater than or equal to a preset resource threshold. The preset resource threshold can be determined based on user needs, specific hardware scenarios, application domains, etc. It can be understood that consecutive test results of failing are defined as the number of consecutive times the migration code data is tested, and the test results corresponding to the test data are all failing. When at least the first consecutive test results are all failing, the node representing the new task replaces the node representing the first task. In some embodiments, if the migration code data is functionally correct, migration optimization is performed using performance data or test data; if the migration code data is functionally incorrect, it reverts to the state before the current node was executed. When the function is correct, the task graph is updated using performance data or test data for migration optimization, i.e., steps S301 to S303 above are executed. The functionality of the migration code data can be determined by compiling the migration code data and the compilation results.

[0046] This application automatically inserts performance tuning nodes to guide local optimization when performance data fails to meet the performance constraints in the migration target. When the number of consecutive test failures reaches a first preset threshold, the current task node is replaced with a new candidate task node, enabling flexible switching of the migration path. When multiple anomalies such as consecutive test failures, compilation failures, performance non-convergence, or resource overruns accumulate to a higher severity level, the task graph is completely deleted and rebuilt, thereby thoroughly reconstructing the migration strategy. The design that the second consecutive number of failures is greater than the first establishes a graded response mechanism for failure severity, ensuring that minor anomalies only trigger local adjustments, moderate anomalies trigger path replacement, and only severe anomalies execute high-cost system restarts. This effectively avoids the migration process from falling into an ineffective loop and wasting resources, achieving intelligent perception, graded response, and self-healing recovery for multi-dimensional and multi-level anomalies, significantly improving the robustness, efficiency, and automation level of the code migration process.

[0047] Optionally, based on the task graph, determine the first task to be executed, including:

[0048] Based on one or more of the test data, performance data, and compilation data in the execution results, determine the first state of each node in the task graph;

[0049] Select the first node from the nodes whose first state is not executed and whose upstream dependent nodes are in the state of successful execution, and take the task corresponding to the first node as the first task to be executed.

[0050] This application determines the first state of each node in the task graph based on one or more of the test data, performance data, runtime data, and compilation data in the execution results. Specifically, if the task execution result represented by each parameter is successful, the first state of the corresponding task node can be "executed" or "executed successfully," facilitating the planning agent to determine the task corresponding to the next node (i.e., the first node) as the first task based on the structure of the task graph according to this first state. This application selects the node whose own state is "not executed" and all upstream dependent nodes have been successfully executed as the first node, ensuring that each migration operation is based on the validity and expectation of the preceding results, avoiding invalid scheduling and migration path interruption caused by unmet dependencies or abnormal preceding tasks. Thus, in complex heterogeneous migration scenarios, it achieves intelligent task scheduling and path adaptive optimization based on real execution feedback, significantly improving the success rate and stability of code migration.

[0051] Optionally, after determining the first state of each node in the task graph based on one or more of the test data, performance data, and compilation data in the execution results, the method further includes:

[0052] Filter the nodes to find the second node whose first state is execution failure, roll back to the state of the second node in the task graph before it was executed, and update the first state of the second node to not executed.

[0053] Obtain the first execution result of the previous node of the second node after it has been executed, and take the task corresponding to the second node based on the first execution result as the first task to be executed.

[0054] If the execution result, represented by the parameters of the execution result, is a failure, the corresponding first state is execution failure. This application provides logic for failure rollback and retry. Specifically, this application rolls back to the state of the second node before execution and updates its first state to "not executed," restoring its initial schedulable conditions. Combined with obtaining the first execution result generated by the previous node after successful execution, the task corresponding to the second node reconstructed based on this valid intermediate result is set as a new task to be executed. Thus, without interrupting the overall migration process, intelligent retry and dynamic replanning of failed tasks are achieved by utilizing the context information of previous successful executions. This effectively avoids migration interruption caused by the failure of a single task, constructs a fault-tolerant code migration mechanism with self-recovery capabilities, and ultimately improves the robustness and success rate of code migration.

[0055] Optionally, one or more target tool agents from the tool agent set are invoked to perform the first task, obtaining the execution result for the source code data, including:

[0056] The target tool agent is invoked to perform structural analysis on the source code data to obtain the source structure data.

[0057] Alternatively, the target tool agent can be invoked to migrate the source code data to obtain migrated code data.

[0058] Alternatively, the target tool agent can be invoked to test the migration code data corresponding to the source code data to obtain test data;

[0059] Alternatively, the target tool agent can be invoked to perform structural analysis on the migration code data corresponding to the source code data to obtain migration structure data.

[0060] Alternatively, the target tool agent can be invoked to compile the migration code data using a compiler and runtime environment to obtain compiled data.

[0061] In this application, the operation involved in the task corresponding to each node of the task graph can be one of the following: structural analysis, migration processing, test verification, structural reanalysis, or compilation verification. When the target tool agent in the tool agent set is called to execute any task, the system can generate structured execution results, including measurable data such as the structural characteristics of the source code, the form of the migrated code, the test pass rate, the compliance of the migrated structure, and whether the compilation was successful. These data are written to the shared space in real time as the basis for dynamic updates of the task graph. The task graph dynamically adjusts the scheduling order and priority of subsequent tasks based on this feedback information, forming a closed-loop control mechanism of "execution-feedback-optimization". This makes the migration path no longer dependent on static preset rules, but intelligently evolves based on the real state of code behavior and executability, thereby effectively solving the problems of path rigidity, difficulty in error location, and low migration efficiency caused by the lack of fine-grained state awareness in traditional migration methods.

[0062] Optionally, before constructing a search query based on one or more of the project size, domain type, and code structure in the migration project data, and before performing a search in the experience base based on the search query, the method further includes:

[0063] Once the target code data that meets the migration objective is obtained, one or more of the following are integrated during the migration process: project feature data, task graph structure, target tool agents called at each node, migration objective and target code data, to obtain experience data, and the experience data is placed into the experience library.

[0064] Alternatively, if the target code data that meets the migration objective is not obtained and the migration task enters an infinite loop, the migration operation is terminated; based on the executed nodes and execution results, a migration report is generated, the migration report is added to the experience base, and error alerts are issued based on the migration report.

[0065] In this embodiment, a search query is constructed based on features such as project size, domain type, and code structure in the migration project data. This query is used to accurately match historical migration cases in the experience base. Before retrieval, project feature data, task graph structure, tool agent call records, migration target and target code data from successful migration processes are integrated into structured experience data and stored in the experience base. Simultaneously, when migration fails or gets stuck in an infinite loop, the process is actively terminated, a migration report containing executed nodes and execution results is generated and archived in the experience base, and an error reminder mechanism is added. This allows the experience base to not only accumulate optimal path knowledge for successful migrations but also systematically record the context and diagnostic clues of failure scenarios. As a result, in subsequent retrievals, the search strategy can be optimized based on complete historical experience (including positive successes and negative failures), improving the accuracy and adaptability of migration solution recommendations.

[0066] Optionally, a task graph is constructed based on the project structure summary and migration goals in the migration project data, including:

[0067] Perform code understanding and static analysis on source code data to generate a project structure summary;

[0068] Perform intermediate representation extraction on the source code data to obtain one or more of the following: data flow dependency information, parallelization opportunity information, and communication domain partitioning information;

[0069] Based on the project structure summary, construct the initial task diagram;

[0070] Adjust the node dependencies in the initial task graph based on the data flow dependency information;

[0071] Adjust the parallel nodes of the initial task graph based on the parallelization opportunity information;

[0072] Based on the communication domain partitioning information, the alternative nodes of the parallel nodes are adjusted to obtain the adjusted task graph.

[0073] Reference Figure 3 As shown, this embodiment of the application performs deep code understanding and static analysis on the source code data in the migration project data to generate a project structure summary reflecting the overall program structure. It further extracts intermediate representations of source code execution, extracting data flow dependencies, potential parallelization opportunities, and communication domain partitioning information, which serve as the semantic basis for task graph construction. After constructing an initial task graph skeleton based on the project structure summary, it dynamically adjusts the execution order and dependency constraints between nodes in conjunction with data flow dependency information to ensure that the migration task logic conforms to the actual data flow of the source code. Simultaneously, it identifies code modules that can be processed in parallel based on parallelization opportunity information, optimizes the setting of parallel nodes in the task graph, and achieves reliable execution of migration code on parallel nodes. Furthermore, it uses communication domain partitioning information to finely screen and constrain candidate execution units of parallel nodes, avoiding migration path failures caused by cross-domain communication overhead. Finally, it forms a reasonably structured, semantically accurate, and path-feasible adjusted task graph, which is then injected into a shared space for collaborative execution by tool agents. This achieves intelligent migration path planning based on the internal structure of the code, effectively solving problems in traditional methods such as coarse task graph modeling, slow migration path convergence, and low tool collaboration efficiency caused by neglecting the semantic structure of the source code.

[0074] Optionally, the candidate nodes for parallel nodes are adjusted based on the communication domain partitioning information, including:

[0075] If a first rule template and a second rule template are obtained based on the communication domain partitioning information, a first alternative node corresponding to the first rule template and a second alternative node corresponding to the second rule template are established under the parallel node.

[0076] If both the first and second alternative nodes have completed execution and the execution results are both successful, a test node and a performance analysis node are established under both the first and second alternative nodes. Based on the test data of the test node or the performance data of the performance analysis node, a target alternative node is selected from the first and second alternative nodes, and the next node of the parallel node is updated to the target alternative node.

[0077] In some embodiments, the recommended rule template obtained from the communication domain partitioning information can be one, two, or multiple. When there is no single recommended rule template, candidate nodes are established, executed, tested, and their performance analyzed for multiple rule templates to select the target candidate node. This application provides a decision-making method for multi-path selection during the migration process, enabling automatic optimization of migration paths and reducing the risk of manual intervention.

[0078] Optionally, the node representing the new task replaces the node representing the first task, updating the task graph, including:

[0079] Select tasks with different code transformation strategies from the first task and treat them as new tasks;

[0080] Alternatively, you can insert code to refactor the node before the node of the first task to obtain a new task.

[0081] When performing node replacement, this application selects other tasks that are fundamentally different from the code transformation strategy adopted by the first task as replacements, or inserts a code refactoring node before the first task node, using the task corresponding to the code refactoring node as the new task, to introduce pre-cleanup or adaptation operations, thereby breaking the rigid cycle of migration path caused by the failure of a single transformation strategy; this replacement mechanism provides strategy diversity or structural optimization drive, ensuring that the tool agent called later will not repeat the same type of transformation operation that caused failure, but will turn to a more adaptive processing path, effectively avoiding invalid retries and improving the fault tolerance and path exploration efficiency of the migration process.

[0082] Optionally, revert to the state of the second node in the task graph before it was executed, including:

[0083] Before and after the second node is executed, snapshot information of the second node is recorded in the shared space;

[0084] Based on the snapshot information, revert to the state of the second node before it was executed.

[0085] Before and after execution at each node in the task graph, snapshot information is created. This snapshot information enables rollback in case of task failure, allowing for retrying the task. It is understood that the snapshot information in this application captures the system state at a specific timestamp without interrupting normal operation, allowing for subsequent rollback or analysis. This snapshot information is read-only to avoid interfering with the original data. Snapshot information includes one or more of the following: input information version, invoked tool agent, key parameters, and execution environment summary. This application achieves rollback of the migration process by acquiring snapshot information without affecting the performance of the migration system, thus improving the accuracy of code migration.

[0086] Optionally, a performance tuning node can be inserted into the task graph, including:

[0087] Based on the intervention measures obtained after the performance tuning node is executed, insert a performance intervention node in the task graph;

[0088] Execute the tasks corresponding to the performance intervention nodes, obtain the execution results of the performance intervention nodes, and based on the execution results of the performance intervention nodes, continue to perform performance analysis and performance tuning steps until the performance data that meets the migration goals is obtained.

[0089] This application determines and executes intervention measures through the execution of performance tuning nodes. Performance analysis and performance tuning nodes are established after the intervention node, referring to... Figure 4 This application employs a loop of intervention, analysis, and adjustment to monitor and adjust the performance of the code execution process, gradually converging the system performance until performance data that meets the migration objectives is obtained. Through this small-loop performance monitoring process, the application achieves convergent execution of various performance-related tool agents, preventing aimless divergence and improving the convergence performance of code execution to obtain the desired code execution results.

[0090] Optionally, one or more target tool agents from the tool agent set are invoked to perform the first task, including:

[0091] Obtain the functional identifiers of each tool agent in the tool agent set;

[0092] Based on the matching relationship between the first task and the function identifier, the target tool agent is determined, and the target tool agent is invoked to execute the first task.

[0093] This application matches the task identifier of the first task with the function identifier of the tool agent. Based on the matching relationship between the task identifier and the function identifier of the first task, the target tool agent is determined to achieve sequential execution of code migration based on the task graph.

[0094] Optionally, before invoking the target tool agent to perform the first task, the method further includes:

[0095] The target tool agent obtains the input information required by the target tool agent from the shared space, and performs the first task based on the input information to obtain the execution result; wherein, the input information includes one or more of the following: source code data, intermediate representation, performance data, test data, and migration code data.

[0096] After identifying the target tool agent, this application plans to have the tool agent invoke the target tool agent to execute a first task. Upon receiving the first task, the target tool agent filters input information from a shared space. This input information is the information required for the first task and may include the execution result of the previous task. The input information may also include instructions, specifying how the tool agent should execute the task and what standards should be met. Specifically, the target tool agent obtains input information from the shared space based on a function identifier. Alternatively, the target tool agent can obtain input information from the shared space based on a preset identifier, which is related to the function identifier. This application connects various tool agents through a shared space, simplifying the introduction of new code migration functionality and improving code migration efficiency.

[0097] Optionally, the migration objective includes performance constraints and resource constraints, until a target execution result that satisfies the migration objective is obtained, including:

[0098] If the difference between the simulation result of the migrated code data and the simulation result of the source code data in the second execution result meets the preset difference range, the performance data in the second execution result meets the performance constraints, and the resource data of the migration process meets the resource constraints, then the second execution result will be used as the target execution result.

[0099] In some embodiments, the migration objectives in this application also include functional correctness constraints and performance objectives.

[0100] Optionally, the second execution result in this application can be any one of the execution results for the source code data. That is, this application selects the second execution result that meets preset constraints as the target execution result. The preset constraints are that the difference between the simulation result of the migrated code data and the simulation result of the source code data meets a preset difference range, the performance data meets performance constraints, and the resource data of the migration process meets resource constraints. Performance constraints and resource constraints are related to user requirements and the hardware environment of the code migration system. The preset difference range can also be adjusted according to requirements, and this application does not impose specific limitations on it.

[0101] Optionally, based on migration project data, a task graph is constructed in the shared space, including:

[0102] Based on the migration project data, the first migration path and the second migration path are retrieved from the experience base;

[0103] If the credibility score of the first migration path is greater than that of the second migration path, a first task graph is constructed based on the first migration path to migrate source code data to first migration code data based on the first task graph, and the first migration code data is migrated to target code data based on the first task graph.

[0104] If the credibility score of the first migration path is less than or equal to the credibility score of the second migration path, a second task graph is constructed based on the second migration path to migrate the source code data to the target code data based on the second task graph; wherein, the credibility score is related to the performance data and test data of the migration path.

[0105] When constructing a task graph based on similar historical cases from an experience base, multiple migration paths related to the current migration project data may be retrieved. This application represents these multiple related migration paths using a first migration path and a second migration path. For each migration path, a reliability score is calculated based on its performance and test data. The migration path is then selected from the multiple migration paths based on the reliability score, and a task graph is constructed based on the selected migration path. This application provides an accurate task graph for code migration by selecting migration paths from the experience base, thereby improving the accuracy of code migration.

[0106] Based on the execution results in the shared space, the task graph is continuously updated, including:

[0107] If the test data or performance data of the execution results do not meet the migration target, the task graph is updated by inserting task repair nodes;

[0108] Alternatively, if the test data or performance data of the execution results do not meet the migration target, the task graph can be updated by adjusting the model parameters corresponding to the first task.

[0109] Alternatively, if the test data or performance data from the execution results do not meet the migration goals, the task graph can be updated by path rollback.

[0110] In this application, updating the task graph may also include inserting task repair nodes, adjusting model parameters, or path rollback. Specifically, the tool agent can analyze the reasons for execution failures to select the task graph update method based on the reasons. This application provides multiple task graph update methods to optimize different execution results, achieve automated migration of code data, and help alleviate the problem of code migration relying on manual intervention in related technologies.

[0111] Based on the execution results in the shared space, the task graph is continuously updated, including:

[0112] Get the cumulative duration; where the cumulative duration is the time elapsed since the last time the status of each node was obtained;

[0113] If the cumulative duration is greater than or equal to the first duration, obtain the status of each node;

[0114] If there is a third node whose execution has ended, the task graph is continuously updated based on the execution result of the third node, the cumulative duration is cleared to zero, and the steps of obtaining the node status and updating the task graph are re-executed based on the relationship between the cumulative duration and the first duration; where the first duration is the time interval between two consecutive node status acquisition operations.

[0115] In this application, the planning agent periodically acquires the states of each node from a shared space to continuously update the task graph. The cumulative duration is the statistical duration, and the first duration is the period for acquiring node states. It is understood that the state of each node is related to the execution status of the task corresponding to that node. If a third node has completed its execution, the task graph is updated based on the execution result of the third node. Those skilled in the art can set a specific value for the first duration according to their needs to quickly update the task graph based on the execution results of the nodes. On the other hand, the acquisition of node states should not affect the performance of the code migration system; that is, the value of the first duration should not be too small. This application improves the accuracy of code migration by periodically updating the task graph.

[0116] On the other hand, refer to Figure 5 This application allows individual intelligent agents to be implemented through functions or through a process management system, such as... Figure 6 As shown, those skilled in the art can set the process implementation method according to their needs.

[0117] Embodiments of this application provide a code data migration system, referring to... Figure 7 As shown, it includes:

[0118] The acquisition module 810 is used to acquire migration project data and construct a task graph in the shared space based on the migration project data; the task graph includes multiple nodes, each node corresponding to one or more tasks; the migration project data includes source code data and migration targets;

[0119] The module 820 is used to determine the first task to be executed based on the task graph, call one or more target tool agents in the tool agent set to execute the first task, obtain the execution result for the source code data, and write the execution result to the shared space through the target tool agent;

[0120] The migration module 830 is used to continuously update the task graph based on the execution results in the shared space, and based on the updated task graph and the status of each node, call the new target tool agent to execute the new first task based on the execution results until the target execution result that meets the migration target is obtained, and use the migration code data in the target execution result as the target code data corresponding to the source code data.

[0121] This application embodiment constructs a task graph in a shared space and updates the task graph based on the task execution results during the migration process, alleviating the problem of low migration accuracy in fixed pipeline migration; at the same time, a shared space is established to store information such as the status and execution results of each node, and each tool agent reads data through the shared space, decoupling each tool agent and enhancing the scalability of the migration system.

[0122] The migration and detection methods for code data provided in this application are described in detail below with specific embodiments:

[0123] 1. The terms used in this plan include:

[0124] High Performance Computing (HPC);

[0125] Central Processing Unit (CPU);

[0126] Graphics Processing Unit (GPU);

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

[0128] Community Earth System Model (CESM);

[0129] Compute Unified Device Architecture (CUDA); for example, a programming model for a GPU;

[0130] Heterogeneous-Compute Interface for Portability (HIP C++).

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

[0132] SYCL, the open standard programming model;

[0133] Directed Acyclic Graph (DAG);

[0134] Large Language Model (LLM);

[0135] An agent, or intelligent agent, is typically composed of an LLM (Library Management System) and external tools (compiler, profiler, etc.). It is capable of making decisions and taking actions autonomously given a goal.

[0136] Planner Agent: A smart agent for task planning and strategy selection;

[0137] Critic / Referee Agent, the intelligent agent for reviewing and scoring;

[0138] Memory / Experience Agent, an intelligent agent that combines experiential memory with policy evolution.

[0139] Tool Agent: A tool-type intelligent agent with specific skills, such as translation agent, compilation agent, profiling agent, etc.

[0140] Blackboard / Workspace is a shared blackboard / workspace used for exchanging code artifacts, logs, and status among multiple agents.

[0141] 2.1 Overview of Multi-Agent Autonomous Migration Architecture

[0142] 2.1.1 System overall design concept.

[0143] This invention proposes a multi-agent architecture for migrating Fortran HPC applications to SYCL, modeling the entire migration process as a searchable and reconfigurable task space. Within this task space, there are multiple possible migration paths, such as first performing a Fortran-C++ conversion and then introducing SYCL, or directly generating a SYCL kernel while retaining the Fortran structure, or inserting MPI parallelization and performance optimization steps at different stages.

[0144] The system manages the task space centrally through a Planner Agent. The Planner is responsible for: understanding the migration goal, perceiving the current state, building and updating the task graph, and scheduling tool agents with different capabilities as needed. The "stages" in the migration are represented as a set of nodes and their dependencies in the task graph. The specific stages that occur and in what order are determined by the Planner dynamically during operation based on project characteristics and feedback information.

[0145] The tool agent is responsible for implementing specific capabilities, such as code understanding, Fortran-C++ / Fortran-SYCL conversion, testing and verification, performance analysis, MPI parallelization, and performance tuning. The tool agent identifies acceptable input and output types through capability descriptions, which are then selected and scheduled by the Planner based on the requirements of the current task graph. In this way, the same set of tool capabilities can be reused and combined in different projects and under different task graph structures, without being restricted by fixed processes.

[0146] 2.1.2 Agent Collaboration and Shared Workspace.

[0147] To achieve loosely coupled collaboration among multiple agents, this invention employs a shared workspace (also known as a blackboard or shared space) for data interaction. The shared space is a unified, structured data storage area used to store various artifacts and metadata generated during the migration process, including but not limited to: the original Fortran source code and project structure description; static analysis results and intermediate representations (IR); C++, SYCL, MPI+SYCL, and other code versions generated at each stage; compilation logs, test cases and test results, performance analysis reports; the current task graph and the execution status of each task node; and key decision records and version tagging information for the Planner. The key decision records are used for real-time decision-making by the Planner. During execution, the Planner consults these records to avoid repeated failures and optimize subsequent decision paths within the current project. Simultaneously, these records also serve as raw materials for building a long-term experience base for intelligent decision-making in future projects.

[0148] When the tool agents execute, they uniformly follow the pattern of "reading input from the shared space - completing the specified capability - writing the result back to the shared space." The Planner monitors the real-time progress of the entire migration process by reading the task graph and artifact status (i.e., node status) in the shared space and makes subsequent decisions accordingly. The tool agents do not directly call each other, but collaborate with the shared space as the central hub, thereby simplifying interaction relationships and facilitating the addition or replacement of certain types of tool capabilities. Among them, artifact status is an objective quality label for data (such as test reports), while the Planner makes subjective assessments such as "node success / failure / insufficient performance" based on these statuses and goals. Different assessment results will trigger different replanning strategies, such as advancing the corresponding path, reverting to a different tool, or inserting an optimized node.

[0149] 2.1.3 Task graph and dynamic programming mechanism.

[0150] This invention uses a task graph to depict the migration process. The task graph can be a directed acyclic graph structure, where each node represents a specific migration subtask, such as: performing structural analysis on a set of Fortran files (i.e., source code data); converting a numerical kernel from Fortran to C++ (i.e., first migration code data) or SYCL (i.e., second migration code data); performing unit tests or integration tests on a code version; performing performance profiling and tuning on a SYCL or MPI+SYCL version; performing MPI domain decomposition and communication insertion on a module, etc.

[0151] The edges in the task graph represent dependencies, indicating that the execution of a task node requires the preceding / dependent nodes to have already produced corresponding input artifacts or metadata (i.e., execution results) in the shared space. After reading the project structure summary and migration goals, the Planner first constructs an initial task graph. As the tool agent continuously writes new results into the shared space, the Planner periodically (i.e., for the first time interval) checks the status of each node in the task graph, selects suitable nodes to submit for execution, and updates the task graph upon receiving test or performance feedback, including inserting new nodes, adjusting dependencies, and replacing certain types of paths, until a migration result that meets the constraints is found.

[0152] Specifically, constraints are quantifiable success criteria set by the user for the migration results, such as correctness constraints (hard requirements), performance constraints (core objectives), and quality and resource constraints (guarantee conditions, such as memory usage limits and no high-risk warnings during operation).

[0153] Under this mechanism, stages are naturally represented as several subgraphs on the task graph, which may present different combinations and execution sequences in different projects. The Planner is not limited to a single fixed path, but continuously plans and modifies at the task graph level, making the migration process explorable and convergent.

[0154] 2.1.4 Experience memory and cross-project adaptation.

[0155] To improve migration efficiency across different projects, this invention introduces an experience store (Memory / ExperienceStore) to save key information from the historical migration process. After each migration is completed, the system compiles the project's feature information, task graph structure, tool combinations along each path, corresponding test and performance metrics, and the final target version into a migration experience (i.e., experience data), and stores it in the experience store.

[0156] When a new Fortran project is introduced into the system, Planner searches the experience base based on characteristics such as project size, domain type, and code structure, obtaining several historical migration cases similar to the current project. Planner adapts and trims the task graphs from these cases to generate a new initial task graph, and continues to incrementally adjust the task graph based on real-time feedback during subsequent migrations.

[0157] In this way, the multi-agent architecture of the present invention has the ability to adapt across projects: the system can gradually form effective migration strategies for different types of Fortran HPC applications based on the continuous accumulation of migration experience, so that subsequent projects have a high degree of rationality and success rate in the early planning stage, while retaining the flexibility to adjust the path according to feedback.

[0158] 2.2 Detailed Explanation of Core Workflow

[0159] 2.2.1 Initialization and migration target declaration.

[0160] In one embodiment of the present invention, the migration process begins with the following initialization steps.

[0161] First, the user provides the Fortran project to be migrated and its associated test case configuration files to the system. The system then organizes these files into a project description and writes it onto the whiteboard. This description includes not only the source file paths but also information such as compilation scripts, dependent libraries, input data, and expected output formats.

[0162] Subsequently, the user or upper-layer system declares the migration goals in the form of structured parameters, such as "Migrate this Fortran project to a single-node GPU version based on SYCL, and achieve scalable computing on 32 GPU nodes via MPI, with overall performance reaching XX". These goals are encoded as constraints and evaluation metrics that Planner can understand and are written to the blackboard as global task constraints.

[0163] Finally, the Planner Agent initiates the initial perception process, invoking the code understanding / analysis class Tool Agent to perform static analysis on some or all of the Fortran files. This yields information such as call relationship diagrams, module dependencies, the location of major numerical kernels, and array and data structure characteristics, generating a preliminary project structure summary. This summary, along with the migration target, forms the basis for Planner to generate the initial task graph.

[0164] 2.2.2 Planner-driven migration loop: perception—planning—execution—feedback.

[0165] Specifically, the entire loop uses Planner Agent as the core scheduler, driven by the "result write" event, enabling it to operate autonomously and continuously by actively reading the workspace state, making dynamic decisions and scheduling tools, receiving execution feedback, and then reading and updating again.

[0166] The main loop of the method of the present invention can be described as a continuously repeating "perception-planning-execution-feedback" cycle.

[0167] At the start of each iteration, Planner reads the current task graph and the execution status of each node from the blackboard, and combines this with the latest compiled results, test results, and performance reports to comprehensively evaluate the entire migration progress. If no candidate code version that meets the target constraints exists, Planner will update or incrementally rewrite the task graph based on historical task graphs in the experience base and the current project structure.

[0168] After the task graph is updated, the Planner selects nodes whose dependencies have been satisfied but not yet executed, maps the capability types corresponding to these nodes to specific Tool Agent instances (i.e., the target tool agent), and constructs the invocation parameters based on the input artifacts in the blackboard. The Planner does not directly concern itself with the internal implementation of the tool; it only needs to ensure that the input and output types are consistent with the capability descriptions. Specifically, the Planner prepares all the input information required for the Tool Agent to run, including which file to process, how to process it, and what standards to achieve.

[0169] It should be noted that the aforementioned capability types are functions, and capability types are represented by identifiers. Essentially, a capability type is an abstract classification of functions, represented by a unique string identifier.

[0170] When a Tool Agent is scheduled for execution, it reads the required source code, IR, or reports from the blackboard and performs the corresponding transformations, analyses, or evaluations. In the next loop, the Planner reads this new data to determine if the current migration path seems to be converging towards the goal (e.g., code migration: has correctness testing improved? Has performance improved?). If a path has a functional error, the Planner can roll back to a node before the error occurred, switch to another type of Tool Agent, or insert additional refactoring nodes. If the functionality is correct but performance is not up to standard, performance optimization-related task nodes can be added to the existing code version, such as memory layout refactoring or MPI parallelization extensions. In this way, the migration process is no longer a static straight line, but rather, under the Planner's control, it explores and converges across multiple paths. A refactoring node is a specific subtask instance in the task graph (e.g., "convert function_A.f90 to C++"), not the agent itself. Rollback operations can attempt to schedule another code transformation agent with a different strategy to re-execute the subtask, or first arrange a code refactoring agent to simplify the original code to reduce the transformation difficulty.

[0171] 2.2.3 Specific Implementation Example: Migration Path from Fortran HPC Applications to SYCL+MPI.

[0172] To facilitate understanding, this invention provides an embodiment illustrating a migration path that Planner might choose when handling large-scale Fortran HPC applications. This path is not the only execution order of the system, but rather an example task graph generated by Planner under specific project and constraints.

[0173] In this embodiment, Planner first invokes the Code Understanding Tool Agent to perform static analysis on the project, obtaining the locations of the main computational kernels and grid data structures. Based on the analysis results and migration records of similar applications in the experience base, Planner suggests first extracting Fortran intermediate representations (IRs) from several core numerical kernel functions, and then having another Tool Agent project the IRs into C++ numerical kernels, facilitating the subsequent unified introduction of SYCL and MPI.

[0174] Next, Planner creates test nodes for these C++ numerical cores, schedules the test tool agent to generate or execute the corresponding unit tests, and compares the output of the old and new versions. If a small number of kernels have functional differences, Planner will insert "retranslation" nodes for these local areas in the task graph, or directly call a dedicated error localization tool agent for diagnosis.

[0175] Based on the execution results in the shared space, the task graph is continuously updated, including:

[0176] If the execution results determine that there are kernels with functional differences, a retranslation node is inserted to update the kernel;

[0177] Alternatively, if the execution results indicate that there are functional differences in the kernel, an error location node can be inserted for fault diagnosis.

[0178] Once a batch of validated C++ numerical cores are available on the blackboard, Planner can decide to introduce SYCL, converting these C++ kernels to SYCL kernels and creating new test and performance evaluation nodes to compare the consistency and performance improvements between the SYCL version and the C++ version, as well as the original Fortran version. For SYCL versions that do not meet performance requirements, Planner can further add nodes for memory access optimization, workgroup configuration tuning, etc.

[0179] After the single-node SYCL version reaches its target, Planner introduces an MPI-related Tool Agent to perform domain decomposition and communication insertion (i.e., parallel nodes) on the overall program structure, generating a hybrid MPI+SYCL version. Subsequently, correctness verification and multi-node performance evaluation nodes are added until a version that meets the target performance and correctness requirements is found. At this point, Planner marks this version as the final migration result and incorporates the entire task graph and intermediate critical versions into the experience base.

[0180] It is important to emphasize that, in this invention, the Fortran-C++-SYCL-MPI example above is merely a migration path generated by Planner in one embodiment. For other projects, Planner can also directly call a Tool Agent that supports direct Fortran-SYCL conversion based on the Fortran source, or first perform algorithm-level refactoring and then generate multiple backend implementations. The specific choice is determined by the task graph and experience base.

[0181] 2.2.4 Failure Recovery and Safe Termination.

[0182] To ensure long-term reliability in complex projects, this invention provides system-level failure recovery and safe termination strategies. Before and after each task node execution, the system records snapshot information on the blackboard, including the input artifact version, the type of Tool Agent invoked, key parameters, and a summary of the execution environment. If a node execution causes a serious runtime error or an exception such as a compiler crash, Planner can use the snapshot information to revert the task graph to the state before the exception occurred and attempt to continue migration using different toolchains or alternative paths.

[0183] When Planner determines there is a risk of an infinite loop (e.g., repeated attempts on the same node all fail), or the migration objective cannot be met under given constraints (e.g., the performance ceiling is clearly insufficient to achieve the specified goal), the system will enter a safe termination process. At this point, Planner packages the explored task paths and corresponding results into the blackboard and experience base, and generates a complete migration report for manual analysis. In this way, even if the migration fails to complete automatically, the system can still provide structured intermediate results and diagnostic information.

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

[0185] This section describes the internal implementation of several typical Tool Agents without altering the core architecture of "Planner + Tool Agent + Blackboard + Experience Base". These implementations are designed to support Fortran-SYCL migration scenarios, and of course, this invention can be extended to other source and target language combinations.

[0186] 2.3.1 Planner Agent.

[0187] The Planner Agent can be implemented using a large language model. Specifically, the planning agent in this embodiment can be used for:

[0188] First, it can read migration goals, project structure summaries, and current task node statuses from the blackboard to construct a project status representation. This status representation includes generated code versions, executed test results and performance metrics, as well as unexplored structural areas. The blackboard information is also structured text information, which can be directly input into the planner as a prompt or part of the input information.

[0189] Secondly, it maintains a task graph, which in this embodiment can be a data structure representing the current migration plan. The Planner can add new nodes, modify dependencies, mark node states on this data structure, and determine the set of nodes that can be scheduled in each round of the loop accordingly.

[0190] Therefore, based on the execution results in the shared space, the task graph is continuously updated, including:

[0191] Based on the execution results, determine the status of each node;

[0192] Based on the status of each node, the task graph is updated by adding new nodes, deleting nodes, or modifying node dependencies.

[0193] Third, Planner accesses an experience base and retrieves historical task graphs from similar projects whenever the task graph needs to be expanded, migrating well-performing path patterns from those projects to the current project.

[0194] Finally, Planner maps abstract "capability requirements" (e.g., "perform static analysis of a function" or "perform performance evaluation of a code version") to specific Tool Agent instances, constructs call parameters, and records decisions. Upon receiving the results written back to the blackboard by the Tool Agent, Planner partially rewrites the task graph based on the result labels (success, failure, average quality, insufficient performance, etc.), thereby achieving feedback-based migration strategy updates. In other words, the task graph is used to represent the migration strategy.

[0195] 2.3.2 Code Understanding and Intermediate Representation Tool Agent.

[0196] To enable Planner to schedule migration tasks at a higher level, this invention introduces a code understanding and IR extraction class, Tool Agent. This Agent is responsible for performing static analysis on Fortran projects, constructing function call graphs, module dependencies, array and grid structure information, and generating a unified intermediate representation when necessary.

[0197] In implementation, this agent can integrate existing Fortran parsers and template matching tools, and leverage LLM to semantically annotate complex structures, such as identifying time-progression loops, spatial dimension loops, and boundary condition handling code. The generated IR does not need to adhere to a specific standard, but should at least include: the location of the core computational kernel, data flow dependencies, potential parallelization opportunities, and potential MPI domain partitioning candidates. In subsequent planning, the Planner can directly treat a "specific IR node" as an operation object in the task graph, assigning it to different transformation-type Tool Agents for processing.

[0198] 2.3.3 Code conversion class Tool Agent (Fortran-C++ / SYCL, etc.).

[0199] The code conversion tool agent in this invention includes, but is not limited to, various capabilities such as Fortran-C++, Fortran-IR, IR-C++, C++-SYCL, and Fortran-SYCL. Unlike previous fixed-stage solutions, these capabilities are not fixed in the method steps, but are provided to the Planner in the form of "capability tags".

[0200] Each transformation agent typically integrates a task-specific fine-tuned LLM, along with appropriate prompt projects and post-processing modules. Taking Fortran-C++ as an example, the agent uses the input Fortran source code snippet and its IR snippet as context, guiding the LLM to generate modern C++ code compliant with relevant standards, and explicitly handling language features such as array subscripts, column-major layout, COMMON blocks, and EQUIVALENCE. The generated code undergoes basic syntax formatting and static checking before being written to the blackboard.

[0201] For C++-SYCL capabilities, the agent focuses on identifying loop structures and data parallelism patterns, extracting the parts suitable for GPU execution into a SYCL kernel, and generating corresponding queue submission code and memory management logic. For some projects, Planner can also directly call the Fortran-SYCL-supporting conversion agent, skipping the intermediate C++ representation. These different conversion capabilities all exist in the form of Tool Agents, and Planner selects the invocation order based on project characteristics and statistical information in the experience base.

[0202] 2.3.4 Testing and Correctness Verification Tool Agent.

[0203] To ensure the reliability of migration results, this invention designs a dedicated testing and correctness verification tool agent. This agent receives a code version and its corresponding test case configuration, retrieves the input data and expected output format from the blackboard, automatically completes compilation, execution, and result comparison, and writes a structured test report back to the blackboard.

[0204] In the Fortran-C++-SYCL migration scenario, the test agent can run multiple versions simultaneously and compare the differences. For example, it can run the original Fortran program, the migrated C++ version, and the SYCL version simultaneously under the same input, calculate the absolute and relative errors between the outputs, and mark it as passed if it is within the allowable error threshold. After reading these reports, the Planner can determine whether a migration path is functionally acceptable and decide whether to further optimize performance or expand to multiple nodes.

[0205] 2.3.5 Performance Analysis and Performance Optimization Tool Agent.

[0206] The performance analysis tool agent is responsible for calling third-party performance analyzers to analyze a specific code version, measuring metrics such as kernel execution time, memory bandwidth utilization, computing power utilization, and communication time, and writing detailed reports back to the blackboard. The performance optimization tool agent, on the other hand, uses LLM and a predefined rule base to propose specific optimization suggestions based on these reports and attempts to generate new optimized code versions.

[0207] Under the architecture of this invention, Planner can view "performance analysis" and "performance optimization" as a pair of complementary capabilities that alternate in the task graph. For example, Planner can first insert a performance analysis node on a single-node SYCL version. If a memory access bottleneck is found, a data layout refactoring node is inserted, followed by a new round of performance analysis on the refactored version. For MPI+SYCL hybrid programs, the performance analysis report will also include communication patterns and load balancing information, which Planner can use to decide whether to introduce further domain partitioning optimization or communication aggregation nodes.

[0208] 2.3.6, MPI Parallelization Tool Agent.

[0209] The MPI Parallelization Tool Agent receives a single-node version of C++ or SYCL code and domain partitioning candidate information from the IR description. Internally, it uses LLM and rule templates to synthesize and generate a version for inserting MPI communication. The agent's output includes not only the source code integrating the calls but also metadata about domain partitioning and process mapping strategies for subsequent analysis and adjustment by the Planner.

[0210] The architecture of this invention allows multiple MPI parallelization agents with different styles to coexist, such as one-dimensional partitioning, two-dimensional partitioning, or three-dimensional partitioning. The Planner can create multiple parallel branches for the same IR segment in the task graph, which are evaluated by the testing and performance analysis agent. Then, only the best-performing path is retained to continue propagating to downstream nodes.

[0211] 2.3.7 Error Handling and Logging Tool Agent.

[0212] To facilitate reliable rollback and retries in Planner, this invention proposes an error handling and logging ToolAgent. This agent is responsible for uniformly collecting error information, exception stacks, compiler and runtime environment output from various Tool Agents, archiving this information on a blackboard, and organizing it into a searchable log by project dimension. When Planner encounters repeated failures, it can search the log for historical solutions to similar errors and attempt to use the same alternative paths or tool combinations. Specifically, after executing the first task by calling one or more target tool agents from the tool agent set and obtaining the execution result for the source code data, the method further includes: if the execution result of the target tool agent contains error information, sending the error information to the logging agent, and having the logging agent integrate the error information by project and store it in an experience base.

[0213] 2.3.8 Experience Base and Memory Management Tool Agent.

[0214] The experience base is maintained by a dedicated Memory Tool Agent. This agent stores each project's task graph structure, the Planner's key decision nodes, the Tool Agent combinations along the path, and the final performance metrics as an experience record in a long-term storage system. When a new project starts, the Planner can request the Agent to perform a similarity search based on project size, domain, and structural characteristics to obtain several candidate task graph templates, and use these as a starting point to generate the initial task graph for the new project. This mechanism allows the system to gradually develop "migration strategy knowledge" for different types of Fortran projects after performing multiple migrations.

[0215] 2.4 System Integration and Execution Backend.

[0216] 2.4.1 Python-based execution host.

[0217] In a lighter-weight embodiment, the various agents of this invention are implemented as Python modules or services, and are scheduled for execution sequentially according to the task graph output by the Planner, handled by a unified runtime. The runtime reads the task graph from the blackboard, selects the appropriate Tool Agent based on the capability tags of each task node, constructs the invocation parameters and environment variables, and updates the task graph and overall state by the Planner after each invocation. Figure 5 As shown, the Python runtime itself does not participate in migration strategy decisions; it only undertakes the roles of task distribution and resource scheduling. It can run on a single machine or a small-scale cluster through multi-process, multi-thread, or remote call methods, thereby supporting the automatic migration of medium-sized Fortran projects.

[0218] 2.4.2 HPC workflow integration based on Pegasus.

[0219] In embodiments targeting large-scale codebases and supercomputing environments, this invention maps the task graph generated by the Planner to multiple Jobs within a Pegasus workflow. The task graph maintained by the Planner in the blackboard is converted into a Pegasus-recognizable DAG description via an adaptation layer. Each Tool Agent is encapsulated as an independent task that can run on the HPC cluster, and artifacts in the blackboard are shared among nodes via a shared file system or data management service. Figure 6 As shown.

[0220] When Pegasus is used in conjunction with scheduling systems such as HTCondor and SLURM, migration subtasks of different projects or different modules of the same project can be executed in parallel on hundreds or even thousands of nodes. The Planner still manages the migration strategy at the logical level, while Pegasus and the underlying scheduling system are only responsible for arranging tasks to run on appropriate computing resources according to the task graph order. In this way, the multi-Agent architecture proposed in this invention can run in small-scale environments and can also be smoothly scaled to large-scale HPC clusters.

[0221] 2.4.3 Central control and status monitoring.

[0222] Regardless of the execution backend used, this invention achieves unified control logic and status monitoring through a global status recording mechanism in the Planner and Blackboard. In each loop, the Planner updates the task node status, marking it with indicators such as "waiting to execute," "in execution," and "execution completed (success / failure)," and generates a migration report when the termination condition is met. Once the status information is persisted, it can be used for visual monitoring, auditing, and subsequent offline analysis of the migration process.

[0223] This application stores all intermediate artifacts, reports, and task statuses in a shared space. All ToolAgents collaborate solely through blackboard read / write operations, avoiding complex point-to-point coupling and enhancing system scalability. The Memory / Experience Store module stores the task graph and execution results of each project in an experience database. At the start of a new project, the Planner retrieves similar cases and generates a more reasonable initial task graph, enabling adaptive and evolving migration strategies across projects. Within this general multi-Agent framework, a set of typical ToolAgent combinations is designed for the migration requirements from Fortran HPC to SYCL+MPI, focusing on Fortran-C++ / SYCL conversion, testing and verification, performance analysis, and MPI parallelization. This allows the system to automatically explore multiple migration paths and optimize performance while ensuring functional correctness.

[0224] The task graph constructed in this application embodiment includes at least one or more of the following types of task nodes: a. Code conversion task nodes that generate C++ code based on Fortran source code and / or intermediate representation; b. Code conversion task nodes that generate SYCL code based on Fortran source code, intermediate representation, or C++ code; c. Correctness verification task nodes that perform compilation and runtime tests for C++ and / or SYCL versions; d. Performance analysis task nodes that use performance analysis tools to perform performance profiling on SYCL and / or MPI+SYCL versions; e. MPI parallelization task nodes that insert MPI communication primitives into SYCL code to form a multi-node parallel version; f. Performance optimization task nodes that adjust data layout, kernel configuration, or communication mode based on performance analysis reports.

[0225] Each migration experience in the experience base includes at least: project size and domain characteristics, the structure of the task graph, the type of tool agent called by each task node, the corresponding test and performance metrics, and the final accepted target code version.

[0226] It should be noted that the specific types of source code data and migration code data, as well as the migration process in the above embodiments, are all exemplary examples and do not substantially limit the solution of this application.

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

[0228] 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 migration method embodiments.

[0229] 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 migration method embodiments at runtime.

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

[0231] 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 migration method embodiments.

[0232] 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 migration method embodiments described above.

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

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

[0235] The foregoing has provided a detailed description of a code data migration 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 method for migrating code data, characterized in that, The migration method includes: Acquire migration project data, and construct a task graph in a shared space based on the migration project data; wherein, the task graph includes multiple nodes, and each node corresponds to one or more tasks; the migration project data includes source code data and migration targets; According to the task graph, a first task to be executed is determined, one or more target tool agents in the tool agent set are invoked to execute the first task, an execution result is obtained for the source code data, and the execution result is written to the shared space through the target tool agent; Based on the execution results in the shared space, the task graph is continuously updated. Based on the updated task graph and the state of each node, a new target tool agent is invoked to execute a new first task based on the execution results until a target execution result that satisfies the migration objective is obtained. The migration code data in the target execution result is then used as the target code data corresponding to the source code data.

2. The code data migration method according to claim 1, characterized in that, The step of constructing a task graph in the shared space based on migration project data includes: Based on one or more of the project size, domain type, and code structure in the migration project data, a search query is constructed, and a search is performed in the experience base based on the search query; If a historical case similar to the current migration project data is found in the experience base, the task graph is constructed based on the historical case; If no historical cases similar to the current migration project data are found in the experience base, the task graph is constructed based on the project structure summary in the migration project data and the migration goal.

3. The code data migration method according to claim 1, characterized in that, The execution results include migration code data, test data on the migration code data, and performance data based on the migration process. The step of continuously updating the task graph based on the execution results in the shared space includes: If the performance data does not meet the performance constraints in the migration target, a performance adjustment node is inserted in the task graph; Alternatively, if the number of consecutive failures in the consecutive tests is greater than or equal to the first consecutive failure, the node representing the new task replaces the node representing the first task, and the task graph is updated. Alternatively, under preset conditions, the task graph can be deleted and a new task graph can be generated; wherein, the preset conditions include one or more of the following four conditions: the number of consecutive test failures in consecutive tests is greater than or equal to the second consecutive number; the number of consecutive compilation failures in consecutive compilations is greater than or equal to the third consecutive number; the performance of the code migration process cannot converge; and the number of consecutive migration process resource limits are exceeded is greater than or equal to the fourth consecutive number, wherein the second consecutive number is greater than the first consecutive number.

4. The code data migration method according to claim 1, characterized in that, The step of determining the first task to be executed based on the task graph includes: Based on one or more of the test data, performance data, and compilation data in the execution results, determine the first state of each node in the task graph; Select the nodes whose first state is not executed and whose upstream dependent nodes are in the state of successful execution, and take the task corresponding to the first node as the first task to be executed.

5. The code data migration method according to claim 4, characterized in that, After determining the first state of each node in the task graph based on one or more of the test data, performance data, and compilation data in the execution results, the method further includes: Filter the nodes from the nodes whose first state is execution failure, roll back to the state of the second node in the task graph before it was executed, and update the first state of the second node to not executed; Obtain the first execution result of the previous node of the second node after it has been executed, and take the task corresponding to the second node based on the first execution result as the first task to be executed.

6. The code data migration method according to claim 1, characterized in that, The execution of the first task by one or more target tool agents in the set of invoking tool agents, and the resulting execution results for the source code data, include: The target tool agent is invoked to perform structural analysis on the source code data to obtain source structure data. Alternatively, the target tool agent can be invoked to perform migration processing on the source code data to obtain migrated code data; Alternatively, the target tool agent can be invoked to test the migration code data corresponding to the source code data to obtain test data. Alternatively, the target tool agent can be invoked to perform structural analysis on the migration code data corresponding to the source code data to obtain migration structure data. Alternatively, the target tool agent can be invoked to compile the migration code data using a compiler and runtime environment to obtain compiled data.

7. The code data migration method according to claim 2, characterized in that, Before constructing a search query based on one or more of the project size, domain type, and code structure from the migration project data, and before performing a search in the experience base based on the search query, the migration method further includes: If the target code data that satisfies the migration objective is obtained, one or more of the following are integrated: project feature data during the migration process, the task graph, the target tool agent called by each node, the migration objective, and the target code data, to obtain experience data, and the experience data is placed into the experience library. Alternatively, if the target code data that meets the migration objective is not obtained and the migration task enters an infinite loop, the migration operation is terminated; a migration report is generated based on the executed nodes and execution results, the migration report is placed in the experience base, and an error reminder message is issued based on the migration report.

8. The code data migration method according to claim 2, characterized in that, The step of constructing the task graph based on the project structure summary in the migration project data and the migration target includes: The source code data is subjected to code understanding and static analysis to generate a project structure summary; The source code data is subjected to intermediate representation extraction to obtain one or more of the following: data flow dependency information, parallelization opportunity information, and communication domain partitioning information. Based on the project structure summary, construct an initial task graph; Adjust the node dependencies of the initial task graph based on the data flow dependency information; Adjust the parallel nodes of the initial task graph based on the parallelization opportunity information; Based on the communication domain partitioning information, the candidate nodes of the parallel nodes are adjusted to obtain the adjusted task graph.

9. The code data migration method according to claim 8, characterized in that, The step of adjusting the candidate nodes of the parallel nodes according to the communication domain partitioning information includes: If a first rule template and a second rule template are obtained based on the communication domain partitioning information, a first alternative node corresponding to the first rule template and a second alternative node corresponding to the second rule template are established under the parallel node; If both the first and second candidate nodes have completed execution and the execution results are both successful, a test node and a performance analysis node are established under both the first and second candidate nodes. Based on the test data of the test node or the performance data of the performance analysis node, a target candidate node is selected from the first and second candidate nodes, and the next node of the parallel node is updated to the target candidate node.

10. The code data migration method according to claim 3, characterized in that, The step of replacing the nodes representing the first task with the nodes representing the new task and updating the task graph includes: Select tasks with different code conversion strategies from the first task and treat them as new tasks; Alternatively, you can insert code to refactor the node before the node of the first task to obtain a new task.

11. The code data migration method according to claim 5, characterized in that, The revert to the state of the second node in the task graph before execution includes: Before and after the second node is executed, snapshot information of the second node is recorded in the shared space; Based on the snapshot information, revert to the state of the second node before it was executed.

12. The code data migration method according to claim 3, characterized in that, The insertion of a performance tuning node in the task graph includes: Based on the intervention measures obtained after the performance tuning node is executed, insert a performance intervention node in the task graph; The task corresponding to the performance intervention node is executed, the execution result of the performance intervention node is obtained, and based on the execution result of the performance intervention node, the performance analysis and performance adjustment steps are continuously executed until the performance data that meets the migration goal is obtained.

13. The method for migrating code data according to any one of claims 1 to 12, characterized in that, The execution of the first task by one or more target tool agents from the set of invoking tool agents includes: Obtain the functional identifier of each tool agent in the tool agent set; Based on the matching relationship between the first task and the function identifier, a target tool agent is determined, and the target tool agent is invoked to execute the first task.

14. The code data migration method according to claim 13, characterized in that, Before invoking the target tool agent to execute the first task, the method for migrating the code data further includes: The target tool agent obtains the input information required by the target tool agent from the shared space, and performs the first task based on the input information to obtain the execution result; wherein, the input information includes one or more of source code data, intermediate representation, performance data, test data and migration code data.

15. The code data migration method according to claim 1, characterized in that, The migration objective includes performance constraints and resource constraints, and the process of obtaining an execution result that satisfies the migration objective includes: If the difference between the simulation result of the migrated code data and the simulation result of the source code data in the second execution result satisfies the preset difference range, the performance data in the second execution result satisfies the performance constraint, and the resource data of the migration process satisfies the resource constraint, then the second execution result is taken as the target execution result.

16. The code data migration method according to claim 2, characterized in that, The step of constructing a task graph in the shared space based on migration project data includes: Based on the migration project data, the first migration path and the second migration path are retrieved from the experience base. If the credibility score of the first migration path is greater than the credibility score of the second migration path, a first task graph is constructed based on the first migration path, so as to migrate the source code data to the first migration code data based on the first task graph, and migrate the first migration code data to the target code data based on the first task graph; If the credibility score of the first migration path is less than or equal to the credibility score of the second migration path, a second task graph is constructed based on the second migration path to migrate the source code data to the target code data based on the second task graph; wherein, the credibility score is related to the performance data and test data of the migration path.

17. The code data migration method according to claim 3, characterized in that, The step of continuously updating the task graph based on the execution results in the shared space includes: If the test data or performance data of the execution results do not meet the migration target, the task graph is updated by inserting task repair nodes; Alternatively, if the test data or performance data of the execution result do not meet the migration target, the task graph is updated by adjusting the model parameters corresponding to the first task. Alternatively, if the test data or performance data of the execution results do not meet the migration target, the task graph is updated by path rollback.

18. The code data migration method according to claim 1, characterized in that, The step of continuously updating the task graph based on the execution results in the shared space includes: Obtain the cumulative duration; wherein, the cumulative duration is the duration elapsed since the last acquisition of the status of each of the nodes; If the cumulative duration is greater than or equal to the first duration, obtain the status of each node; In the case of a third node whose execution has ended, the task graph is continuously updated based on the execution result of the third node, and the cumulative duration is cleared to zero. The steps of obtaining the node status and updating the task graph are then performed again based on the relationship between the cumulative duration and the first duration. The first duration is the time interval between two consecutive node status acquisition operations.

19. A code data migration system, characterized in that, The code data migration system includes: The acquisition module is used to acquire migration project data and construct a task graph in the shared space based on the migration project data; wherein, the task graph includes multiple nodes, each node corresponding to one or more tasks; the migration project data includes source code data and migration targets; The calling module is used to determine the first task to be executed according to the task graph, call one or more target tool agents in the tool agent set to execute the first task, obtain the execution result for the source code data, and write the execution result into the shared space through the target tool agent; The migration module is used to continuously update the task graph based on the execution results in the shared space, and based on the updated task graph and the state of each node, call a new target tool agent to execute a new first task based on the execution results until a target execution result that satisfies the migration target is obtained, and the migration code data in the target execution result is used as the target code data corresponding to the source code data.

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 migration method as described in any one of claims 1 to 18.

Images