COMPUTER-IMPLEMENTED METHOD FOR THE EFFICIENT FORMULATION AND EFFICIENT EXECUTION OF GENERAL NUMERICAL ALGORITHMS WITHIN MEMORY-MANAGED ENVIRONMENTS

Abstract

Computer-implemented method for the efficient formulation and efficient execution of general numerical algorithms within a memory-managed environment, whereby specific methods of memory management adapted to the numerical algorithms are implemented and used to provide and manage memory blocks, which, unlike those methods provided by the memory-managed environment, are geared to special requirements when executing numerical algorithms, and whereby various array classes are provided for the formulation of the numerical algorithms, which are automatically selected depending on the intended lifetime of an array.

Description

[0001] The invention relates to a computer-implemented method for the efficient formulation and efficient execution of general numerical algorithms within memory-managed environments. Such algorithms form the basis of virtually any technical implementation of scientific findings into executable applications involving data. A few examples of technical implementations using numerical algorithms are: applications for risk assessment in financial transactions, control applications for controlling production lines in automotive engineering, applications for processing data from computer tomography scanners, signal processing chains for mobile communications systems, simulations of flow acoustics on aircraft turbine blades, etc.

[0002] In the publication by RISCO-MARTIN, Jose L., COLMENAR, J. Manuel, ATIENZA, David et al.: "Simulation of High-Performance Memory Allocators", in: 2010 13th Euromicro Conference on Digital System Design: Architectures, Methods and Tools, 2010, pages 275-282, a flexible and efficient simulator for investigating dynamic memory managers (DMMs) is described. Within a search procedure, a system designer can select the "best" allocator for a specific target application and embedded system through simulation. In the publication by Chia-Tien Dan Lo, W. Srisa-An, JM Chang: "A quantitative simulator for dynamic memory managers", in: 2000 IEEE International Symposium on Performance Analysis of Systems and Software. ISPASS (Cat. No.00EX422), IEEE Conference Paper, 2000, presents a quantitative simulator for dynamic memory management and memory tracing techniques.At the end of each simulation run, various performance metrics are presented to the user. This approach allows software developers to evaluate system performance and decide which algorithm is best suited for their applications. Furthermore, the paper by BERGER, Emery D., ZORN, Benjamin G., MCKINLEY, Kathryn S.: "Reconsidering Custom Memory Allocation," in: OOPSLA '02, November 4-8, 2002, Seattle, Washington, USA, 2002 ACM, examines eight applications that use custom allocators and proposes a generalization of general-purpose and region-based allocators.

[0003] Numerical algorithms can, in principle, be created and executed in any modern computer system. Individual systems differ significantly in the efficiency of algorithm formulation, the speed of execution, and the complexity of the infrastructure available to the programmer for embedding algorithms into executable programs. Prominent examples include FORTRAN and numpy / scipy, as well as C / C++ and Matlab®.

[0004] Many environments offer a high degree of convenience in formulating numerical algorithms while simultaneously offering a rich spectrum of advanced functionality, which is also important for application development. However, one disadvantage is that these environments provide scripting languages ​​that are only partially suitable for creating enterprise applications. Examples include numpy and Matlab®. The consequence—as with the use of FORTRAN algorithms—is a heterogeneous system break: the programmer implements the numerical algorithms in a different language than the one chosen for the main application. This leads to more complex development and higher costs for the creation and maintenance of an application.

[0005] The most commonly used platforms for enterprise applications today are JAVA EE (Oracle®) and .NET (Microsoft®). However, both are only marginally used to implement numerical algorithms. The reason for this is their poor execution speed. .NET and Java represent "memory-managed" environments (hereinafter: environment). These are characterized, among other things, by the fact that the developer (i.e. the user of these environments) generally does not manage the memory blocks for running computer programs themselves. Instead, they use memory blocks provided by the environment. A mechanism known as the "garbage collector" (GC) ensures that memory blocks that are no longer needed are identified and returned to the operating system.A further advantage of these environments is the platform independence of the generated bytecode and the potential for dynamic execution optimization on the target architecture.

[0006] The GC process is optimized for the requirements of enterprise and desktop applications that prioritize the use of small memory blocks. It brings popular advantages, such as increased system security. However, all modern implementations of these environments are unsuitable for meeting the memory management requirements of numerical algorithms: The naive attempt to implement a non-trivial numerical algorithm in a memory-managed environment results in negative consequences, such as memory fragmentation, excessive GC activity, degraded data locality, and ultimately significantly increased program execution speed compared to non-memory-managed environments. Previous attempts to circumvent these disadvantages resulted in increased effort for the developer of numerical algorithms when formulating the algorithms.The developer can no longer concentrate solely on the mathematical formulation, but must constantly consider memory management. This—as well as excessively slow execution—prevents widespread acceptance.

[0007] The present invention aims to make memory-managed environments accessible for the formulation and execution of numerical algorithms—even for relevant problem sizes—without sacrificing convenient language elements. This is achieved by implementing memory management specifically tailored to the requirements of numerical algorithms, thus relieving the environment of the responsibility for managing these (usually 'large') memory blocks. As a result, numerical algorithms implemented using the methods of the invention can be executed at the same speed known from non-memory-managed environments. At the same time, all the advantages of the memory-managed environment are retained, which is essential for acceptance by a broad range of users.

[0008] The invention can be implemented as a user library that allows users to use a managed environment directly to implement numerical algorithms.

[0009] The method uses the features of modern programming languages ​​to conceal memory management from the user and allow the formulation of algorithms based on the convenient scripting languages ​​of modern mathematical programs. These features are explained below.

[0010] The invention implements a memory base that provides all memory blocks required to execute a numerical algorithm. After a memory block of an array has been used for the last time in the algorithm, the invention ensures that the memory block associated with the array is returned to the memory base to be available for future steps of the algorithm.

[0011] In memory-managed environments, developers are not given the option to determine when an object is released ("nondeterministic disposal"). Rather, the environment determines the release time independently through the use of the GC. This represents the core of the term "memory-managed." Generally, however, the GC only kicks in when the operating system can no longer fulfill a memory allocation request, since all available memory on the computer is already allocated to running programs. However, this time is not suitable for efficient management of memory blocks in the context of numerical algorithms, as the garbage collection architecture poses the risk of severe memory fragmentation.Also, due to the size of the memory blocks, otherwise effective countermeasures such as compacting memory areas (“compacting GC”) cannot be applied efficiently in this context.

[0012] Rather, it is necessary to implement deterministic disposal to release a memory block immediately after use, i.e., to transfer it to the memory base. This "deterministic disposal" is implemented with the invention as follows: Array classes are provided that correspond to the intended lifetime of a numeric object. Two types of array classes must be distinguished: 1) Local arrays or permanent arrays, and 2) temporary arrays.

[0013] Local array variables are always of the local array type. Their validity period ends after the current algorithm completes. These arrays can be used repeatedly within that algorithm.

[0014] Most arrays created during any algorithm fall into the category of temporary arrays. They are the return type of all elementary mathematical operations and all algorithms. In common expressions such as sin(abs(A+pi))−2.3*cos(abs(A*A)+pi / 2) only temporary arrays are involved, with the exception of the constant pi and the local variable A.

[0015] The invention specifies that temporary arrays are used only once. After this use, the memory block associated with the array is immediately transferred to the memory base. The term "use" here refers to one of the following three possible uses of an array: 1) use as a parameter in function calls, 2) use of instance functions on the array, or 3) conversion to a local array. The invention ensures that when using the classes it provides, all temporary arrays are released after the first use, and the memory block associated with the array is immediately transferred to the memory base.

[0016] The memory blocks associated with local arrays are freed using constructs provided by all modern programming languages ​​for memory-managed environments. These are known, for example, from Java or .NET as "try / catch / finally" constructs. For this purpose, the body of each algorithm is enclosed in such a construct, which creates an artificial scope. In the "try" part, this scope is established in the form of a stack class. As the algorithm progresses, all newly created local arrays are collected in the stack and freed again in the "finally" part. This achieves deterministic freeing, which allows any memory blocks to be transferred back to the memory base immediately after they are used.

[0017] Since the memory blocks required for individual calculation steps within an algorithm vary in size over the course of the algorithm, it cannot be assumed with complete certainty that an already used memory block can be reused in every case. Rather, it is possible that a calculation step requires a memory block that is larger than the one potentially available in the memory base. In this case, a new memory block is requested from the operating system, and the new memory block is included in the invention's recycling cycle.

[0018] The reverse case, however, can be solved more efficiently. If a memory block is required for which there is no exact equivalent in the memory base, any memory block that is at least the required size can be used. The memory base of the invention may therefore also deliver memory blocks that are actually too large if this avoids reallocation by the operating system. In contrast to established memory base systems ("pools"), the use of memory blocks of variable size for the purpose of optimized reuse represents an innovation.

[0019] Since all memory block requests of the algorithm are made to the memory base, it always "knows" which allocation profile the algorithm has. Using statistical and heuristic methods, it can optimize at execution time which memory blocks are best suited for which memory request. This incorporates information collected during the algorithm's previous execution. Specifically, this information includes the number of requested memory blocks of each size, as well as the frequency and distribution of memory blocks returned to the memory base. This information is used both to optimize current requests and to limit the size of the memory base in the event that the number of memory blocks in the memory base becomes too large due to unfavorable allocation sequences.

Claims

[1] Computer-implemented method for the efficient formulation and efficient execution of general numerical algorithms within a memory-managed environment, whereby separate methods of a memory management adapted to the numerical algorithms are implemented and used to provide and manage memory blocks, which, unlike those methods provided by the memory-managed environment, are geared to special requirements in the execution of numerical algorithms, and whereby various array classes are provided for the formulation of the numerical algorithms, which are automatically selected depending on the intended lifetime of an array. [2] Method according to claim 1, wherein the memory management adapted to the numerical algorithms does not immediately return used memory blocks to the memory-managed environment, but keeps them in a memory base for repeated use. [3] The method of claim 2, wherein the memory base implements a set of rules that automatically optimizes the use and reuse of memory blocks at execution time. [4] Method according to claim 3, wherein the size of memory blocks is not determined solely by the memory requirement of a numerical operation, but this requirement only determines the minimum size of a memory block, but the actual size is determined by the memory management adapted to the numerical algorithms. [5] A method according to any preceding claim, wherein array classes are provided for temporary arrays and for permanent arrays. [6] Method according to claim 2 and claim 5, wherein all temporary arrays are released after the first use by the memory management adapted to the numerical algorithms and the memory block associated with the respective array is immediately transferred to the memory base. [7] Method according to one of claims 1 to 5, wherein an algorithm consists of elementary arithmetic operations on the arrays of the method as well as from 0 to a finite number of other algorithms and the memory blocks required to execute an algorithm are released into the memory base for reuse immediately after their use, but at the latest at the end of an algorithm. [8] A method according to any one of claims 1 to 5, wherein the memory blocks associated with an array as a result of an algorithm are generally returned to the memory base after the first use of the array. [9] A method according to claim 8, wherein the use is passing the array to other algorithms, using array instance methods, or transforming an array into a persistent array. [10] Method according to one of the preceding claims, wherein the methods are adapted to meet specific requirements for the execution of numerical algorithms involving large, short-lived memory blocks.