Program exception positioning method, tool and device and storage medium

Abstract

The invention provides a program exception positioning method, tool and device and a storage medium, which can determine the code position with performance exception in a source program according to two executable files with performance difference, thereby facilitating debugging of the source program to improve the running performance of the source program.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to a method, tool, device and storable medium for locating program exceptions. Background Art

[0002] In the computer field, users can use programming languages ​​to write source programs, which are converted into binary files that can be executed on a processor by a compiler. When the source program is run on a processor, performance anomalies may occur.

[0003] Usually, users can use different compilation tool chains to compile source programs, but different compilation tool chains may cause differences in the binary files corresponding to the source programs, which may cause performance anomalies in the source programs. Alternatively, users may modify the program code, which may also cause performance anomalies in the source programs. However, existing tools do not provide the function of locating performance anomalies, making it difficult for users to locate the code snippets that cause performance anomalies. Summary of the invention

[0004] Based on the existing technology, the present disclosure provides a method, tool, device and storage medium for locating program exceptions, which can determine the code location where performance exceptions occur in a source program, thereby facilitating users to debug the source program.

[0005] The present disclosure provides a method for locating program exceptions, the method comprising:

[0006] Obtaining a first executable file and a second executable file; wherein the performance of the first executable file is better than the performance of the second executable file;

[0007] Generate a first sampling log corresponding to the first executable file and a second sampling log corresponding to the second executable file;

[0008] A code location with a performance exception in a source program is determined according to the first sampling log and the second sampling log.

[0009] The present disclosure also provides a tool for locating program exceptions. The tool provides at least one function interface, and the method is implemented by calling the at least one function interface.

[0010] The present disclosure also provides a device for locating program exceptions, the device comprising a memory and a processor, the memory storing a computer program, and the method described above is implemented when the computer program is executed by the processor.

[0011] The present disclosure also provides a storage medium storing a computer executable program, wherein the computer executable program implements the method when executed by at least one processor.

[0012] The present disclosure also provides a computer program product, which includes a program or instructions, and when the computer program product is executed by at least one processor, the steps of the method are implemented.

[0013] The method, tool, device and storage medium for locating program exceptions disclosed in the present invention can generate two sampling logs corresponding to two different executable files based on two executable files with performance differences. The sampling logs are used to record performance data during the operation of the corresponding executable files, and determine the code location of the performance exception in the source program based on the performance data recorded in the two sampling logs, thereby facilitating debugging of the source program to improve the operating performance of the source program. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 A schematic diagram of an application scenario of a method and a device according to an embodiment of the present disclosure;

[0015] Figure 2 Bit Figure 1 A structural block diagram of an embodiment of a computing device;

[0016] Figure 3 A flowchart of a method for locating program anomalies according to an embodiment of the present disclosure;

[0017] Figure 4 A flowchart of a method for locating a code location with performance anomalies in a source program according to an embodiment of the present disclosure;

[0018] Figure 5 A flowchart of a method for locating a code location with performance anomalies in a source program according to an embodiment of the present disclosure;

[0019] Figure 6 A flowchart of a method for locating a code location with performance anomalies in a source program according to an embodiment of the present disclosure;

[0020] Figure 7 A flow chart of a method for determining abnormal events and abnormal hardware units according to an embodiment of the present disclosure;

[0021] Figure 8 A schematic diagram of a first event log and a second event log according to an embodiment of the present disclosure;

[0022] Fig. 9 The diagram is a schematic diagram of a first sampling log and a second sampling log according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0023] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0024] The terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of the present application and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings.

[0025] It should be understood that the term "and / or" used in this article is only a description of the same field of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the associated objects before and after are in an "or" relationship.

[0026] It should be understood that, although the terms first, second, third, etc. may be used to describe preset ranges, etc. in the embodiments of the present application, these preset ranges should not be limited to these terms. These terms are only used to distinguish preset ranges from each other. For example, without departing from the scope of the embodiments of the present application, the first preset range may also be referred to as the second preset range, and similarly, the second preset range may also be referred to as the first preset range.

[0027] The word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining" or "in response to detecting", depending on the context. Similarly, the phrases "if it is determined" or "if (stated condition or event) is detected" may be interpreted as "when it is determined" or "in response to determining" or "when detecting (stated condition or event)" or "in response to detecting (stated condition or event)", depending on the context.

[0028] In the computer field, users can use programming languages ​​to write source programs, which are a series of program codes. The source program is converted into a binary file that can be executed on a processor by a compiler. When the source program is run on a processor, performance anomalies may occur.

[0029] Usually, users can use different compilation tool chains (such as compilation tool chains of different versions) to compile the source program, but different compilation tool chains may cause differences in the binary files corresponding to the source program, which may cause performance anomalies in the source program. Alternatively, the user's modification of the program code may also cause performance anomalies in the source program. However, the existing compilation tool chain usually only provides a compiler for implementing code conversion, a performance analysis tool for analyzing program performance, and a debugging tool for debugging the program, etc. The tools provided by it cannot support the function of locating program performance anomalies, making it difficult for users to locate the code fragments that cause performance anomalies.

[0030] Based on this, the embodiments of the present disclosure aim to provide an automated program performance anomaly location tool, which can be used in conjunction with the compiler, performance analysis tools and debugging tools in the compilation tool chain to facilitate users to locate the code location in the program that causes performance anomalies, thereby helping users to debug the program code to improve the program's running performance.

[0031] To facilitate understanding of the technical solution of the present disclosure, the application scenarios of the automated performance anomaly location tool and the functions of each tool in the compilation tool chain are first introduced here.

[0032] like Figure 1 As shown, the automated performance anomaly location tool may be applied to a heterogeneous hardware device, which may include a computing device 110 and a processing device 130 having different instruction set architectures.

[0033] Among them, the computing device 110 is configured to execute user-specified operations, and is mainly implemented as a single-core intelligent processor or a multi-core intelligent processor to perform deep learning or machine learning calculations. It can interact with the processing device 130 through the interface device 120 to jointly complete the user-specified operations.

[0034] The processing device 130 is a general processing device that performs basic controls including but not limited to data handling, starting and / or stopping the computing device 110. Depending on the implementation, the processing device 130 can be a central processing unit (CPU), a graphics processing unit (GPU), or one or more types of processors in other general and / or computing devices, including but not limited to a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc., and the number of them can be determined according to actual needs. As mentioned above, only with respect to the computing device 110 of the present disclosure, it can be regarded as having a single-core structure or a homogeneous multi-core structure. However, when the computing device 110 and the processing device 130 are integrated and considered together, the two are regarded as forming a heterogeneous multi-core structure.

[0035] The interface device 120 is used to transmit data and control instructions between the computing device and the processing device. The storage device 140 is used to store data to be processed, which can be a DDR memory for storing data of the computing device 110 and / or the processing device 130.

[0036] Furthermore, the computing device may be a multi-core processor including multiple processor cores, each of which may be recorded as a hardware unit. The multiple processor cores of the computing device may form multiple clusters, and data may be communicated between the multiple clusters. By setting multiple processor cores, the parallelism of the program may be increased, thereby improving the processing efficiency of the processor.

[0037] like Figure 2 As shown, four clusters 210 are shown in the figure by way of example. With the development of hardware, the cluster of the computing device of the present disclosure may also include 8, 16, 64 or even more clusters. Each cluster 210 includes multiple processor cores 220 and a storage core 230. Four processor cores 220 are shown in the figure by way of example, and the present disclosure does not limit the number of processor cores 220. The storage core 230 may be used to implement data interaction between multiple processor cores in the same cluster, and may also be used for data interaction between clusters or between a cluster and an external storage device.

[0038] Furthermore, in order to support performance analysis of programs running on a computing device, a performance monitoring unit (PMU, not shown in the figure) is usually provided on the computing device. The performance monitoring unit is used to collect various performance indicator data of the computing device when it is running. Specifically, the performance monitoring unit can obtain and record the performance indicator data of each processor core on the computing device when it is running. The performance indicator data includes but is not limited to the number of instructions, instruction branch prediction rate, cache hit rate, etc. Optionally, the performance monitoring unit may include one or more counters, and the one or more counters are used to generate one or more performance indicator data, and the count value of each counter is used to represent the corresponding performance indicator data.

[0039] The above compilation toolchain can be run on Figure 1 On the processing device 130 shown, each tool in the compilation tool chain can be a computer program for implementing corresponding functions. The compilation tool chain can include a compiler, a performance analysis tool, and a debugging tool.

[0040] The compiler is used to convert the source program written by the user into an executable file (such as a binary file) that can be executed by a hardware device (such as a computing device). For example, the compiler may include a compile module and an assembler module, the compile module is used to convert the source program written by the user into an intermediate code, and the assembler module is used to convert the intermediate code into an executable file.

[0041] The performance analysis tool is used to help users locate the performance bottleneck of the program. The performance analysis tool is based on performance events, which can be divided into software events and hardware events. Software events refer to simple kernel function counters, such as context switching. The source of hardware events (also called PMU hardware events) is the computing device itself and the performance monitoring unit (PMU, Performance Monitoring Unit) of the computing device. Hardware events refer to events used to evaluate the microarchitecture of the computing device, such as cache hit rate, instruction branch prediction rate, cache access delay, memory bandwidth, etc. When performing performance analysis of the program, users can specify specific hardware events through the performance analysis tool. The performance analysis tool can read the performance indicator data recorded by the performance monitoring unit and generate a log file based on each hardware event and its corresponding performance indicator data. Users can locate the performance bottleneck of the program based on the log file. Furthermore, the performance analysis tool can also perform frequency sampling on specific hardware events to capture short-term performance problems in the computing device to obtain more refined performance data.

[0042] The debugging tool is used to test and debug computer programs, and the debugging tool can be GDB (GNU Symbolic Debugger). During the compilation process of the source program, the debugging tool can generate debugging information. The debugging information can be in the DWARF (Debugging With Attributed Record Formats) format, which is used to store the program's symbol table, type information, and other debugging-related data. The debugging information can include multiple sections, each of which stores different types of debugging information. For example, the debugging information may include a ".debug_line" section and a ".cn_debug_line_IR" section, wherein the ".debug_line" section is used to store the mapping relationship between the source program and the machine instruction, and can be specifically used to record the mapping relationship between the line number of the source program and the pc value (Program Counter) of the intermediate code. The ".cn_debug_line_IR" section is used to store the mapping relationship between the intermediate code and the machine instruction, and can be specifically used to record the mapping relationship between the line number of the intermediate code and the pc value of the machine instruction. In this way, the machine instruction can be matched one-to-one with the source program and the intermediate code through the debugging information, so as to facilitate the user to debug the program.

[0043] At present, the functions of the above tools in the compilation tool chain are relatively fragmented, and it is difficult for users to locate the code location of performance anomalies through the above tools. Therefore, the present disclosure provides an automated program performance anomaly location tool (hereinafter referred to as an automated tool), which can call various tools of the existing compilation tool chain, and can facilitate users to locate the code location of performance anomalies in the program by integrating and coordinating the above tools, so as to facilitate the debugging of the source program and improve the running performance of the source program.

[0044] Optionally, the automation tool supports a series of function interfaces, which can implement different functions, including but not limited to calling compilers, performance analysis tools, and debugging tools, so as to locate the code position of performance anomalies in the program. Each function interface can be implemented by a set of software instructions, and when the set of software instructions is executed by the processing device, the corresponding function of the function interface is implemented.

[0045] Optionally, the automation tool may provide at least one of the following function interfaces: a compilation function interface, a sampling function interface, an exception location function interface, a line number counting function interface, a frequency search function interface, and an abnormal event and unit acquisition function interface. Among them, the compilation function interface is used to call the compiler to obtain the first executable file and the second executable file. The sampling function interface is used to generate a first sampling log and a second sampling log. The abnormal location function interface is used to determine the code location of the performance abnormality in the source program. The line number counting function interface is used to count the number of times at least one line number appears in the second sampling log. The frequency search function interface is used to determine the high-frequency line numbers in the second sampling log. The abnormal event and unit acquisition function interface is used to determine the abnormal hardware events and abnormal hardware units where the performance abnormality occurs.

[0046] In one embodiment, the automation tool of the embodiment of the present disclosure can integrate a compilation tool chain. The above-mentioned automation tool is used to obtain a first executable file and a second executable file, wherein the performance of the first executable file is better than the performance of the second executable file; thereafter, the automation tool can obtain a first sampling log generated during the operation of the first executable file and a second sampling log generated during the operation of the second executable file, and determine the code location of the performance abnormality in the source program according to the first sampling log and the second sampling log.

[0047] Among them, the automation tool can call the compiler in the compilation tool chain through the function interface, and the compiler can be used to generate two executable files with different performance. For example, if the user uses different versions of the compiler to compile the same source program, two executable files with different performance can be obtained. For another example, if the user adjusts the code of the source program to obtain two versions of the source program, the user uses the same version of the compiler to compile the above two versions of the source program, and also obtains two executable files with different performance.

[0048] After obtaining the above-mentioned executable file through the compiler, the processing device can send the above-mentioned two executable files with performance differences to the computing device for execution respectively. Specifically, during the operation of the first executable file, the performance monitoring unit of the computing device can collect and record the first performance data of the first executable file when the computing device is running. The first performance data can include the performance data corresponding to each hardware unit of the computing device for at least one specified hardware event. During the operation of the second executable file, the performance monitoring unit of the computing device can collect and record the second performance data of the second executable file when the computing device is running. The second performance data can include the performance data corresponding to each hardware unit of the computing device for at least one specified hardware event.

[0049] Furthermore, the automation tool may call a performance analysis tool, which may obtain first performance data collected by the performance monitoring unit, and generate a first sampling log based on a specified hardware event, wherein the first sampling log may include a current PC value and a timestamp for recording the time when the PC value occurs. At the same time, the automation tool may call a performance analysis tool, which may obtain second performance data collected by the performance monitoring unit, and generate a second sampling log based on a specified hardware event, wherein the second sampling log may include a current PC value and a timestamp for recording the time when the PC value occurs. Afterwards, the tool may determine the code location of the performance anomaly in the program based on the first sampling log and the second sampling log.

[0050] Specifically, the automation tool can calculate the sampling difference time of the appearance time of the same code position in the first sampling log and the appearance time in the second sampling log according to the pc value recorded in the first sampling log and the second sampling log and its corresponding timestamp. At the same time, the automation tool disclosed in the present invention can also calculate the performance difference time according to the actual running time of the first executable file and the actual running time of the second executable file. The performance difference time can be the difference between the actual running time of the first executable file and the actual running time of the second executable file. If the sampling difference time is closer to the above-mentioned performance difference time, the greater the possibility of performance anomaly at the code position. If the difference between the sampling difference time and the above-mentioned performance difference time is larger, the smaller the possibility of performance anomaly at the code position. In this way, the code position of the performance anomaly in the program can be determined through the exception location function interface, and the specific description can be referred to the following description.

[0051] like Figure 3 As shown, the present disclosure provides a method for locating program exceptions, which can be applied to the above-mentioned automation tool to locate the code location of performance exceptions in the source program in a heterogeneous programming scenario. The method may include:

[0052] S310: Obtain a first executable file and a second executable file; wherein the performance of the first executable file is better than the performance of the second executable file.

[0053] Among them, the executable file is a binary program code that can be operated by a computing device, and the above-mentioned first executable file and second executable file can be pre-compiled by a compiler; the compiler is used to compile the source program written by the user in a programming language into an executable file.

[0054] In one embodiment, the first executable file and the second executable file are obtained by compiling the same source program. For example, when the source program is compiled using compilers of different versions, the first executable file and the second executable file with different performances can be obtained.

[0055] In another embodiment, the first executable file and the second executable file are two source programs with the same functions compiled by the same compiler. Among them, the two source programs can be respectively recorded as the first source program and the second source program, the two source programs implement the same function, and the two source programs have performance differences. For example, the second source program is simplified in program logic relative to the first source program (for example, the second source program deletes some dead codes on the basis of the first source program). In theory, the performance of the second source program will be better, but in fact, the performance of the first source program is better than that of the second source program. The two source programs can be compiled by the same version of the compiler to generate the first executable file and the second executable file, and accordingly, the performance of the first executable file is better than that of the second executable file. At this time, the method can be used to locate the code position of the performance abnormality in the second source program.

[0056] Optionally, the above-mentioned method for locating program exceptions may further include a compiling step to obtain a first executable file and a second executable file. Specifically, the automation tool disclosed herein may call a compiler through a compiling function interface to compile a source program to obtain a first executable file and a second executable file. Optionally, the input parameters of the compiling function interface may include a source program and a compiler of a specified version, after which the compiling function interface may call a compiler of a specified version to compile the source program, and the compiling function interface returns the corresponding first executable file or the second executable file.

[0057] For example, the two versions of the source program are as follows:

[0058]

[0059] The compilation function interface can be recorded as compileWithDebugLine(), then

[0060] First executable file good_exec = compileWithDebugLine(user_code, Toolchain);

[0061] The second executable file bad_exec=compileWithDebugLine(user_code, Toolchain).

[0062] The user may specify to use the same version of the compiler (Toolchain) to compile the first version of the source program and the second version of the source program to obtain the corresponding first executable file and the second executable file.

[0063] Furthermore, in the above-mentioned compilation process, the automation tool can call the debugging tool to generate corresponding debugging information, and the debugging information is used to record the corresponding relationship between the line number of the source program and the pc value of the executable file. Specifically, in the process of the compiler generating the first executable file, the debugging tool can generate the first debugging information for recording the mapping relationship between the source program and the binary instructions in the first executable file. In the process of the compiler generating the second executable file, the debugging tool can generate the second debugging information for recording the mapping relationship between the source program and the binary instructions in the second executable file.

[0064] S320: Generate a first sampling log corresponding to the first executable file and a second sampling log corresponding to the second executable file.

[0065] In a heterogeneous programming environment, the processing device may send the above two executable files with performance differences to the computing device for execution. Specifically, during the execution of the first executable file, the performance monitoring unit of the computing device may collect and record the first performance data of the first executable file when the computing device is running. During the execution of the second executable file, the performance monitoring unit of the computing device may collect and record the second performance data of the second executable file when the computing device is running. When the computing device includes multiple processor cores, the first performance data and the second performance data may include the performance data of the executable file when it is executed on each processor core on the computing device.

[0066] As described above, the performance analysis tool supports frequency sampling of specific hardware events. Therefore, the method can call the performance analysis tool through the sampling function interface, and the performance analysis tool can generate a first sampling log according to the hardware event to be sampled, and generate a second sampling log according to the hardware event to be sampled. Among them, the hardware event to be sampled can be specified by the user through the performance analysis tool.

[0067] Optionally, the input parameter of the sampling function interface may be a first executable file, and the output of the sampling function interface may be a first sampling log. The input parameter of the sampling function interface may be a second executable file, and the output of the sampling function interface may be a second sampling log. The first sampling log and the second sampling log may include performance data of the specified hardware event when it is executed on each processor core of the computing device.

[0068] S330: Determine a code location of a performance abnormality in a source program according to the first sampling log and the second sampling log.

[0069] The code position of the performance anomaly in the source program may refer to the line number of the code in the source program where the performance anomaly occurs. Since the first sampling log records the performance data of the first executable file with better performance when it is running, and the second sampling log records the performance data of the second executable file with worse performance when it is running, by analyzing the performance data recorded in the first sampling log and the second sampling log, the running performance difference of the program code at each position in the second executable file relative to the program code at the corresponding position in the first executable file can be obtained, thereby determining the code position that causes the performance anomaly.

[0070] Optionally, the above step S330 can be implemented by calling an exception locating function interface. The input parameters of the exception locating function interface can be the first sampling log and the second sampling log, and the exception locating function interface can analyze and process the first sampling log and the second sampling log, and then return the code location of the performance abnormality in the source program.

[0071] The performance anomaly locating method disclosed in the present invention can generate a first sampling log and a second sampling log during the execution of an executable file with performance differences, and automatically locate the code location of the performance anomaly in the program according to the first sampling log and the second sampling log, thereby facilitating the user to debug the source program and improve the running performance of the source program. At the same time, the performance anomaly locating method disclosed in the present invention can enable various tools and auxiliary tools of the compilation tool chain to be used in coordination by calling a series of function interfaces, so that the user can easily and quickly locate the code location of the performance anomaly in the program.

[0072] In one embodiment, the first sampling log and the second sampling log may be obtained based on a specified event to be sampled. Optionally, the hardware event to be sampled may be a hardware event specified by a user through a performance analysis tool. The specified hardware event to be sampled may be a current pc (Program Counter) value and a timestamp corresponding to the time when the current pc value appears in the sampling log, and the current pc value and its timestamp may be recorded in the sampling log accordingly.

[0073] Specifically, the sampling log can be obtained through the sampling function interface. The sampling function interface can obtain the hardware event to be sampled, and generate a first sampling log according to the hardware event to be sampled, and generate a second sampling log according to the hardware event to be sampled. Among them, the first sampling log is used to record the current PC value of the specified hardware event and the timestamp corresponding to the current PC occurrence time during the operation of the first executable file; the second sampling log is used to record the current PC value of the specified hardware event and the timestamp corresponding to the current PC occurrence time during the operation of the second executable file. In this way, the automation tool can determine the code location of the performance anomaly in the program according to the first sampling log and the second sampling log by calling the exception location function interface.

[0074] Specifically, the exception location function interface can calculate the sampling difference time of the appearance time of the same code position in the first sampling log and the appearance time in the second sampling log according to the pc value recorded in the first sampling log and the second sampling log and its corresponding timestamp. At the same time, the exception location function interface of the present disclosure can also calculate the performance difference time according to the actual running time of the first executable file and the actual running time of the second executable file. The performance difference time can be the difference between the actual running time of the first executable file and the actual running time of the second executable file. If the sampling difference time is closer to the above-mentioned performance difference time, the greater the possibility of performance anomaly at the code position. If the difference between the sampling execution difference and the above-mentioned performance difference time is larger, the smaller the possibility of performance anomaly at the code position. In this way, the code position of performance anomaly in the program can be determined through the exception location function interface, and the specific description can be referred to the description below.

[0075] In one embodiment, the source program uses a loop structure to complete the main functional calculation. The loop structure can improve the parallelism of the source program, but the loop structure is also the code structure that is most likely to affect the program performance. When the source program uses a loop structure, the same code position will appear multiple times in a loop, that is, the same pc value and its corresponding timestamp in the first sampling log and the second sampling log can appear multiple times. Therefore, the method disclosed in the present invention can analyze and process the first sampling log to determine the first time difference of the same code position (such as the current pc value or line number) in the first sampling log when the first executable file is running. At the same time, the method disclosed in the present invention can also analyze and process the second sampling log to determine the second time difference of the same code position (such as the current pc value or line number) in the second sampling day when the second executable file is running. Afterwards, the method disclosed in the present invention can calculate the sampling difference time based on the above-mentioned first time difference and the second time difference, so as to determine the code position of the performance anomaly based on the sampling difference time and the actual performance difference time. When the source program is a non-loop structure, the line number of a code will only appear once in the first sampling log and the second sampling log. At this time, the above-mentioned sampling difference time and the actual performance difference time are no longer applicable to determine the code position of the performance anomaly.

[0076] like Figure 4 As shown, the above-mentioned determination of the code location of the performance anomaly in the program may include the following method steps:

[0077] S410, replacing the current pc value in the first sampling log and the second sampling log with the line number;

[0078] The exception location function interface can replace the current PC value in the first sampling log and the second sampling log with the line number through the performance analysis tool according to the debugging information generated by the debugging tool during compilation. The debugging information can record the mapping relationship between each line number of the source program and each PC value in the executable file.

[0079] Specifically, in the process of the compiler compiling the source program into the first executable file, the debugging tool can generate first debugging information, and the first debugging information can record the correspondence between the line number of the source program and the PC value of the code in the first executable file. Similarly, in the process of the compiler compiling the source program into the second executable file, the debugging tool can generate second debugging information, and the second debugging information can record the correspondence between the line number of the source program and the PC value of the code in the second executable file. The performance analysis tool can replace the current PC value in the first sampling log with the corresponding line number by querying the first debugging information, and replace the current PC value in the second sampling log with the corresponding line number by querying the second debugging information.

[0080] After replacing the current PC value in the first sampling log and the second sampling log with the line number, performance analysis can be performed based on the specified line number therein to help locate the code position of the performance anomaly. The specified line number can be determined based on the line number appearing in the first sampling log and / or the second sampling log. Optionally, since the performance of the second executable file is lower than that of the first executable file, it is only necessary to determine the specified line number based on the second sampling log. This can increase the speed of locating the code position of the performance anomaly and improve the efficiency of performance analysis.

[0081] Optionally, the specified line number may be one or more line numbers in the second sampling log. In one embodiment, the specified line number may be a line number in the second sampling log, such as a high-frequency line number. In another embodiment, the specified line number may be all line numbers appearing in the second sampling log, or the specified line number may be a portion of all line numbers appearing in the second sampling log.

[0082] S420, calculating a first time difference between the first appearance and the last appearance of a specified line number in a first sampling log;

[0083] The first time difference corresponding to the line number may be the difference between the time of the last appearance and the time of the first appearance. The first time difference between the first appearance and the last appearance of the specified line number may be calculated based on the timestamp of the first appearance and the timestamp of the last appearance of the specified line number. The first time difference corresponding to the specified line number may be used to evaluate the running time of the program code corresponding to the specified line number. When the specified line number is a plurality of line numbers, the first time difference corresponding to each line number may be calculated separately.

[0084] S430: Calculate a second time difference between the first appearance and the last appearance of the specified line number in the second sampling log.

[0085] The second time difference corresponding to the line number may be the difference between the time of the last appearance and the time of the first appearance. The second time difference between the first appearance and the last appearance of the specified line number in the second sampling log may be calculated based on the timestamp of the first appearance and the timestamp of the last appearance of the specified line number. The second time difference corresponding to the specified line number may be used to evaluate the running time of the program code corresponding to the line number. When the specified line number is a plurality of line numbers, the second time difference corresponding to each line number may be calculated separately.

[0086] S440: Determine a code location of a performance anomaly in the source program according to the performance difference time and a first time difference and a second time difference corresponding to a specified line number.

[0087] Specifically, the exception location function interface can calculate the sampling difference time when the specified line number appears in the first sampling log and the second sampling log according to the first time difference and the second time difference corresponding to the specified line number, and the sampling difference time corresponding to the specified line number can be the difference value between the second time difference and the first time difference. Among them, the actual performance difference time is the difference value between the running time of the first executable file and the running time of the second executable file. For example, the running time of the first executable file on the computing device is T1, and the running time of the second executable file on the computing device is T2, then the performance difference time = T2-T1.

[0088] Furthermore, the exception location function interface can compare the sampling difference time corresponding to the specified line number with the actual performance difference time, and determine the line number where the sampling difference time is closest to the actual performance difference time as the code location of the performance anomaly in the source program. The closer the sampling difference time is to the above-mentioned performance difference time, the greater the possibility of a performance anomaly at that code location. The greater the difference between the sampling difference time and the above-mentioned performance difference time, the smaller the possibility of a performance anomaly at that code location. In this way, the code location of the performance anomaly in the program can be determined through the exception location function interface, and please refer to the description below for details.

[0089] Optionally, the exception location function interface can evaluate the relationship between the sampling difference time and the actual performance difference time through a time ratio, and determine the code location of the performance exception of the source program according to the time ratio. The larger the value of the time ratio, the closer the sampling difference time is to the performance difference time.

[0090] like Figure 5 As shown, the step of determining the code location of the source program with performance anomalies may further include:

[0091] S510, determining a time ratio of a sampling difference time corresponding to a specified row number to a performance difference time;

[0092] Wherein, time ratio timeRatio=sampling difference time / performance difference time.

[0093] After calculating and obtaining the time ratio corresponding to the specified line number, the code position of the performance abnormality in the source program can be determined according to the time ratio corresponding to the specified line number, that is, the code line number of the performance abnormality in the source program can be determined.

[0094] S520: Determine whether the time ratio corresponding to the specified row number is greater than or equal to a preset value.

[0095] If it is determined that the time ratio corresponding to the specified line number is greater than or equal to the preset value, step S530 is executed to determine the specified line number as the code location with abnormal performance in the source program. If the time ratio corresponding to the specified line number is less than the preset value, step S540 can be executed to update the specified line number, and return to the above step S510. The updated specified line number can be other line numbers in the source program except the specified line number before the update.

[0096] At the same time, after updating the specified row number, the maximum value of the time ratio can also be updated, and the row number corresponding to the maximum value of the time ratio can be the current specified row number. If the time ratio corresponding to the specified row number after the update is greater than the time ratio corresponding to the specified row number before the update, the maximum value of the time ratio can be set to the time ratio corresponding to the specified row number after the update.

[0097] S550: If the time ratios corresponding to all designated line numbers are smaller than a preset value, the line number corresponding to the maximum value of the time ratio is determined as the code position with the abnormal performance in the source program.

[0098] Further, if it is determined that the line number corresponding to the code position of the performance anomaly is the first line number, the line number corresponding to the maximum value of the time ratio is determined as the code position of the performance anomaly of the source program. The exception locating function interface disclosed in the present invention can sort the time ratios corresponding to each line number to obtain the line number with the largest time ratio. If the line number where the performance anomaly occurs is 0, that is, the first line number, the line number corresponding to the maximum value of the time ratio can be determined as the code position of the performance anomaly of the source program.

[0099] For example, the above preset value can be 0.5. If the time ratio corresponding to the specified line number is greater than or equal to 0.5, the specified line number can be determined as the code location of the performance anomaly of the source program. If the time ratios corresponding to the specified line numbers are all less than 0.5, the specified line numbers are updated to continue searching for line numbers with time ratios greater than or equal to 0.5. At the same time, the maximum value of the time ratio is updated. If the time ratios corresponding to all the specified line numbers are less than 0.5, the line number corresponding to the maximum value of the time ratio is determined as the code location of the performance anomaly of the source program.

[0100] In one embodiment, the specified line number may be a high-frequency line number in the second sampling log. The exception location function interface disclosed herein may determine the high-frequency line number that appears in the second sampling log through a frequency search function interface. The high-frequency line number refers to the line number that appears most times in the source program.

[0101] like Figure 6 As shown, the method for determining the code location of performance anomalies in a source program may include:

[0102] S610: Replace the current pc values ​​in the first sampling log and the second sampling log with line numbers, and obtain the number of occurrences of each line number from the second sampling log.

[0103] The exception location function interface can replace the pc value recorded in the first sampling log and the second sampling log with the line number by calling the performance analysis tool and combining the debugging information generated by the debugging tool.

[0104] The method disclosed herein can obtain the number of times each line number appears in the second sampling log by calling a line number counting function interface. For example, the line number counting function interface can be getLineNumberNum(), the input parameter of the function interface can be the second sampling log, and the return value of the function interface can be the number of times each line number appears in the second sampling log.

[0105] S620: Determine the high-frequency line number according to the number of times each line number appears in the second sampling log. The high-frequency line number may be the line number that appears most frequently in the second sampling log. Optionally, the high-frequency line number may also be obtained through a frequency search function interface.

[0106] For example, the frequency search function interface may be findNextHighFrequencyLineNumber(), the input parameters of the function interface may be the second sampling log and the input line number, and the return value of the function interface may be the high-frequency line number. If there are multiple line numbers with the same number of occurrences in the second sampling log, the function interface may return multiple high-frequency line numbers in sequence.

[0107] Among them, the initial value of the input line number can be 0. If the input line number is the initial value, the function interface can return the line number that appears most times in the second sampling log, that is, the high-frequency line number. The high-frequency line number can be used to locate the code position of the performance anomaly in the source program. Further, if the code position of the performance anomaly in the source program is located by the high-frequency line number, the method is executed; if the code position of the performance anomaly in the source program is not located by the high-frequency line number, the method can also continue the above method by updating the high-frequency line number. If the input line number is not 0, for example, the input line number is a high-frequency line number before the update, the function interface can return a line number that appears less than or equal to the number of times the input line number appears. In this way, the updated high-frequency line number can be determined through the function interface.

[0108] S630, calculating a first time difference between the first and last appearance of the high-frequency line number in the first sampling log; calculating a second time difference between the first and last appearance of the high-frequency line number in the second sampling log.

[0109] The method disclosed herein can calculate the first time difference based on the timestamp when the high-frequency line number first appears in the first sampling log and the timestamp when it last appears; and calculate the second time difference based on the timestamp when the high-frequency line number first appears in the second sampling log and the timestamp when it last appears. For details, refer to the calculation method of the above embodiment.

[0110] S640: Calculate a sampling difference time according to the first time difference and the second time difference; wherein the sampling difference time may be equal to the difference between the second time difference and the first time difference. The sampling difference time may be used to evaluate the performance difference value when the high-frequency line number is running in two executable files with performance differences.

[0111] S650: Determine the time ratio corresponding to the high-frequency row number according to the sampling difference time and the actual performance difference time, wherein the time ratio corresponding to the high-frequency row number=sampling difference time / performance difference time.

[0112] S660: Determine whether the time ratio corresponding to the high-frequency row number is greater than or equal to a preset value, for example, the preset value may be 0.5.

[0113] If the time ratio corresponding to the high-frequency line number is greater than or equal to the preset value, step S670 is executed to use the high-frequency line number as the code position of the performance abnormality in the source program.

[0114] If the time ratio corresponding to the high-frequency line number is less than the preset value, execute step S680, and continue to search for the high-frequency line number from other line numbers in the second sampling log to update the high-frequency line number until all line numbers appearing in the second sampling log are traversed. Specifically, if the time ratio corresponding to the high-frequency line number is less than the preset value, the above-mentioned frequency search function interface findNextHighFrequencyLineNumber() can be used to search for the high-frequency line number in other line numbers to update the high-frequency line number. At this time, the input line number of the frequency search function interface can be the high-frequency line number before the update, and the frequency search function interface returns the updated high-frequency line number, and the number of occurrences of the updated high-frequency line number is less than or equal to the number of occurrences of the high-frequency line number before the update.

[0115] S690: If the time ratios corresponding to all line numbers are smaller than a preset value, the line number corresponding to the maximum value of the time ratio is determined as the code position with the abnormal performance in the source program.

[0116] Further, if it is determined that the code position of the performance anomaly is the first line of code, that is, the code line number of the performance anomaly is 0, the line number corresponding to the maximum value of the time ratio in the second sampling log is determined as the code position of the performance anomaly in the source program.

[0117] In one embodiment, the above-mentioned specified line number may be part or all of the line numbers appearing in the second sampling log. At this time, the above-mentioned exception locating function interface may be used to implement the following method steps:

[0118] S1. Calculate the first time difference between the first and last appearance of each line number in the first sampling log, and calculate the second time difference between the first and last appearance of each line number in the second sampling log; wherein, the calculation method of the first time difference and the second time difference corresponding to each line number is as described above.

[0119] S2. Calculate the sampling difference time corresponding to each row number according to the first time difference and the second time difference corresponding to each row number. Then, determine the time ratio corresponding to each row number according to the sampling difference time corresponding to each row number and the actual running difference time. The calculation method of the sampling difference time and time ratio corresponding to each row number can be found in the above text.

[0120] If there is a time ratio corresponding to each line number that is greater than or equal to a preset value, the line number whose time ratio is greater than or equal to the preset value is determined as the code position of the performance abnormality in the source program. If the time ratios corresponding to each line number are all less than the preset value, the time ratios corresponding to each line number are sorted, and the line number corresponding to the maximum value of the time ratio is used as the code position of the performance abnormality in the source program. Furthermore, if it is determined that the code position of the performance abnormality in the source program is the first line number, the line number corresponding to the maximum value of the time ratio is used as the code position of the performance abnormality in the source program.

[0121] Furthermore, if the specified line number may be part of the line numbers appearing in the second sampling log, when the time ratios corresponding to the part of the line numbers are all less than the preset value, the specified line number can be updated according to the remaining line numbers in the second sampling log and the above steps can be repeated.

[0122] In one embodiment, in order to improve the accuracy of locating the code position of the performance anomaly in the source program, the method of the present disclosure can also sample the hardware events when the executable file is running on a specific hardware unit to improve the accuracy of the anomaly location. The above method also includes:

[0123] Obtain a hardware unit to be sampled; wherein the hardware unit to be sampled may be an abnormal hardware unit with abnormal performance. The abnormal hardware unit may be predetermined, and the method for locating the abnormal hardware unit may be specifically described below.

[0124] For the hardware unit to be sampled, a first sampling log is generated according to the hardware event to be sampled; for the hardware unit to be sampled, a second sampling log is generated according to the hardware event to be sampled.

[0125] As mentioned above, the hardware event to be sampled may be a hardware event specified by a user through a performance analysis tool. The specified hardware event may be a current pc (Program Counter) value and a timestamp corresponding to the time when the current pc value appears in a sampling log. The current pc value and its timestamp may be recorded in the sampling log accordingly, and the sampling log may be obtained through a sampling function interface.

[0126] Specifically, the sampling function interface can obtain the hardware event to be sampled, and generate a first sampling log according to the performance data when the first executable file is running on the hardware unit to be sampled. The sampling function interface can obtain the hardware event to be sampled, and generate a second sampling log according to the performance data when the second executable file is running on the hardware unit to be sampled. Therefore, the above-mentioned first sampling log and second sampling log only record the current PC value and its timestamp corresponding to the hardware unit to be sampled, which can reduce the data volume of the first sampling log and the second sampling log, thereby reducing the storage space of the sampling log and improving the generation speed of the sampling log. In addition, the sampling function interface disclosed in the present invention only collects performance data for the hardware unit to be sampled, which can improve the accuracy of subsequent performance anomaly analysis.

[0127] In one embodiment, the method of the embodiment of the present disclosure may also include a step of determining an abnormal hardware unit to indicate an abnormal hardware event that causes performance abnormality, thereby improving the accuracy and efficiency of locating the code position of the performance abnormality. The above-mentioned step of determining the abnormal hardware unit may be implemented by calling a function interface of an automation tool. For example, the above-mentioned automation tool may provide an abnormal event and a unit acquisition function interface to determine the above-mentioned abnormal hardware unit.

[0128] Optionally, abnormal hardware events and abnormal hardware units are obtained by calling an abnormal event and unit acquisition function interface. The input parameters of the abnormal event and hardware unit acquisition function interface can be a first executable file and a second executable file. The abnormal event and unit acquisition function interface can implement the following method steps and return abnormal hardware events and abnormal hardware units.

[0129] like Figure 7 As shown, the above method may further include the following steps:

[0130] S710, obtaining a first event log and a second event log;

[0131] After the compiler generates the first executable file, the processing device can send the first executable file to the computing device for execution to implement a series of computing functions of the source program. At least one hardware unit (i.e., processor core) of the computing device executes the first executable file, and the performance monitoring unit in the computing device that is turned on can be used to record performance data during the operation of the first executable file. The performance analysis tool can obtain performance data during the operation of the first executable file through hardware events specified by the user and generate a first event log.

[0132] After the compiler generates the second executable file, the processing device can send the second executable file to the computing device for execution to implement a series of computing functions of the source program. At least one hardware unit (i.e., processor core) of the computing device executes the second executable file, and the performance monitoring unit in the computing device that is turned on can be used to record performance data during the operation of the second executable file. The performance analysis tool can obtain performance data during the operation of the second executable file through hardware events specified by the user and generate a second event log.

[0133] The hardware event may be all or part of the hardware events supported by the performance monitoring unit, and the hardware event includes but is not limited to cache hit rate, instruction branch prediction rate, cache access delay, memory bandwidth, etc. The first event log is used to record the performance data of each specified hardware event on at least one hardware unit. The second event log is used to record the performance data of each specified hardware event on at least one hardware unit.

[0134] S720: Determine an abnormal hardware event according to the first event log and the second event log.

[0135] According to the first event log and the second event log, the performance difference of each hardware event can be determined, and the performance difference is used to evaluate the performance difference of the hardware event during the operation of two executable files with performance differences, so that an abnormal hardware event can be determined according to the performance difference of at least one hardware event. The larger the difference corresponding to the hardware event, the greater the possibility that the hardware event is abnormal; the smaller the difference corresponding to the hardware event, the smaller the possibility that the hardware event is abnormal, so that an abnormal hardware event can be determined.

[0136] Among them, the performance data of a hardware event in the first event log can be calculated based on the performance data of the hardware event on at least one hardware unit of the hardware device. Specifically, for each hardware event in the first event log, the method disclosed in the present invention can traverse the performance data of the hardware event in at least one hardware unit from the first event log to obtain a first comprehensive performance value, and the first comprehensive performance value can be the sum of the performance data of the hardware event on at least one hardware unit. For each hardware event in the second event log, the method disclosed in the present invention can traverse the performance data of the hardware event in at least one hardware unit from the second event log to obtain a second comprehensive performance value, and the second comprehensive performance value can be the sum of the performance data of the hardware event on at least one hardware unit. For each hardware event, the performance difference of the hardware event is evaluated according to the first comprehensive performance value and the second comprehensive performance value of the hardware event, respectively, so as to determine the abnormal hardware event.

[0137] Optionally, for each hardware event, the method disclosed herein can calculate a performance difference based on a first comprehensive performance value and a second comprehensive performance value of the hardware event, where the performance difference can be the difference between the first comprehensive performance value and the second comprehensive performance value, and determine an abnormal hardware event based on the performance difference.

[0138] Furthermore, the method disclosed herein can use a performance ratio to evaluate the performance difference of each hardware event, and the performance difference can be the ratio of the above-mentioned performance difference value to the first comprehensive performance value. Therefore, the method disclosed herein can sort the performance difference corresponding to at least one hardware event, and determine the hardware event with the largest performance difference as an abnormal hardware event.

[0139] The method disclosed in the present invention can determine abnormal hardware events based on the first event log and the second event log, thereby indicating the direction of the code with performance abnormalities and improving the efficiency of locating the code position of the performance abnormalities.

[0140] Furthermore, the method disclosed in the present invention can also locate the hardware unit with the abnormal performance according to the performance data of the abnormal hardware event in the first event log and the second event log, thereby further simplifying the step of locating the code position of the performance abnormality. At the same time, locating the hardware unit with the abnormal performance can also make the results of the first sampling log and the second sampling log more accurate. Figure 7 As shown, the above method also includes:

[0141] S730: Determine, according to the first event log and the second event log, a performance difference of an abnormal hardware event on the same hardware unit.

[0142] As described above, the first event log and the second event log can record the performance data of each hardware event when it is running on each hardware unit. The method disclosed in the present invention can obtain the first performance data of the abnormal hardware event when it is running on a hardware unit from the first event log, obtain the second performance data of the abnormal hardware event when it is running on the same hardware unit from the second event log, and determine the performance difference corresponding to the hardware unit based on the first performance data and the second performance data.

[0143] Optionally, the present disclosure first determines the performance difference when the abnormal hardware event runs on the hardware unit based on the first performance data and the second performance data, and takes the ratio of the performance difference to the first performance data as the performance difference degree corresponding to the hardware unit, and evaluates the performance difference of the abnormal hardware event on the same hardware unit based on the performance difference degree corresponding to the hardware unit.

[0144] In the case where the computing device is a multi-core processor, the performance difference corresponding to each hardware unit (ie, processor core) of the computing device may be calculated respectively, so as to locate the abnormal hardware unit with abnormal performance.

[0145] S740: Determine an abnormal hardware unit according to the performance difference of the abnormal hardware event on the same hardware unit; wherein the abnormal hardware unit can serve as a hardware unit to be sampled.

[0146] Generally, the greater the performance difference corresponding to the abnormal hardware event in the same hardware unit, the greater the possibility of a performance abnormality in the hardware unit. The method disclosed in the present invention can calculate the performance difference of each hardware unit based on the first performance data and the second performance data, and determine the hardware unit with the largest performance difference as the abnormal hardware unit. When the abnormal hardware event is a waiting event (such as a synchronization event such as sync or barrier), the smaller the performance difference corresponding to the abnormal hardware event in the same hardware unit, the greater the possibility of a performance abnormality in the hardware unit. At this time, the method disclosed in the present invention can calculate the performance difference of each hardware unit based on the first performance data and the second performance data, and determine the hardware unit with the smallest performance difference as the abnormal hardware unit.

[0147] The abnormal hardware unit serves as the hardware unit to be sampled, so that a first sampling log and a second sampling log can be generated for the abnormal hardware unit, so as to determine the code location of the performance abnormality in the source program according to the first sampling log and the second sampling log. Figure 7 , the above method may further include:

[0148] S750: For the abnormal hardware unit, generate a first sampling log according to the hardware event to be sampled; for the abnormal hardware unit, generate a second sampling log according to the hardware event to be sampled.

[0149] S760: Determine a code location of a performance abnormality in a source program according to the first sampling log and the second sampling log.

[0150] In this embodiment, the automation tool determines the code location of the performance anomaly in the source program by calling the exception locating function interface. Specifically, the exception locating function interface can determine the code location of the performance anomaly in the source program based on the first sampling log and the second sampling log. The method steps implemented by the exception locating function interface are the same as those described above. Figure 4-Figure 6 The method steps of any embodiment are consistent, and the details can be found in the above description.

[0151] Below Figure 6 and Figure 7 The illustrated embodiment illustrates a method for locating a code position of a performance anomaly according to an embodiment of the present disclosure.

[0152] The two versions of the source code are as follows:

[0153] / / Source program before modification

[0154] uint32_t num=(num_classes>=4)? num_classes:4;

[0155] / / Modified source program

[0156] uint32_t num = 4;

[0157] Among them, the user has made a minor adjustment to the source program code. Intuitively, the modified source program version is more concise than the source program version before the modification, and theoretically should have better performance, but in fact, the performance of the modified source program version has deteriorated, and the performance of the source program version before the modification is better than the modified source program version. The method disclosed in the present invention aims to locate the code position of the modified source program in the program.

[0158] First, the automation tool can call the compile and debug interface, for example, the compileWithDebugLine() function, which can output a first executable file and a second executable file, wherein the first executable file corresponds to the source program before modification, the second executable file corresponds to the source program after modification, and the performance of the first executable file is better than that of the second executable file. At the same time, the compile and debug interface can also return first debugging information corresponding to the first executable file and second debugging information corresponding to the second executable file.

[0159] Secondly, the automation tool can call the abnormal event and unit acquisition function interface, such as calling the getAbnormalEventAndCore() function, which can call the performance analysis tool in the compilation tool chain. The performance analysis tool can receive the hardware event specified by the user and generate and record the first event log when the first executable file is running on the computing device and the second event log when the second executable file is running on the computing device according to the hardware event specified by the user. The first event log and the second event log are as follows: Figure 8 As shown, core, core1, core2, and core3 represent hardware units of the computing device, respectively. Pmu in the figure represents a specified hardware event. Good performance represents the first event log, and poor performance represents the second event log.

[0160] Afterwards, the function interface can calculate the sum of the performance data of each hardware event on at least one hardware unit according to the first event log to obtain a first comprehensive performance value. At the same time, the function interface can also calculate the sum of the performance data of each hardware event on at least one hardware unit according to the second event log to obtain a second comprehensive performance value. Thus, the function interface can determine the performance difference according to the first comprehensive performance value and the second comprehensive performance value, and determine the hardware event with the performance difference as an abnormal hardware event. Figure 8 As shown, the abnormal hardware event is "barrier_sync_wait_cycles", which belongs to the wait event.

[0161] After determining the abnormal hardware event, the function interface can also compare the performance differences of the abnormal hardware event on various hardware units. Figure 8 It can be seen that the performance difference of core0 is small, while the performance differences of core1, core2, and core3 are increasing, indicating that the remaining core1, core2, and core3 are all waiting for core0, that is, the abnormal hardware unit is core0.

[0162] Again, the automation tool can call the sampling function interface, such as the runHighrateSampling() function, which can call the performance analysis tool, use the performance analysis tool to sample the hardware events to be sampled, and generate the first sampling log and the second sampling log. Among them, the hardware event to be sampled is the current pc value and its corresponding timestamp. At the same time, since the abnormal hardware unit has been determined, when sampling, it is only necessary to sample the hardware events to be sampled running on the above-mentioned abnormal hardware unit core0. The first sampling log and the second sampling log returned by the function interface are as follows: Fig. 9As shown, (a) represents the first sampling log, and (b) represents the second sampling log. 158 or 177 represents the line number corresponding to the current pc value after replacement, 0x27dd1... in the first sampling log represents the timestamp corresponding to each line number, and 0x18eb... in the second sampling log represents the timestamp corresponding to each line number.

[0163] Finally, the automation tool determines the code location of the performance abnormality in the program by calling the exception location function interface, such as the getAbnormalLineNumber() function, which may be the code line number of the performance abnormality in the program.

[0164] The function interface can use the performance analysis tool to replace the current pc value in the first sampling log and the second sampling log with the line number. Then, the function interface can use the frequency search function interface, such as the findNextHighFrequencyLineNumber() function to determine the high-frequency line number in the second sampling log. Fig. 9 As can be seen from the second sample log shown, the high frequency row number is 158.

[0165] Afterwards, the function interface can calculate the first time difference between the first and last appearance of the high-frequency line number in the first sampling log, such as Fig. 9 As shown in (a), the timestamp value of the high-frequency line number when it first appears minus the timestamp value when it last appears = 4502. At the same time, the function interface can also calculate the second time difference between the first and last appearance of the high-frequency line number in the second sampling log, as shown in Fig. 9 As shown in (b), the timestamp value of the high-frequency line number when it first appears - the timestamp value when it last appears = 6804. Then, the function interface can calculate the sampling difference time based on the above first time difference and the second time difference. The timestamp difference between the two versions is 2302 counters. Under the architecture of the computing device, one timestamp counter is about 40ns, and 2302 counters are about 92us. The performance difference time between the first executable file and the second executable file is 440-325=115us, and the above sampling difference time is basically consistent with the performance difference time. Therefore, it can be concluded that the high-frequency line number 158 is the source code line number that causes the performance anomaly.

[0166] The disclosed automated tool and method for locating program anomalies can locate the code location, abnormal hardware events, and abnormal hardware units that cause performance anomalies in the source program. The code location of the performance anomaly is used to indicate the source of the performance anomaly, the abnormal hardware event indicates the direction of the performance anomaly (register allocation, cache hit rate, branch prediction, etc.), and the abnormal hardware unit indicates the processor core that causes the performance anomaly and makes the high-precision sampling result more accurate. In this way, basic information support is provided for subsequent users to perform performance anomaly analysis, which is convenient for users to debug and analyze the program to improve the performance of the source program.

[0167] The present disclosure also provides a device for locating program anomalies, the device comprising a memory and a processor, the memory storing a computer program, and when the computer program is executed by the processor, the steps of the above method embodiment are implemented. Specifically, the above processor may be the above processing device, such as a central processing unit (CPU), and when the computer executable program is executed by the processor, the following steps are implemented:

[0168] Obtaining a first executable file and a second executable file corresponding to a source program; wherein the performance of the first executable file is better than the performance of the second executable file;

[0169] Generate a first sampling log corresponding to the first executable file and a second sampling log corresponding to the second executable file;

[0170] A code location with a performance exception in a source program is determined according to the first sampling log and the second sampling log.

[0171] The implementation steps of the embodiments of the present disclosure are basically the same as the implementation steps of the above-mentioned method embodiments. For details, please refer to the above description and will not be repeated here.

[0172] The present disclosure also provides a storage medium, wherein a computer executable program is stored. When the computer executable program is executed by at least one processor, the steps of the method in the above embodiment are implemented. Specifically, when the computer executable program is executed by at least one processor, the following steps are implemented:

[0173] Obtaining a first executable file and a second executable file corresponding to a source program; wherein the performance of the first executable file is better than the performance of the second executable file;

[0174] Generate a first sampling log corresponding to the first executable file and a second sampling log corresponding to the second executable file;

[0175] A code location with a performance exception in a source program is determined according to the first sampling log and the second sampling log.

[0176] The implementation steps of the embodiments of the present disclosure are basically the same as the implementation steps of the above-mentioned method embodiments. For details, please refer to the above description and will not be repeated here.

[0177] Among them, the storage medium can be a computer-readable storage medium, for example, a ferroelectric random access memory (FRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic surface memory, an optical disk, or a compact disk read-only memory (CD-ROM) and other memories; it can also be various devices including one or any combination of the above memories.

[0178] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0179] The above-mentioned embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the patent of the present application shall be subject to the attached claims.

Claims

1. A method for locating program anomalies, characterized in that: The method comprises: Obtaining a first executable file and a second executable file; wherein the performance of the first executable file is better than the performance of the second executable file; Generate a first sampling log corresponding to the first executable file and a second sampling log corresponding to the second executable file; A code location with a performance exception in a source program is determined according to the first sampling log and the second sampling log.

2. The method according to claim 1, characterized in that The generating a first sampling log corresponding to the first executable file and a second sampling log corresponding to the second executable file includes: Get the hardware events to be sampled; Generate a first sampling log according to the hardware event to be sampled; A second sampling log is generated according to the hardware event to be sampled.

3. The method according to claim 2, characterized in that The generating of a first sampling log corresponding to the first executable file and a second sampling log corresponding to the second executable file further includes: Get the hardware unit to be sampled; For the hardware unit to be sampled, generating the first sampling log according to the hardware event to be sampled; For the hardware unit to be sampled, the second sampling log is generated according to the hardware event to be sampled.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: Generate the first sampling log and the second sampling log by calling a sampling function interface; The code position of the performance exception in the source program is determined by calling the exception locating function interface.

5. The method according to claim 1, characterized in that The determining, according to the first sampling log and the second sampling log, a code location of a performance abnormality in a source program includes: Replace the current pc values ​​in the first sampling log and the second sampling log with line numbers equivalently; Calculate a first time difference between the first appearance and the last appearance of a specified line number in the first sampling log; Calculate a second time difference between the first appearance and the last appearance of the specified line number in the second sampling log; The code position of the performance abnormality in the source program is determined according to the performance difference time and the first time difference and the second time difference corresponding to the specified line number.

6. The method according to claim 5, characterized in that The determining, according to the performance difference time and the first time difference and the second time difference corresponding to the specified line number, the code position of the performance abnormality in the source program includes: Calculate the sampling difference time corresponding to the specified row number according to the first time difference and the second time difference corresponding to the specified row number; The code position of the performance abnormality in the source program is determined according to the sampling difference time and the performance difference time corresponding to the specified line number.

7. The method according to claim 6, characterized in that Determining the code position of the performance abnormality in the source program according to the sampling difference time and the performance difference time corresponding to the specified line number includes: Determine a time ratio of the sampling difference time corresponding to the specified row number to the performance difference time; If the time ratio corresponding to the specified line number is greater than or equal to a preset value, the specified line number is determined as a code position with abnormal performance in the source program; If the time ratio corresponding to the designated row number is less than a preset value, the designated row number is updated.

8. The method according to claim 7, characterized in that The method further comprises: If the time ratios corresponding to all designated line numbers are less than or equal to a preset value, the line number corresponding to the maximum value of the time ratio is determined as the code position with the performance abnormality in the source program.

9. The method according to claim 7, characterized in that: The method further comprises: If it is determined that the line number corresponding to the code position with the performance abnormality is the first line number, the line number corresponding to the maximum value of the time ratio is determined as the code position with the performance abnormality in the source program.

10. The method according to any one of claims 5 to 9, characterized in that: The specified line number is a high-frequency line number in the second sampling log; the method further includes: The high-frequency line numbers in the second sampling log are determined to determine the code location of the performance abnormality in the source program according to the performance difference time and the first time difference and the second time difference corresponding to the high-frequency line numbers.

11. The method according to claim 10, characterized in that The method further comprises: Calculate the number of occurrences of at least one line number in the second sampling log through a line number counting function interface; The high-frequency line number in the second sampling log is determined through a frequency search function interface.

12. The method according to any one of claims 1 to 11, characterized in that: The method further comprises: Obtain a first event log and a second event log; An abnormal hardware event is determined according to the first event log and the second event log.

13. The method according to claim 12, characterized in that The determining an abnormal hardware event according to the first event log and the second event log includes: For each hardware event in the first event log, calculating a first comprehensive performance value of the hardware event according to performance data of the hardware event on at least one hardware unit; For each hardware event in the second event log, calculating a second comprehensive performance value of the hardware event according to performance data of the hardware event on at least one hardware unit; The abnormal hardware event is determined according to the first comprehensive performance value and the second comprehensive performance value corresponding to the hardware event.

14. The method according to claim 12, characterized in that The method further comprises: Determine, according to the first event log and the second event log, a performance difference of the abnormal hardware event on the same hardware unit; According to the performance difference of the abnormal hardware event on the same hardware unit, the abnormal hardware unit is determined; wherein the abnormal hardware unit can serve as the hardware unit to be sampled.

15. The method according to claim 14, characterized in that The method further comprises: The abnormal hardware event and abnormal hardware unit are obtained by calling the abnormal event and unit acquisition function interface.

16. A tool for locating program anomalies, characterized in that: The tool provides at least one function interface, and the method according to any one of claims 1 to 15 is implemented by calling the at least one function interface.

17. A device for locating program anomalies, characterized in that: The device includes a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the method according to any one of claims 1 to 15 is implemented.

18. A storage medium storing a computer executable program, wherein the computer executable program, when executed by at least one processor, implements the method according to any one of claims 1 to 15.

Images