Estimating progress of a computer program execution

Abstract

The invention relates to a computer-implemented method (900) of estimating progress of an execution of a computer program. The program is executed while evolving an execution counter, indicative of a current control flow position of the computer program. The execution counter can for example be a program counter used to exchange messages in a system for cryptographic secure multi-party computation. The execution counter has an execution-independent part that corresponds to the control flow position regardless of the current execution. To estimate progress, the execution-independent part is mapped to an estimate accessed from a predetermined, e.g., pre-calibrated, progress estimation mapping.

Description

[0001] ESTIMATING PROGRESS OF A COMPUTER PROGRAM EXECUTION

[0002] FIELD OF THE INVENTION

[0003] The invention relates to a computer-implemented method of estimating progress of an execution of a computer program, and to a corresponding device. The invention further relates to a computer-implemented calibration method, and to a corresponding device. The invention further relates to a computer-readable medium.

[0004] BACKGROUND OF THE INVENTION

[0005] There is a growing demand for privacy enhancing technologies (PETs), i.e. , data processing techniques that intrinsically protect the privacy of the data they operate on. For example, with the cryptographic technique of secure multi-party computation (MPC), multiple parties can perform a computation on their joint input using a distributed cryptographic protocol, such that each party learns nothing beyond the output of computation and his own (private) input.

[0006] One reason for the growing demand for PETs is that citizens are becoming increasingly dependent on the digital information stored about them by various companies and institutions. Because of this increasing dependence, the consequences of a breach of personal data are getting increasingly severe. And due to the worldwide surge of cybercrime and nation-state-sponsored cyber espionage, the risk of a data breach has increased sharply in recent years. Also, data-based collaborations between separate entities (like companies, hospitals, local governments) usually implies that personal data is copied between the entities, which poses the risk of uncontrolled spreading of data, in particular personal information. PETs can enable data collaboration between entities without the need for sharing the data in clear-text form. Another factor driving demand for PETs is the emergence of legal frameworks for data protection, such as the European GDPR and the Californian CCPA legislation, and their mandatory compliance. In the context of such frameworks, PETs are valuable as technical safeguards, and typically provide concrete instantiations of abstract legal notions.

[0007] In particular, one technique to perform a privacy-preserving computation on secret data is cryptographic secure multi-party computation (MPC). MPC is a cryptographic technique in which a computation is performed in a distributed way between multiple cryptographic devices in such a way that the inputs, intermediate values, and / or outputs of the computation remain hidden from the parties performing the computation. Such values that remain hidden from the parties may be referred to as the secret values of the MPC. In general, a secret value of the MPC may have the property that a limited number of parties, up to a given threshold, does not know the secret value. However, a number of parties that exceeds the threshold may be able to derive the secret value.

[0008] A multi-party computation is performed as a distributed computation among the different devices. Throughout the distributed computation, the devices exchange messages with each other. Since a receiving device needs to wait until the sender has sent the message, and can only then proceed to process the received message, such message exchange implies that the distributed computation is synchronised among the different devices. For example, a cryptographic protocol performed as part of the multi-party computation may be performed in multiple rounds, wherein in one round, for example, one of the devices may send a message that may be received by all of the other devices; all devices may send messages to all other devices; or similar

[0009] In many cases, the communication pattern between the different devices performing the multi-party computation is not linear, e.g., multiple sub-protocols and / or multiple high-level operations, such as table joins and / or model inferences, may be performed concurrently and independently from each other. In such a case, in order to dispatch an incoming message to the right operation, e.g., the sub-protocol or high-level operation that is waiting for the message, such a message may be identified by an execution counter that indicates the current step in the cryptographic protocol. This approach is taken for example in the MPyC software package for multi-party computation, where this identifier is referred to as the "program counter".

[0010] Performing a computation as a multi-party computation takes a significant amount of overhead compared to performing the computation in the plain at a single device. Therefore it would be desirable to provide progress estimates while the multi-party is running. For example, MPyC provides a demo where the multi-party computation involves performing the same operation for a total number of time steps. After a time step, a progress estimate is computed by dividing the number of performed steps by the total number of steps. The same principle of computing a progress estimate based on a current number of steps and a total number of steps is used in various available Python libraries for estimating progress, such as "progress", "progressbar2", "alive-progress", and "tqdm".

[0011] SUMMARY OF THE INVENTION

[0012] It would be desirable to estimate progress of an execution of a computer program, for example a computer program for performing a cryptographic secure multi-party computation, that can provide progress estimates that are accurate, work for computer programs with various control flows, and / or can provide with little or no modification of the computer program whose progress is being estimated.

[0013] In accordance with a first aspect of the invention, a computer-implemented method of estimating progress of an execution of a computer program is provided, as defined by claim 1. In accordance with a further aspect of the invention, a computer- implemented method of calibrating a progress estimation mapping is provided, as defined by claim 11. In accordance with further aspects, devices and a computer-readable medium are provided corresponding to the above methods, as defined by claims 13, 14, and 15.

[0014] Various aspects relate to the estimation of progress of an execution of a computer program. Such an estimation may comprise determining a progress estimate for the execution of the computer program, and outputting the progress estimate. For example, the progress estimate may be output by displaying a progress bar at a user interface; or by making the progress estimate available via an API such as a web API. The progress estimate can for example be determined upon request, e.g., one or more progress estimates may be determined via respective API calls; the progress estimate can be determined at regular time intervals; and / or the progress estimate can be determined as triggered by the computer program being executed, e.g., by an update of an execution counter.

[0015] As the inventors realized, the traditional technique of computing a progress estimate by, in a loop, dividing a current number of steps by a total number of steps, in many cases has several disadvantages. Such an approach may be relatively easy to incorporate in programs whose control flow at the highest level is a loop, and may provide accurate estimates in such a case, but unfortunately, many computer programs do not have such a control flow. For example, a computer program may comprise performing multiple sub-steps, where the multiple sub-steps typically do not take the same amount of time as each other, even approximately. In such a case, dividing the current number of steps by the total number of steps does may not provide an accurate approximation. Moreover, if the steps are implemented in the computer program not by looping over the same set of computer instructions but by executing respective sets of instructions, then these respective sets of instructions may need to be modified to enable progress estimation.

[0016] Interestingly, instead of keeping track of loop indices and computing a progress estimate based on that, the inventors envisaged to determine progress estimates based on evolving an execution-independent part of an execution counter, and mapping this execution-independent part of the execution counter to a progress estimate according to a predetermined mapping.

[0017] In general, the execution counter may be indicative of a current control flow position of the computer program, and the execution-independent part of the execution counter may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same. Such an execution counter with an execution-independent part can in general be implemented in various ways.

[0018] For example, the execution counter can be determined by introspection of the execution counter, e.g., by obtaining a stack trace of the execution of the computer program. As is known per se, computer programs using various programming languages, including C++ and Python, may allow such a stack trace to be determined by introspection, either from the computer program by itself, or from an external computer program. From the stack trace, an execution-independent part may be derived, e.g. by removing information that is specific to a particular execution, such as values for arguments to a function being called, or memory addresses, or parts of the stack trace not part of the computer program whose progress is being estimated. For example, the execution-independent part may comprise a list of respective recursive function calls, identifying at which point in a respective function, a respective sub-function was called. Interestingly, when using introspection, the computer program itself may remain unmodified, and accordingly progress estimation may be added to a computer program with little effort, or progress estimation may even be added to an already existing computer program.

[0019] As another example, the execution counter may be based on an execution counter that is used to identify messages in a distributed computation, such as a secure multi-party computation protocol. As also discussed elsewhere, in a distributed computation where multiple concurrent messages may be sent and received, an identifier may be used such that a receiver can dispatch a received message to the part of the computer program that is waiting for it. Such an identifier may accordingly indicate the current control flow position of the computer program in terms of the position in the distributed computation. An example of such an identifier is the program counter used in MPyC, for example. Such an identifier may for example be extended to comprise an execution-independent part, as discussed in detail elsewhere in this specification. Also in this case, by using existing functionality already used to evolve the message identifiers, progress estimation may be added to a computer program for a distributed computation with little effort.

[0020] However, it is not needed to use introspection or existing message identifiers. For example, it is also possible to manually implement an evolution of an execution counter to a computer program, e.g., respective instructions to evolve the execution counter may be included in a computer program at respective places where an updated progress estimate is desired. In such cases, the execution counter can for example not contain an executiondependent part and can thus consist only of the execution-independent part. Regardless of how the execution counter and its execution-independent part are determined, the inventors made an interesting realization. Namely, the inventors observed that, in many cases, in different executions of a computer program, the execution counter evolves in largely the same way. For example, a computer program may call a first, a second, and a third subroutine, and accordingly, in different executions of the computer program, the execution-independent part of the execution counter may, at a point, evolve to a value corresponding to the beginning of the first subroutine; to a value corresponding to the beginning of the second subroutine; and to a value corresponding to the beginning of the third subroutine. Accordingly, the inventors realized that, by associating a certain progress estimate to the reaching of a certain value for the execution-independent part of the execution counter, a particularly convenient and accurate way of estimating progress may be obtained.

[0021] Namely, to provide progress estimates, a predetermined mapping of execution-independent parts to progress estimations may be used. For example, the mapping may indicate that, upon reaching the beginning of the first subroutine, progress is at 20%; upon reaching the beginning of the second subroutine, progress is at 55%; and upon reaching the beginning of the third subroutine, progress is at 90%. The mapping may be predetermined in the sense that it is available before starting the execution of the computer program, e.g., as a file on disk. For example, the mapping may have been previously determined by a calibration wherein the progress estimates are determined based on measurements, as also discussed elsewhere. Accordingly, the mapping may not be evaluated dynamically by dividing a current iteration by a number of iterations, for example; preferably, the mapping is also not hard-coded into the computer program itself, or at least is not incorporated in the source code of the computer program; for example, the mapping may be loaded from an external file.

[0022] The inventors found that the provided way of estimating process has several advantages. The inventors found that accurate progress estimates can be obtained for a wide range of possible control flows, e.g., involving function calls to subroutine(s), and / or including recursive calls, and / or where different subroutines do not all take the same amount of time. Even though it is possible that different executions of a computer program do not follow exactly the same control flow, e.g., may perform a loop for a different number of times depending on an input, or visit an "if" or an "else" depending on an input, still, the parts of the control flow that are the same, and thus lead to the same value of the executionindependent part of the execution counter, in many cases provide sufficient, and sufficiently accurate, updates to the progress estimate. Interestingly, moreover, by using a mapping of execution counters to progress estimates, the estimates may be obtained with little or no modification of the computer program whose progress is being estimated. For example, when using introspection or when basing the progress estimation on an execution counter that is already being evolved by the computer program, such as in the context of distributed computations, progress estimation may be added with no or little effort, and may even be added to existing programs. But also manually adding an execution counter to a computer program that didn't previously have one, may need relatively little effort, e.g., it may suffice to add a counter and increment and / or fork it, as discussed in more detail herein, without explicitly specifying a number of stages and / or a weight assigned to respective stages, etc, inside the computer program.

[0023] Moreover, the use of a mapping makes it possible to determine and / or update the mapping separately from the computer program. In particular, the mapping can be calibrated by measurements, and if needed, the calibration can be performed again when the computer program is run in a different environment, e.g., with different performance characteristics such as memory or hard disk size, or network latency. The progress reporting can be configured to use the same computer program but an updated mapping. For example, the mapping can be read from an external file or database.

[0024] Optionally, the computer program may be for performing a distributed computation with at least a further device. In such a distributed computation, a device may be configured to exchange one or more messages with one or more further devices. Multiple programs, and / or multiple subroutines of a program, may be performed concurrently. In such cases, it is known per se to evolve an execution counter, and to identify exchanged messages based on the execution counter to dispatch received messages e.g. to the right program and / or the right subroutine that is expecting the message. For example, the execution counter may be evolved, e.g., incremented, upon sending and / or receiving the message, e.g., the execution counter may indicate a round of a distributed communication protocol. An example of such an execution counter is the program counter used in the MPyC software package for performing multi-party computation.

[0025] Interestingly, by basing the provided techniques on an existing execution counter and its existing evolution mechanism, progress estimation may be added to a program that already uses an execution counter, with little additional effort.

[0026] In particular, the provided progress estimation techniques may be applied to determine respective progress estimates for respective concurrent executions of the computer program. In such a case, the execution counter as a whole may be executiondependent, such that messages can be dispatched to the right instance. In particular, the execution counter may comprise an execution-dependent part such that, for different executions of the computer program that are in the same current control flow position, the execution-dependent part is different.

[0027] Interestingly, an execution-independent part may be included in such an execution counter to enable progress estimation using a progress estimation mapping. For example, the execution-dependent part may be determined by evolving this part from different starting values in different executions. An execution-independent part may be implemented by using the same evolution mechanism, but with the same starting value of this execution-independent part for different executions of the same computer program. The starting value may however depend on which computer program, and optionally which variant of the computer program, is being executed. By using the same evolution mechanism, e.g., by evolving the execution-independent part in a subroutine that is already called to evolve the execution-dependent part, progress estimation may be implemented with little effort.

[0028] Optionally, the computer program being executed, may be for performing a cryptographic secure multi-party computation protocol. As discussed in more detail elsewhere, this is a distributed execution of a cryptographic protocol to allow privacypreserving computation on sensitive data. The provided techniques are particularly advantageous in this setting for several reasons. First, multi-party computation protocols for high-level operations, such as a model inference or a table join, typically follow a relatively complex control flow, with many different subroutines at different levels of recursion, making it hard to produce good progress estimates manually. This makes it particularly advantageous to allow to produce estimates automatically, e.g., by calibration.

[0029] Second, the performance of multi-party computation protocols, and in particular the relative performance of different sub-steps, can differ greatly depending on the available bandwidth, network latency, and CPU, and their relative differences. This makes it beneficial to be able to calibrate the performance estimates, in particular for different settings. A final and important advantage is that multi-party computation protocols, by nature, perform little input-dependent branching, since branching on secret inputs is generally avoided in such protocols to protect the inputs; and accordingly, there is a great correspondence in control flow between different program executions, leading to particularly accurate progress estimates.

[0030] Optionally, the execution of the computer program may involve the execution of a subroutine. In such a case, the evolution of the execution counter may be implemented by performing a fork of the execution counter. Based on the execution counter, a forked execution counter and an evolved execution counter may be determined. While executing the subroutine, the forked execution counter may be evolved. While executing the remainder of the computer program after the subroutine, the evolved execution counter may be evolved. The forked and evolved execution counter may be determined such that their evolutions are independent from each other, e.g., such that the evolved counters do not, or are very unlikely to, clash.

[0031] Performing a fork is advantageous because it helps to keep evolutions of the execution counter similar across executions. For example, if the subroutine increments the forked execution counter for a different amount of times, for example, based on an input to the computer program, this may lead to execution-independent parts that are no longer included in the progress estimation mapping, e.g., because they did not occur during calibration, and for which thus no progress estimates may be available. However, these differences may then not affect the remainder of the program, if the remainder uses an evolved execution counter independent of the forked execution counter.

[0032] In the setting of distributed systems, performing a fork is also advantageous since it allows to execute subroutines in the background while keeping execution counters between different participants of the distributed system in sync, as done e.g. in MPyC.

[0033] Execution counter forking may also be used in other situations. For example, for a conditional statement, an if branch and an else branch may be performed using different forked execution counters, with instructions after the conditional using an evolved execution counter, or similar. Also in such a case, keeping the evolutions in the if, else, and remainder independent from each other may keep execution counter evolutions similar across executions and may on the other hand avoid clashes between independent parts corresponding to different control flow positions.

[0034] Optionally, forking the execution counter may trigger the determination of an updates progress estimate for the computer program execution, e.g., by looking up in the progress estimation mapping the execution-independent part of the execution counter prior to the fork.

[0035] Optionally, the execution of the computer program may comprise performing a given number of iterations of a loop, for example, in a sequential way. The number of iterations may differ between executions, e.g., may depend on the input of the computer program. In such a case, to provide accurate progress estimations despite this difference in control flow evolution, interestingly, the progress estimation may be applied recursively to the loop. Namely, iterations of the loop may be performed by evolving an iteration execution counter, wherein the execution-independent part of the iteration execution counter is determined such that, for different iterations that are in the same current control flow position within the iteration, the execution-independent part is the same. For example, the execution- independent part of the iteration execution counter may be configured to evolve from the same value for different iterations of the loop. Based on the iteration execution counter, an iteration progress estimate for the iteration of the loop may be determined, and a progress estimate for the execution of the program may be determined based on the iteration progress estimate. To allow the overall performance estimate to be determined, the progress estimation may use the given number of iterations. This information can be obtained, for example, by having the computer program call a function to add the number of iterations to the execution counter, or by letting the progress estimation extract the number of iterations from the program execution by introspection.

[0036] In particular, to determine the overall progress estimate, a begin progress estimate and an end progress estimate for the loop may be obtained based on the execution counter, and the progress estimate may be determined based on the begin progress estimate, the end progress estimate, the given number of iterations, the number of completed iterations, and the iteration progress estimate, e.g., by linear interpolation. Such an interpolation may effectively compute the progress estimate based on the assumption that the loop takes up a fixed proportion of the enclosing program regardless of the number of iterations. The inventors found that progress estimates determined in this way are for many computer programs in practice accurate, even when input parameters differ greatly between calibration and execution.

[0037] Optionally, executing the computer program may comprise performing a given number of iterations of a loop at least in part concurrently. For example, the computer program may be configured to perform at most a given number of iterations concurrently. In such a case, as in the case of a sequential loop, a progress estimate of an iteration may be determined based on an iteration execution counter, and an overall progress estimate may be determined based on the iteration progress estimate. Interestingly, in such a case, if there is a further iteration that is performed at least in part concurrently with the first iteration, then the progress estimate for that further iteration may not be determined, or at least may not be used for the overall progress update. For example, an iteration may be configured to determine whether another respective iteration of the loop is currently evolving a respective iteration execution counter; and to evolve an iteration execution counter for the iteration and determine an iteration progress estimate based on the iteration execution counter only if this is not the case. More generally, progress estimation may be performed based on progress estimates of at most one active iteration of the loop. For example, the progress estimate may use the total number of iterations, the number of completed iterations, and the iteration progress estimate. This way, an overall progress estimate can be determined relatively efficiently without tracking and combining progress estimates of multiple iterations that are performed at the same time, while still providing an accurate overall performance estimate.

[0038] However, it is also possible to determine an overall progress estimate for multiple concurrent operations by evolving respective operation execution counters; using these to determine respective operation progress estimates; and determining an overall progress estimate based on the respective operation progress estimates. This applies to the case where the operations are respective loop iterations, or respective subroutines, for example. While more complex than only determining progress estimates for one concurrent operation at a time, as described above, this approach has the advantage that it can provide more accurate estimates, especially if the respective operations take up different amounts of time. In particular, the overall progress estimate may be determined as a weighted combination, e.g., a weighted sum, of operation progress estimates, with weights representing relative costs, e.g., in terms of running time, of the respective operations. Such a relative cost may be determined as part of a calibration as also discussed elsewhere in this specification.

[0039] Optionally, the determined progress estimate may represent a completed proportion of the execution of the computer program, e.g., represented as a percentage, as a value between zero and one, or the like. Indeed, as the inventors realized, in general, a certain control flow position in an execution of a computer program may be assumed to generally correspond to a certain proportion of the execution of the computer program being finished. Thus, a progress estimation mapping as described herein may be used to accurately estimate such a proportion.

[0040] Optionally, the progress data that is used to determine the progress estimate, may have been obtained by calibrating the progress estimation mapping with respect to a measured use of a resource, as also discussed elsewhere in this specification. This provides an automated way of determining a mapping that provides accurate progress estimates.

[0041] Various aspects relate to the calibration of a progress estimation mapping. Such a progress estimation mapping may be used to estimate the progress of an execution of a computer program as described herein.

[0042] To perform the calibration, the computer program may be executed as described herein. In particular, an execution counter may be evolved. The execution counter may be indicative of a current control flow position of the computer program, and may comprise an execution-independent part determined such that, for different executions of the computer program that are in the same current control flow position, the executionindependent part is the same. Interestingly, to perform the calibration, further, a current cumulative use of a resource may be measured. In particular, during the calibration, a current executionindependent part of an execution counter may be associated with a current measurement of the cumulative use of the resource. The progress estimation mapping may map a respective execution independent part to a respective progress estimate, and may be determined by comparing the measured current cumulative use of the resource to an overall use of the resource, e.g., the cumulative use measured after the computer program has finished. In general, various resources may be measured, including but not limited to: time, such as wall clock time or CPU time; network traffic, such as incoming and / or outgoing numbers of messages or bytes; CPU usage; or the like. Interestingly, by basing a progress mapping on measurements, it is possible to obtain an accurate progress mapping in an automated way. As the inventors have found, in practice, even if inputs of the computer program are different between calibration and use of the progress mapping, still, in many cases, accurate progress estimates can be obtained.

[0043] Optionally, a progress estimation mapping may include entries corresponding to different computer programs and / or different variants of the same computer program. For example, during calibration, progress estimation mappings of different programs and / or variants may be determined, and optionally combined into a single progress estimation mapping. In the latter case, during calibration and execution, for different programs or variants, the execution-independent part of the execution counter is preferably evolved from a different initial value. This way, it can be achieved that values for the executionindependent part of different variants or programs do not clash. For example, the executionindependent part may be set to a hash, e.g., a cryptographic hash, of an index corresponding to the program or variant, thereby making clashes unlikely.

[0044] It will be appreciated by those skilled in the art that two or more of the above- mentioned embodiments, implementations, and / or optional aspects of the invention may be combined in any way deemed useful. Modifications and variations of any device, system, and / or computer readable medium, which correspond to the described modifications and variations of a corresponding computer-implemented method, can be carried out by a person skilled in the art on the basis of the present description; also the other way round.

[0045] BRIEF DESCRIPTION OF THE DRAWINGS

[0046] These and other aspects of the invention will be apparent from and elucidated further with reference to the embodiments described by way of example in the following description and with reference to the accompanying drawings, in which:

[0047] Fig. 1 shows a device for calibrating a progress estimation mapping; Fig. 2 shows a device for estimating progress;

[0048] Fig. 3 shows a cryptographic system;

[0049] Fig. 4a shows a detailed example of evolving an execution counter;

[0050] Fig. 4b shows a detailed example of evolving an execution counter;

[0051] Fig. 4c shows a detailed example of determining a progress estimate;

[0052] Fig. 5 shows a detailed example of performing a synchronised operation;

[0053] Fig. 6a shows a detailed example of evolving an execution counter;

[0054] Fig. 6b shows a detailed example of determining a progress estimate;

[0055] Fig. 7 shows a detailed example of performing iterations concurrently;

[0056] Fig. 8 shows a detailed example of calibrating a progress calibration mapping;

[0057] Fig. 9 shows a computer-implemented method;

[0058] Fig. 10 shows a computer-implemented method;

[0059] Fig. 11 shows a computer-readable medium comprising data.

[0060] It should be noted that the figures are purely diagrammatic and not drawn to scale. In the figures, elements which correspond to elements already described may have the same reference numerals.

[0061] DETAILED DESCRIPTION OF EMBODIMENTS

[0062] Fig. 1 shows a device 100 for calibrating a progress estimation mapping. The progress estimation mapping may be for use in a computer-implemented method and / or by a device as described herein, e.g., device 200 of Fig. 2. In particular, the device 100 may be a cryptographic device that is configured to, with one or more further devices, perform a cryptographic secure multi-party computation protocol.

[0063] The device 100 may comprise a data interface 120 for accessing respective progress data 030 representing respective entries of a progress estimation mapping. By way of illustration, the figure shows two entries; more generally, the number of entries may be at most or at least 10; at most or at least 100; or at most or at least 1000.

[0064] For example, as also illustrated in Fig. 1, the input interface may be constituted by a data storage interface 120 which may access the data 030 from a data storage 021. For example, the data storage interface 120 may be a memory interface or a persistent storage interface, e.g., a hard disk or an SSD interface, but also a personal, local or wide area network interface such as a Bluetooth, ZigBee or Wi-Fi interface or an ethernet or fibreoptic interface. The data storage 021 may be an internal data storage of the device 100, such as a hard drive or SSD, but also an external data storage, e.g., a network- accessible data storage. In some embodiments, respective data may each be accessed from or distributed across different data storages, e.g., via a different subsystem of the data storage interface 120. Each subsystem may be of a type as is described above for data storage interface 120.

[0065] A respective entry 030 may map an execution-independent part of a respective execution counter to a respective progress estimate. An execution counter may be indicative of a control flow position of a computer program. The execution-independent part of the execution counter may be determined such that, for different executions of the computer program that are in the same current control flow position, the executionindependent part is the same. The respective progress estimate may be indicative of a progress in the execution corresponding to the control flow position indicated by the execution counter.

[0066] The device 100 may further comprise a processor subsystem 140. The processor subsystem 140 may be configured to, during operation of the device 100, execute the computer program. Executing the computer program may comprise evolving the execution counter, e.g., by keeping track of the execution within the computer program or by executing the program and determining the execution counter from outside of the computer program by introspection. Executing the computer program may further comprise measuring a current cumulative use of a resource, e.g., wall clock time or CPU usage spent by the processor subsystem 140 on executing the computer program. The measuring may be performed by a measuring subsystem of the device 100, for example, a real-time clock, and / or by the processor subsystem 140 itself. The processor subsystem 140 may be further configured to, during operation of the device 100, determine a progress estimation mapping. The progress estimation mapping may map a respective execution independent part to a respective progress estimate. The respective progress estimate may be determined by comparing the current cumulative use of the resource to an overall use of the resource.

[0067] The device 100 may also comprise a communication interface 180. For example, the computer program may be for performing a distributed computation with at least a further device. In such a case, the communication interface 180 may be configured for communication 126 with the at least one further device, for example, a further cryptographic device that is configured to, with device 100, perform a cryptographic secure multi-party computation protocol. Communication interface 180 may internally communicate with processor subsystem 140 via data communication 125. Communication interface 180 may be arranged for direct communication with the other devices, e.g., using USB, IEEE 1394, or similar interfaces. As illustrated in the figure, communication interface 180 may also communicate over a computer network 099, for example, a wireless personal area network, an internet, an intranet, a LAN, a WLAN, etc. For instance, communication interface 180 may comprise a connector, e.g., a wireless connector, an Ethernet connector, a Wi-Fi, 4G or 4G antenna, a ZigBee chip, etc., as appropriate for the computer network. Communication interface 180 may be an internal communication interface, e.g., a bus, an API, a storage interface, etc.

[0068] Fig. 2 shows a device 200 for estimating progress of an execution of a computer program. In particular, the device 200 may be a cryptographic device that is configured to, with one or more further devices, perform a cryptographic secure multi-party computation protocol. Device 200 may use a progress estimation mapping to estimate the progress. The progress estimation mapping may have been previously determined as described herein, e.g., by device 100 of Fig. 1.

[0069] In general, the device 200 may be as described for device 100 of Fig. 1. In particular, device 200 may comprise a data interface 220, a processor subsystem 240, and / or a communication interface 280, for which the same options are available as discussed for device 100 of Fig. 1. It is also possible to combine devices 100 and 200 in a single device that is configured to, e.g., first determine a progress mapping for a computer program and then estimate progress of an execution of the computer program using the determined progress mapping.

[0070] In particular, the cryptographic device 200 may comprise a data interface 220. The data interface can be for accessing respective progress data 030 representing respective entries of a predetermined progress estimation mapping. The progress data 030 may be as discussed for Fig. 1. A respective entry may map an execution-independent part of a respective execution counter to a respective progress estimate. An execution counter may be indicative of a control flow position of the computer program. The executionindependent part of the execution counter may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same. The respective progress estimate may be indicative of a progress in the execution corresponding to the control flow position indicated by the execution counter. The mapping 030 may be available via a single data interface 220. The mapping 030 may be available before executing the computer program, and may remain unchanged throughout the execution. Respective entries may be stored by storing respective estimates, e.g., an estimate may be accessed as a stored value instead of being defined by a formula.

[0071] The device 200 may further comprise a processor subsystem 240. The processor subsystem 240 may be configured to, during operation of the device 200, execute the computer program. The execution of the computer program may comprise evolving the execution counter, as also discussed with respect to Fig. 1 and elsewhere in this specification. The processor subsystem 240 may be further configured to, during operation of the device 200, determine a progress estimate for the execution of the computer program according to the execution-independent part of the execution counter and according to the progress estimation mapping.

[0072] The device 200 may comprise an output interface (not shown) for outputting the progress estimate. For example, the output interface may be an interface to a rendering device, such as a display, a light source, a loudspeaker, a vibration motor, etc., which may be used to generate a sensory perceptible output signal which may be generated based on the progress estimate, for example, a progress bar shown on a screen, and / or a sound signal that can for example have a pitch dependent on the progress estimate, and / or a signal representing an estimated time remaining. The output interface can also be formed by a communication interface, e.g., to make the progress estimate available via an API.

[0073] In general, each device described in this specification, including but not limited to the device 100 of Fig. 1 and the device 200 of Fig. 2, may be embodied as, or in, a single device or apparatus, such as a workstation or a server. The device may be an embedded device. The device or apparatus may comprise one or more microprocessors which execute appropriate software. For example, the processor subsystem of the respective device may be embodied by a single Central Processing Unit (CPU), but also by a combination or system of such CPUs and / or other types of processing units. The software may have been downloaded and / or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash. Alternatively, the processor subsystem of the respective system may be implemented in the device or apparatus in the form of programmable logic, e.g., as a Field-Programmable Gate Array (FPGA). In general, each functional unit of the respective system may be implemented in the form of a circuit. The respective system may also be implemented in a distributed manner, e.g., involving different devices or apparatuses, such as distributed local or cloud-based servers.

[0074] Fig. 3 shows a cryptographic system 010 for performing a privacy-preserving computation as a cryptographic secure multi-party computation. The cryptographic system 010 may in general comprise multiple input devices, multiple different cryptographic devices, and at least one result device, where the sets of input, cryptographic, and result devices may overlap with each other. As illustrated, the devices typically communicate over a computer network 099, e.g., the internet or a local network. The input and result devices may also be considered not to be part of, but merely interacting with, the cryptographic system 010. For example, the inventors envisage a cryptographic system 010 in which at least one of the cryptographic devices, e.g., all devices, is / are a device for calibrating a progress estimation and / or a device for estimating progress, as discussed with respect to Fig. 1 and Fig. 2.

[0075] In particular, shown in the figure are three cryptographic devices CP1 , 221 ; CP2, 222; and CP3, 223. The cryptographic devices may be based on device 100 of Fig. 1 or device 200 of Fig. 2. Generally, the number of cryptographic devices that is used can vary depending on the particular technique used for the multi-party computation and the security properties which are desired. For example, the number of cryptographic devices CPi can be two, three, or more. Although the cryptographic devices of the cryptographic system are typically distinct devices, e.g., operated by different organizational entities, it is also possible to combine the different cryptographic devices into a single device, for example, for performing the multi-party computation as a so-called MPC-in-the-Head.

[0076] The cryptographic devices CPi may be configured to perform a secure multiparty computation (also known per se as multi-party computation, secure computation, or MPC). Generally, a multi-party computation may be a distributed protocol between the cryptographic devices for performing a computation in a privacy-preserving way. Depending on the specific technique used, MPC may ensure privacy and / or correctness of the computation against an attacker that eavesdrops or controls one or more (but typically not all) of the cryptographic devices. As known per se, any computation can be performed as a multi-party computation (in other words, “under the multi-party computation”), but concrete computational and communication efficiency can in general greatly depend on how exactly the computation is performed.

[0077] In particular, the multi-party computation can be performed based on secret sharing, in particular arithmetic secret sharing such as Shamir secret sharing, replicated secret sharing, or additive secret sharing. In arithmetic secret sharing, the shared values may be numbers defined modulo a certain modulus, e.g., a prime modulus. The modulus may have a bit length of at least 20 bits, at least 30 bits, or at least 60 bits.

[0078] In particular, the arithmetic secret sharing may be a multiplicative secret sharing, such as Shamir secret-sharing or replicated secret sharing. As is known per se, multiplicative secret sharing generally admits efficiently performing additions and multiplications under multi-party computation, as well as efficient conversion to additive secret sharing, e.g., see, R. Cramer et a / ., "General Secure Multi-Party Computation from any Linear Secret-Sharing Scheme", proceedings EUROCRYPT 2000.

[0079] For example, the multi-party computation can be based on the techniques described in Shamir, “How to Share a Secret”, Communications ACM, 1979; Ben-Or, Goldwasser, Wigderson, “Completeness Theorems for Non-Cryptographic Fault-Tolerant Distributed Computation (Extended Abstract)”, Proceedings of the 20th Annual ACM Symposium on Theory of Computing, 1988; Chaum, Crepeau, Damgaard, “Multiparty Unconditionally Secure Protocols (Extended Abstract)”, Proceedings of the 20th Annual ACM Symposium on Theory of Computing, 1988; Ito, Saito, Nishizeki, “Secret sharing scheme realizing general access structure”, Electronics and Communications in Japan (Part III: Fundamental Electronic Science), 1989; Damgaard, Pastro, Smart, Zakarias, “Multiparty Computation from Somewhat Homomorphic Encryption”, proceedings CRYPTO 2012.

[0080] Various higher-level operations such as sorting and integer comparison can be performed based on such basic multi-party computation protocols as discussed e.g. in M. Keller, "MP-SPDZ: A Versatile Framework for Multi-Party Computation", proceedings ACM CCS 2020; or as implemented in MPyC, see https: / / github.com / lschoe / mpyc.

[0081] A multi-party computation protocol may be performed as a synchronized operation between the cryptographic devices CPi, e.g., various sub-operations may be performed in the form of sub-protocols that are performed in one or more rounds, wherein, in a round, one or more sending devices CPi send respective messages to one or more receiving devices CPi. As is known per se, for example in MPyC, a message may be identified based on an execution counter that, e.g., may be indicative of the round within the sub-protocol. To indicate the round, the execution counter may be evolved upon sending and / or receiving the message. Execution counters as known per se are typically also indicative of the particular instance of the sub-protocol being executed. For example, respective execution counters for different instances may be evolved from respective starting execution counters that are different for the different instances. It is noted that such an execution counter, e.g., as used by MPyC, typically does not comprise an executionindependent part, although it can be modified to do so, as discussed in more detail elsewhere in this specification.

[0082] The multi-party computation may be configured to perform operations on so called sharings, or secret shares, of values. A secret share may be a distributed representation of an input, intermediate, or output value of the MPC. A limited number of shares, up to a certain threshold t, may not allow to derive the represented value. The threshold may be configurable, with different techniques supporting different possible threshold. In particular, the multi-party computation may be an honest majority MPC, where the threshold t is strictly smaller than half the number of parties n, e.g., 1 / 2 (n - 1). Examples of sharings are multiplicative secret sharing schemes, such as Shamir secret sharing or replicated secret sharing. Specifically, the provided techniques may be combined with a multi-party computation protocol with threshold 1, in view of the use of additive shares of a first and second cryptographic device. For example, the multi-party computation may be a two-party protocol, e.g., based on additive secret sharing. Or, the multi-party computation may be a protocol based on a multiplicative secret sharing scheme such as replicated or Shamir secret sharing, e.g., with three parties. Use of multiplicative secret sharing is advantageous in view of the possibility to efficiently obtain additive secret shares of a secret input value shared according to the multiplicative secret sharing scheme.

[0083] A value that is computed on by the MPC but that is represented among the parties in such a way that no single party, more generally no unqualified set of parties, can derive the value from that representation, is referred to as a secret value, or private value, of the MPC. A secret value can be a secret sharing, but it is also possible in general e.g. to use a threshold encryption. For example, a secret value can be a secret input, a secret output, or a secret intermediate value. Here, a secret input may be known in the plain by the party inputting it, and known only in a secret representation by the cryptographic devices CPi; and similarly, a secret output may be learned in the plain by the party receiving it as output, but may be known only in a secret representation by the cryptographic devices CPi. A private intermediate value may be known only to the cryptographic devices CPi, and only as a secret representation. By processing values using secret representations, the data can be kept secret, at least as long as the underlying assumptions of the multi-party computations (e.g., a number and / or type of corruptions of the cryptographic devices) are satisfied.

[0084] Also shown in the figure are a number of input devices INP1 , 211; INP2, 212; up to INPk, 213. The input devices may input respective input data for the computation. The input devices 211-213 may use the hardware configuration discussed in Fig. 1. The number of input devices can be two, at most or at least three, or at most or at least five, for example. In many cases, the sets of inputs devices INPi and cryptographic devices CPi may wholly or partially overlap. For example, the set of input devices may be a subset or a superset of the set of cryptographic devices, or may be exactly the same.

[0085] Further shown is a result device RES, 230. The result device RES may obtain a result of the MPC based on the performed privacy-preserving computation. It is also possible for multiple respective result devices to obtain multiple respective results of the multi-party computation. Although illustrated as a separate device in the figure, the result device(s) RES can be the same devices as an input device INPi and / or cryptographic device CPi. Generally, the result device may be implemented using the hardware configuration discussed with respect to Fig. 1. Many known multi-party computation techniques are defined per se for the case where the input and result devices INPi and RES form a subset of the set of cryptographic devices CPi that perform the MPC. To use such techniques in a setting where an input and / or result device does not perform the MPC itself, an input device can for example determine a secret representation, e.g., a secret sharing, and distribute it among the computation devices. Similarly, a result device can for example receive a secret representation, e.g., respective secret shares, of an output from the computation devices and derive the output from the secret representation. It is also possible to use specific techniques for letting an external party provide inputs to and / or obtain outputs from a multiparty computation. For example, the techniques from the following reference can be used: T. P. Jakobsen, J. B. Nielsen, and C. Orlandi. “A framework for outsourcing of secure computation”, proceedings CCSW’14. It is noted that, apart from such inputs by external parties INPi, the cryptographic devices CMPi that perform the MPC themselves typically also provide inputs to the multi-party computation as part of performing various operations, e.g., by inputting representations of the first and second remainder as described herein.

[0086] Fig. 4a shows a detailed, yet non-limiting, example of evolving an execution counter as part of the execution of a computer program. In this example, the execution counter may be evolved by the computer program itself. For example, the computer program may keep track of the execution counter by means of a variable that is passed to functions whose control flow is tracked to provide process estimates. For example, the execution counter in this example may be based on a program counter as maintained, for example, by MPyC or similar.

[0087] In this example, the execution counter EC, 410, is evolved by means of an increment operation Inc, 420, into an evolved execution counter ECi, 430.

[0088] The increment operation Inc may be performed at a point where an updated progress estimate is desired. For example, the computer program being executed may comprise multiple stages, and the increment operation Inc may be performed between respective stages. As another example, the increment operation Inc may be performed upon sending and / or receiving a message as part of performing a synchronised operation with one or more devices, such as the execution of a cryptographic secure multi-party computation protocol. The latter case is advantageous since the increment operation has the double function of also enabling synchronized communication, and thus, progress estimation may be obtained with little modification of the computer program at hand. In any case, the execution counter may evolve throughout the execution of the computer program, and may thereby be indicative of a current control flow position of the computer program. The increment operation Inc may comprise or otherwise trigger the determination of a progress estimate, as discussed e.g., with respect to Fig. 4c.

[0089] As shown in the figure, the execution counter EC may comprise an executiondependent part EDP, 411. The execution-dependent part EDP may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-dependent part is different. In principle, the use of an executiondependent part EDP is not needed to determine progress estimates, or even to exchange messages, e.g., in settings where there are no multiple concurrent executions of the computer program.

[0090] Interestingly, the execution counter EC may further comprise an executionindependent part EIP, 412. The execution-independent part EIP may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same.

[0091] The increment operation Inc may be implemented in various ways. In some embodiments, the increment operation Inc may evolve the execution-independent part EIP and the execution-dependent part EDP independently from each other, to obtain an evolved execution-independent part ElPi, 432, and an evolved execution-dependent part EDPi, 431 , respectively. The operations to evolve the respective parts can be the same, or can differ from each other. For example, one or both parts can be implemented as an integer, for example, a 32-bit or 64-bit integer. The increment operation Inc may be implemented by increasing the value by one. However, various other options, such as a decrement, a multiplication, e.g., by an odd number, or an application of a hash function, are also possible. Preferably, the operation is such that applying the increment operation for a given number of N times, leads to N different values, e.g., where N is at least 100, at least 1000, or at least 10000. Clashes between the increment operation Inc and the fork operation as discussed with respect to Fig. 4b, are also preferably avoided, as discussed elsewhere.

[0092] Another possibility for the increment operation Inc is to evolve the executionindependent part EIP and leave the execution-dependent part EDP intact. For example, the execution-dependent part may be generated at the beginning of the execution of the computer program and may serve to distinguish execution counters from different executions of the same and / or different computer programs, whereas the executiondependent part EDP may be used to represent the control flow position within the computer program. The options for determining the evolved execution-independent part ElPi, as described above, also apply in this case. Fig. 4b shows a detailed, yet non-limiting, example of evolving an execution counter. This example is based on the execution counter EC, 410, of Fig. 4a, and also in this example the execution counter EC can comprise an optional execution-dependent part EDP, 411 , and an execution-independent part EIP, 412.

[0093] In this example, the execution counter may be evolved by means of a forking operation Fork, 450, into at least two execution counters ECi, 430, and ECF, 440. The forking operation may also be referred to as a hop of the execution counter.

[0094] Interestingly, the forking operation may be defined such that evolutions of the different execution counters ECi and ECF are unlikely to lead to the same execution counter. For example, the forking operation Fork may be defined such that, at least with high probability, incrementing execution counter ECi for a number of times N does not lead to execution counter ECF, and the other way round, where N is for example at least 100, at least 1000, or at least 10000. More generally, the forking operation Fork may be defined such that, for any two different sequences of forks and increments of length N starting from the same execution counter, the resulting execution counter may be different, at least with high probability.

[0095] One of the resulting execution counters ECi may be referred to as an evolved execution counter. Another resulting execution counter ECF may be referred to as a forked execution counter.

[0096] The forking operation can be implemented in various ways. For example, one of the resulting execution counters, for example the evolved execution counter, may be determined by incrementing the execution counter EC as discussed with respect to Fig. 4a. Another resulting execution counter, for example the forked execution counter, may be determined by applying a different update operation. For example, the forked executionindependent part EIPF and / or the forked execution-dependent part EDPF may be determined by applying the same or a different update operation to the respective parts of the execution counter EC. One example of such an update operation is computing a hash, e.g., a cryptographic hash or other collision-resistant hash, of the execution counter EC. Another example is where an increment is an addition-by-one and a fork is a shift by a given number of bits. As another example, an execution-dependent part or execution-independent part may be represented by a list, where incrementing is implemented by incrementing the final element and forking is implemented by appending an element to the list, or similar, e.g., by incrementing the first element and pre-pending. As discussed with respect to Fig. 4a, the execution-dependent part can for example be left unchanged while only updating the execution-independent part, or both can be updated. The forked and evolved execution counter can be used to evolve the execution counter while executing a subroutine. For example, the subroutine may be executed while evolving the forked execution counter ECF. The remainder of the computer program following the execution of the subroutine, may be executed while evolving the evolved execution counter ECi. This is advantageous over performing the remainder of the program with the execution counter evolved from the subroutine. First, it allows the subroutine to be performed at least in parallel with the remainder of the computer program. Second, it implies that, since the evolution of the evolved execution counter ECi is independent from the subroutine, variations in control flow in the subroutine do not affect the evolved execution counter. For example, if the subroutine increments its execution counter for a variable amount of times, this may lead to less accurate progress estimates for the subroutine due to the progress mapping described herein not being representative for all executions; but this decreased accuracy may then be limited to the subroutine because of the use of the forked execution counter ECF.

[0097] Similarly to Fig. 4a, the fork operation Fork may trigger the determination of an updated progress estimate, e.g., as discussed with respect to Fig. 4c. The updated estimate can e.g. be based on the execution counter EC or one of its updates ECi, ECF, 440.

[0098] In some embodiments, the execution counter may be evolved by introspection, e.g., not by configuring the computer program to evolve the execution counter, but by determining the execution counter externally from the computer program. For example, the execution counter may be determined at least in part based on a stack trace. A stack trace may represent one or more recursive function calls performed as part of the computer program. At least the execution-independent part of the execution counter may be derived from such a stack trace. For example, the stack trace may comprise an identifier of a function and of a location in the function, indicating that the function below it in the stack trace was called from this function at this location. For example, a stack trace may be represented by file names and line numbers, as illustrated in the following example of file names and line numbers of scripts in the Python programming language:

[0099] [runtime. py:1401 , asyncoro.py:437, runtime. py:1331 , runtime. py:1313, sectypes. py:337, kmsurvival.py:161, kmsurvival. :300 events. py:84 base_events.py:1936, base_events.py:608, base_events.py:641 , runtime. py:200, kmsurvival. py:312]

[0100] In this example, for example, the entry kmsurvival. py:300 may represent the top-level function of the computer program whose progress is to be estimated. In this example, the execution-independent part of the execution counter may be derived from the frames of the stack trace formed by the top-level function and those functions that it directly or indirectly calls: in this case, the underlined part. For example, in this example, the execution-independent part may be formed by the underlined text, or a hash thereof. The non-underlined part in this example may represent callers of the top-level function and can be ignored for the purpose of determining the execution-independent part.

[0101] It is also possible to use other identifying information instead of the file name and line number, e.g., a function name and an address within that function. The executiondependent part can for example be given by an identifier, e.g., a memory address or an object identifier, of the top-level function, and / or a part of the stack trace representing the caller of the top-level function. For example, the top-level function, or its caller, may explicitly notify the progress estimation facility to indicate that progress is to be estimated for the toplevel function, or the relevant frames of the stack trace may be extracted based on a criterion, e.g., a file name or function name pattern. Regardless of this, the determination of the stack trace and the resulting execution counter may be performed, e.g., periodically and / or upon a request to determine a progress estimate.

[0102] Fig. 4c shows a detailed, yet non-limiting, example of determining a progress estimate. This example shows an execution counter EC, 410, comprising an optional execution-dependent part EDP, 411 , and an execution-independent part EIP, 412. The execution counter may be determined as described with respect to Fig. 4a-4b, or by introspection as described elsewhere, for example.

[0103] The figure further shows a progress estimation mapping 403 comprising one or more entries. A respective entry may map an execution-independent part ElPk of a respective execution counter to a respective progress estimate ESTk. The respective progress estimate ESTk may be indicative of a progress in the execution corresponding to the current control flow position indicated by the execution counter ElPk. A progress estimate ElPk of the mapping may represent a completed proportion of the execution of the computer program, represented for example as a percentage, as a number on a scale of 0 to 1, or similar. The mapping 403 may be obtained by calibrating it with respect to a measured use of a resource, as discussed in more detail elsewhere.

[0104] The figure further shows an estimation operation Est, 460. Estimation operation Est may comprise determining a progress estimate EST, 470 for the execution of the computer program according to the execution-independent part EIP of the execution counter EC and according to the progress estimation mapping 403. In this example, progress estimate EST may be determined by looking up the execution-independent part EIP and returning the corresponding progress estimate from the mapping. If the executionindependent part is not found, it is possible not to return an estimate EST, or to leave the estimate EST unchanged from a previous value, for example.

[0105] Estimation operation Est can be performed as triggered by a change in the execution counter, as discussed e.g. with respect to Fig. 4a or 4b; periodically; and / or upon a request to determine an updated progress estimate.

[0106] Estimation operation Est can be configured to determine progress estimates for instances of multiple computer programs in various ways. In an embodiment, estimation operation Est is configured to access respective mappings 403 corresponding to respective computer programs. A request to determine a progress estimate may include an identifier of the computer program being executed. Instead or in addition, the mappings of multiple computer programs may be combined into a single mapping. In such a case, preferably, the execution-independent part of the execution counter may be configured to evolve from different starting values for the different computer programs. This way, the estimation Est may obtain the estimate for the right computer program. The set of multiple computer programs may also include multiple computer program variants representing the same computer program being called with different parameters, e.g., a table join called as a left join, as a right join, as an inner join, or as an outer join; this way, progress estimates for the computer program can be determined based on a variant that is expected to have a good similarity in control flow thus to provide accurate progress estimates.

[0107] Estimation operation Est can be configured to provide respective progress estimates EST for multiple respective concurrent executions of the same and / or different computer programs, such as variants of the same computer program. For example, the execution-dependent part EDP may include an identifier of the execution, and estimation operation Est may be configured to output a respective identifier with a respective progress estimate; and / or to report the respective progress estimate to the respective program; etc.

[0108] It is also possible for estimation operation Est to determine a combined progress estimates (not shown here) for multiple respective computer programs that are concurrently being executed, e.g., by determining an average of the respective progress estimates. The average may be weighted, e.g., according to a relative cost of the computer program. To this end, a mapping of respective compute programs, e.g., respective variants of a computer program, to respective relative costs, may be made accessible.

[0109] Fig. 5 shows a detailed, yet non-limiting, example of performing a synchronised operation. This example illustrates a synchronised operation being performed by at least two parties, illustrated by respective sequence diagrams 501, 502. The parties may exchange messages, wherein the messages are identified based on an execution counter as described herein, e.g., with respect to Fig. 4a-4b.

[0110] In particular, the figure shows computer program A, 511, 512, being executed by the respective parties. For this computer program A, an execution counter may be evolved. In particular, as shown in the figure, at the start of the computer program A, the execution counter may have value ECA at both parties 501, 502. For example, computer program A may be called with the initial execution counter as an argument. For simplicity, it is assumed throughout this figure that the execution counter is the same at both parties. This is not strictly needed, as long as the execution counters correspond at the two parties such that messages at respective parts of the distributed computation can be identified based on the respective execution counter. For example, the execution-dependent parts of the two execution counters may be the same, and may be used to identify messages as described herein, whereas the execution-dependent parts can be different.

[0111] The figure further shows the execution of a subroutine B, 521 , 522, at the respective parties. Interestingly, the execution counter may be evolved by determining, from the current execution counter ECA in the program A, a forked execution counter ECB and an evolved execution counter ECA, replacing the previous value of ECA. The execution counters may be determined by performing a forking operation Fork, 531 , 532, as discussed e.g., with respect to Fig. 4b. For example, subroutine B may be called, 541, 542 with the forked execution counter as an argument.

[0112] Subroutine B may comprise a message exchange between the parties, for example, as part of a secure multi-party computation protocol between the parties. In this example, party 501 may send a message, which may be received by party 502. Interestingly, the message may be identified based on the execution counter. For example, the message may comprise a header and a payload, and the header may comprise an identifier based on the execution counter, in this case, on ECB. For example, as illustrated in the figure, a Send routine, 551 and a Recv routine, 552, may be used, that have the execution counter, or an identifier derived from it, as an argument. Interestingly, upon receipt of the message by party 502, the message may be routed to the Recv routine using the identifier.

[0113] The identifier used to identify the message can for example be equal to the execution-independent part of the execution counter. It is advantageous however to use the execution-dependent part of the execution counter, such that messages from different concurrent executions of the computer program may be distinguished.

[0114] As shown in the figure, the forked execution counter ECB may be evolved upon sending 551 and / or receiving 552 the message, e.g., by performing an increment as also discussed with respect to Fig. 4a. As discussed, the increment may trigger the determination of a progress estimate, or may in any case cause the next determined progress estimate to be determined based on the incremented execution counter.

[0115] As illustrated in the figure, the incremented execution counter may be used in a further message exchange: for example, one in which party 502 sends, 562 a message and party 501 receives it, 561, identified based on the incremented execution counter. The execution counter ECB may be further evolved upon the further sending / receiving.

[0116] The figure further illustrates the remainder of the computer program A after executing the subroutine B. In this remainder, for example, one or more further messages may be exchanged, one or more further subroutines may be called; and / or the evolved execution counter ECA may be further evolved, e.g., by an increment 571, 572.

[0117] Interestingly, as illustrated in this figure, execution counters can play a double role of identifying messages and being used to determine progress estimates. This applies to execution counters that are evolved as part of the computer program itself, as illustrated in this figure; but also to execution counters determined by introspection; for example, the computer program may determine a message identifier by introspecting itself and deriving the execution counter.

[0118] Many variations are possible. For example, subroutine B may recursively call itself or another subroutine, messages may be exchanged directly from computer program A itself, etc. It is also possible to evolve the execution counter without sending a message. As an example, in a setting with more than two parties, at a certain point, not all parties may be involved in a message exchange, in which case the uninvolved parties may increment the execution counter to keep it in sync with the execution counters of the involved parties.

[0119] Fig. 6a shows a detailed, yet non-limiting, example of evolving an execution counter. This example illustrates performing a loop in a certain number of iterations, in this case, sequentially.

[0120] Shown in the figure is a computer program A, 601 , that is executed. The execution may comprise execution counter ECA being evolved, e.g., by an increment 691. In this example, the computer program A comprises a loop for i=1,...,N, 692, which is performed in a certain number of iterations, in this case, N. The body body, 602, of the loop, may comprise operations that evolve the execution counter, such as message exchanges. By way of illustration, an increment Inc, 694, that is part of body, is shown.

[0121] In some embodiments, the number of iterations N may differ between different executions of the computer program A, e.g., the number of iterations may depend on the inputs of the computer program. In this case, evolving the execution counter ECA and using a progress estimation mapping for this execution counter for progress estimation, may not lead to accurate progress estimates for all possible values of N. Namely, the mapping may effectively represent one possible evolution of the execution counter, for a specific number of iterations, and may not be representative of other evolutions with a different number of iterations. Moreover, regardless of whether the number of iterations is fixed or variable, the number of evolved execution-independent parts of the execution counter ECA from performing multiple iterations in such a way can be large, leading to a large progress estimation mapping.

[0122] Interestingly, however, the inventors realised that a more accurate progress estimate, and a smaller progress estimation mapping, may be obtained, by applying the progress estimation recursively to the loop iteration to obtain an iteration progress estimate, and then determining an overall progress estimate from the iteration progress estimate. To this end, an iteration 693, 695 of the loop 692 may be performed, while evolving an iteration execution counter (EIPB,EDPB,I), (EIPB,EDPB,2). The execution-independent part EIPB of the iteration execution counter may be determined such that, for different iterations that are in the same current control flow position within the iteration, the execution-independent part is the same. For example, the execution-independent part may, for respective loop iterations, be evolved from the same starting value. The execution-dependent part of the execution counter can, if using, evolve from different starting values, although, if the iterations are performed non-concurrently, it is also possible to re-use the same starting value.

[0123] As shown, the remainder of the computer program A after the end of the loop end for, 692, may be performed while evolving the execution counter for the computer program, e.g., including performing an increment Inc, 697, as illustrated in the figure. For example, the remainder of computer program A may be evolved from an evolved execution counter, and the loop may be performed from a forked execution counter, determined according to a forking operation as discussed with respect to Fig. 4b.

[0124] Fig. 6b shows a detailed, yet non-limiting, example of determining a progress estimate. This example shows how, when performing a loop, a progress estimation may be determined. For example, this example may be combined with the example of Fig. 6a.

[0125] This example shows in particular a progress estimation operation Est, 660, which determines a progress estimate EST, 670, for the execution of the program based on an iteration progress estimate. The iteration progress estimate itself may be determined by evolving an iteration execution counter ECB, 612, while performing an iteration of the loop.

[0126] The loop may be performed for a given number of times N. As also discussed with respect to Fig. 6a, the number N can be fixed, or it can be variable. Interestingly, when the number of iterations N is variable, it can be included in the iteration execution counter ECB or otherwise be made available to estimation Est. The number of iterations may however be regarded not to be part of the execution-independent part ECB of the iteration execution counter, to avoid the number of iterations causing a difference in executionindependent parts between different executions. Also the number of completed iterations may be included in the ECB outside of its execution-independent part. As also discussed elsewhere, the execution counter may be obtained by being explicitly evolved by the computer program, or by introspection, for example. In the case of introspection, one or more variables representing the current iteration and the total number of iterations may be identified to the progress reporting, for example, by annotation, or by a variable naming convention.

[0127] The iteration progress estimate (not shown separately in this figure) may be determined from the iteration execution counter ECB, according to a progress estimation mapping 603 for the subroutine. A respective entry of mapping 603 may map an executionindependent part of a respective iteration execution counter to a respective iteration progress estimate. The respective progress estimate may be indicative of a progress in the execution of the iteration, corresponding to the current control flow position indicated by the iteration execution counter. The iteration progress estimate may for example be determined e.g. as discussed with respect to Fig. 4c; or, if the loop is itself performed as part of another loop, by recursively applying the technique discussed with respect to the present figure, etc.

[0128] The overall progress estimate EST may be determined from the iteration progress estimate. In particular, the progress estimate may be obtained based on a progress estimate for the beginning of the loop and a progress estimate for the end of the loop. For example, referring back to Fig. 6a, at the beginning of loop 692 the execution counter may be forked into a forked execution counter and an evolved execution counter, with the forked execution counter being used to execute the loop. In such a case, the execution counter prior to the forking may be used to obtain a progress estimate for the beginning the loop, and the evolved execution counter may be used to obtain a progress estimate for the end of the loop, for example, by a lookup in the progress estimation mapping for computer program A. It is also possible, as illustrated in the figure, to associate in the progress estimation mapping 604 for program A both the beginning progress estimate EST1 and the end progress estimate EST2 for the loop to the execution-independent part of the execution counter for the loop, for example.

[0129] Overall progress estimate EST may be determined based on the number of iterations N, the beginning and end progress estimates B, E for the loop, the number of completed iterations C, and the iteration progress estimate of the current iteration E. For example, an interpolation formula may be used, e.g., assuming progress estimates between 0 and 1, the formula B + (E-B)*(C+E) / N may be used. Such a formula may be adapted to other values of the progress estimate as appropriate.

[0130] Accordingly, it may effectively be assumed that the loop takes up a fixed part of the overall computer program regardless of the number of iterations. This has been found in practice to lead to accurate progress estimates for various computer programs.

[0131] As another example, in the case where multiple iterations of the loop are executing concurrently with respective progress estimates E1 ,...,Ek, the overall progress estimate EST may be determined as B + (E-B)*(C+E1+...+Ek) / N, or similar.

[0132] The techniques discussed with respect to this figure can be applied recursively, e.g., the determined estimate EST may itself be used as an iteration progress estimate for an iteration of a loop to estimate progress of a program that includes the loop.

[0133] Fig. 7 shows a detailed, yet non-limiting, example of performing iterations concurrently. This example illustrates the case where multiple iterations of a loop may be performed at least in part concurrently. For example, the iterations may be performed concurrently with a certain maximum number of iterations. The maximum number can for example be at least 2, at most or at least 8, or at most or at least 32.

[0134] As was discussed with respect to Fig. 6b, it is possible to use respective iteration progress estimates for the respective iterations that are currently being performed, and combine them into an overall progress estimate.

[0135] However, as the inventors realized, it is not necessary to track and estimate progress for the respective concurrent executions. Instead, when a further iteration of the loop is performed at least in part concurrently with a first iteration, the progress estimate for the execution of the program may be based on the progress estimate of the first iteration, without having to evolve an iteration execution counter and / or determine an iteration progress estimate for the further iteration. This may allow for a simpler and more efficient implementation, e.g., where locking of progress-related data for the respective concurrent iterations may be avoided.

[0136] In particular, an iteration of the loop may be performed by determining whether another respective iteration of the loop is currently evolving a respective iteration execution counter. If not, an iteration execution counter for the iteration may be evolved, and an iteration progress estimate may be determined based on the iteration execution counter. If so, the evolving and / or determining may be avoided.

[0137] By way of example, the figure illustrates six iterations T1 , 701 , up to T6, 706 of a loop being performed at least in part in concurrently, with a maximum of three iterations being performed in parallel. The width of the respective boxes Ti represents the time taken up by the iterations. The illustrated times and their relative differences are for illustration only; in a typical case, the times taken up by respective iterations may be more similar to each other than shown. The figure shows three iterations T1, T2, T3, being started at around the same time.

[0138] Iteration T1 may determine that no other iteration is reporting progress, and may accordingly be executed with progress estimation. As discussed with respect to Fig. 6b, the iteration progress estimation of T1 may be combined with a number of completed iterations to determine an overall progress estimate; this number of completed iterations may initially be zero but may increase to 1 for later progress estimates as task T2 finishes, as also illustrated in the figure.

[0139] Iteration T2 may start at around the same time as iteration T1 , but may determine that iteration T1 is already reporting progress; e.g., iteration T2 may perform this check just after iteration T1 has registered that it is reporting progress, e.g., using locking to ensure that this information is synchronized. Accordingly, iteration T2 may not report progress. Similarly, iteration T3 may determine that iteration T1 is reporting progress and so may be configured not to report progress itself.

[0140] When iteration T2 completes, iteration T4 can start according to the maximum number of concurrent iterations. Also iteration T4 may determine that task T1 is already reporting progress, and may accordingly not report progress itself.

[0141] When iteration T1 completes, iteration T5 may start. Iteration T5 may determine that there is no iteration currently reporting progress, so iteration T5 may report progress itself. Alternatively, an already started iteration, e.g., T3 or T4, may determine that no iteration is reporting progress, and may start to do so. The iteration progress estimates of iteration T5 may be combined with the information that two iterations, namely iteration T1 and iteration T2, have completed so far.

[0142] When iterations T3 and T5 complete, iteration T6 may start, may determine that no iteration is reporting progress, and may thus report progress itself. The iteration progress estimates of iteration T5 may be combined with the information that four iterations, namely iterations T1, T2, T3, and T5, have completed so far. When iteration T4 completes, in this example there is no new iteration to start, but the information that iteration T4 has completed may be used to determine a progress estimate from the iteration progress estimate of iteration T6.

[0143] Fig. 8 shows a detailed, yet non-limiting, example of calibrating a progress calibration mapping according to an execution of a computer program. Shown in the figure is a progress calibration mapping 803. A respective entry of mapping 803 may map an execution-independent part EIP of a respective execution counter to a respective progress estimate EST. The execution counter may be indicative of a current control flow position of a computer program. The respective progress estimate may be indicative of a progress in an execution of the computer program, corresponding to the current control flow position indicated by the execution counter. The progress estimation mapping may be for use as described herein, e.g., with respect to Figs. 4c and 6b.

[0144] To determine the progress calibration mapping 803, the computer program may be executed. The execution may comprise evolving execution counter EC, 810, indicative of the current control flow position of the computer program. The execution counter EC may comprise an execution-independent part EIP, 812. The executionindependent part of the execution counter may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same. As shown in the figure, the execution counter may further comprise an execution-dependent part EDP, 811. The execution counter may be defined and evolved as described elsewhere in this specification, e.g., through introspection, or as discussed with respect to Figs. 4-5. For the present purpose of calibrating per se, it may not be needed to evolve the execution-dependent part EDP, since it may not form part of the mapping 803 to be determined; and accordingly, the execution counter EC that is evolved for calibration may per se not need to comprise it (unless used for other purposes).

[0145] The execution of the computer program may further comprise measuring a current cumulative use M, 841 , of a resource. The use of the resource may be used as a proxy for a cost of the computer program. The progress of the computer program may be estimated as an expected proportion of the total use of the resource that has been spent so far, and thereby, the progress estimate may represent a completed proportion of the execution of the computer program.

[0146] Various resources may be measured, e.g., wall clock time, CPU usage, incoming and / or outgoing network traffic measured e.g. in size or number of messages, etc. Measuring wall clock time may be advantageous since a progress estimate in terms of wall clock time may lead to an accurate prediction of how long the computation may still take. Measuring network traffic can for example be advantageous in the setting of a distributed computation, since in such cases this measurement M may already be measured anyway. Another advantage of measuring network, or another metric that is computed exactly, is calibration can be performed on very small problem instances, and can thus be performed efficiently, while still obtaining sufficiently accurate measurements to provide reliable progress estimates. Typically, during calibration, only a single instance of the computer program is run at the same time, in order to obtain good measurements.

[0147] The figure shows a recording operation Rec, 820, in which executionindependent part EIP of the execution counter may be recorded in recording data 802, associated with the corresponding measurement M of the current cumulative use of the resource. The recording operation Rec may be triggered as described for the estimation operation Est, 460, of Fig. 4c, e.g., upon an evolution of the execution counter or periodically. The recording may further comprise recording an overall use Mtot, 842 of the resource, e.g. recording the cumulative use at the end of the computer program.

[0148] Based on the recording data, in a calibration operation Cal, 830, the progress estimation mapping 803 may be determined. A respective progress estimate EST for an execution-independent part EIP may be determined by comparing the current cumulative use of the resource M to the overall use of the resource Mtot, e.g., by dividing M by Mtot.

[0149] Various extensions are possible. It is possible to repeat the recording Rec and calibration Cal multiple times for the same computer program, for example, with the same or with different inputs, and to determine the estimate EST based on these multiple runs, e.g., as an average. In such a case, for example due to differences in inputs, the sets of recorded execution-independent parts may not be exactly the same. In such a case, e.g., per execution-independent part an average over available measurements may be taken.

[0150] It is also possible to make the progress estimation mapping smaller by filtering it. The filtering can for instance be based on selecting execution-independent parts that were measured in a largest number of runs, and / or based on selecting executionindependent parts that provide a representative set of progress estimates. For example, the set of possible progress estimates may be divided into intervals or possible values, and for an interval or a possible value, a number of progress estimates may be selected, e.g., the single progress estimate that was most measured. For example, in case progress estimates are reported as percentages, for respective percentages 1%, 2%, ..., an executionindependent part may be selected corresponding to this estimate. Other executionindependent parts can for example be discarded.

[0151] Another possibility is to perform recording Rec and calibration Cal for executions of multiple different computer programs, which can be multiple different variations of the same computer program, as also discussed elsewhere. In such a case, it is possible to output a single progress estimation mapping 803 for multiple computer programs at the same time, and / or to output respective progress estimation mappings for respective computer programs. It is also possible to store a measured total resource use Mtot for a program computer program, e.g., for use in determining a weighted average of progress estimates of multiple concurrent executions, as also discussed elsewhere.

[0152] Fig. 9 shows a block-diagram of a computer-implemented method 900 of estimating progress of an execution of a computer program. For example, the method may be performed by device 200 of Fig. 2. However, this is not a limitation, in that the method 900 may also be performed using another system, apparatus or device.

[0153] The method 900 may comprise, in an operation titled "EXECUTE", executing 910 the computer program. The operation 910 may comprise, in an operation titled "EVOLVE", evolving 915 an execution counter. The execution counter may be indicative of a current control flow position of the computer program. The execution counter may comprise an execution-independent part. The execution-independent part of the execution counter may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same.

[0154] The method 900 may comprise, in an operation titled "ACCESS PROGRESS ESTIMATION MAPPING", accessing 920 respective progress data representing respective entries of a predetermined progress estimation mapping. A respective entry may map an execution-independent part of a respective execution counter to a respective progress estimate. The respective progress estimate may be indicative of a progress in the execution corresponding to the current control flow position indicated by the execution counter.

[0155] The method 900 may comprise, in an operation titled "ESTIMATE", determining 930 a progress estimate for the execution of the computer program according to the execution-independent part of the execution counter and according to the progress estimation mapping.

[0156] The method 900 may comprise, in an operation titled "OUTPUT", outputting 940 the progress estimate.

[0157] Fig. 10 shows a block-diagram of a computer-implemented method 1000 of calibrating a progress estimation mapping. The method may be performed by device 100 of Fig. 1. However, this is not a limitation, in that the method 1000 may also be performed using another system, apparatus or device. The determined progress estimation mapping may be for use by a device as described herein, e.g., device 200 of Fig. 2; and / or for use according to a computer-implemented method as described herein, e.g., method 900 of Fig. 9. It is also possible to combine method 1000 of calibrating a progress estimation mapping, with a method of estimating progress that uses the calibrated mapping, such as method 900 of Fig. 9. The method 1000 may comprise, in an operation titled "EXECUTE", executing 1010 the computer program. The operation 1010 may comprise, in an operation titled "EVOLVE", evolving 1015 an execution counter. The execution counter may be indicative of a current control flow position of the computer program. The execution counter may comprise an execution-independent part. The execution-independent part of the execution counter may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same. The operation 1010 may further comprise, in an operation titled "MEASURE", measuring 1017 a current cumulative use of a resource.

[0158] The method 1000 may further comprise, in an operation titled "MAP", determining 1020 a progress estimation mapping. The progress estimation mapping may map a respective execution independent part to a respective progress estimate. Operation 1020 may comprise, in an operation titled "COMPARE", comparing the current cumulative use of the resource to an overall use of the resource.

[0159] It will be appreciated that, in general, the operations of method 900 of Fig 9 or method 1000 of Fig. 10 may be performed in any suitable order, e.g., consecutively, simultaneously, or a combination thereof, subject to, where applicable, a particular order being necessitated, e.g., by input / output relations. As discussed, methods 900 and 100 can also be combined into a single computer-implemented method.

[0160] The method(s) may be implemented on a computer as a computer implemented method, as dedicated hardware, or as a combination of both. As also illustrated in Fig. 11 , instructions for the computer, e.g., executable code, may be stored on a computer readable medium 1100, e.g., in the form of a series 1110 of machine-readable physical marks and / or as a series of elements having different electrical, e.g., magnetic, or optical properties or values. The medium 1100 may be transitory or non-transitory. Examples of computer readable mediums include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Fig. 11 shows an optical disc 1100.

[0161] Instead of or in addition to such instructions, data 1110 stored on the medium 1100 may represent respective entries, e.g., all entries, of a progress estimation mapping as described herein, e.g., as determined by the method of Fig. 10, and / or for use as described herein, e.g., in the method of Fig. 9. A respective entry of the mapping may map an execution-independent part of a respective execution counter to a respective progress estimate. An execution counter may be indicative of a control flow position of the computer program. The execution-independent part of the execution counter may be determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same. The respective progress estimate may be indicative of a progress in the execution corresponding to the control flow position indicated by the execution counter.

[0162] Examples, embodiments or optional features, whether indicated as nonlimiting or not, are not to be understood as limiting the invention as claimed.

[0163] It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb "comprise" and its conjugations does not exclude the presence of elements or stages other than those stated in a claim. The article "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of’ when preceding a list or group of elements represent a selection of all or of any subset of elements from the list or group. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The invention may be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In the device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

Claims

CLAIMS1 . A computer-implemented method (900) of estimating progress of an execution of a computer program, comprising: executing (910) the computer program, comprising evolving (915) an execution counter, wherein the execution counter is indicative of a current control flow position of the computer program, wherein the execution counter comprises an executionindependent part, and wherein the execution-independent part of the execution counter is determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same; accessing (920) respective progress data representing respective entries of a predetermined progress estimation mapping, wherein a respective entry maps an executionindependent part of a respective execution counter to a respective progress estimate, wherein the respective progress estimate is indicative of a progress in the execution corresponding to the current control flow position indicated by the execution counter; determining (930) a progress estimate for the execution of the computer program according to the execution-independent part of the execution counter and according to the progress estimation mapping, and outputting (940) the progress estimate.

2. The method (900) of claim 1 , wherein the computer program is for performing a distributed computation with at least a further device, wherein the method further comprises sending and / or receiving a message with the further device, wherein the message is identified based on the execution counter.

3. The method (900) of claim 2, comprising performing multiple executions of the computer program concurrently, wherein the execution counter further comprises an execution-dependent part, wherein the execution-dependent part is determined such that, for different executions of the computer program that are in the same current control flow position, the execution-dependent part is different.

4. The method (900) of any one of claims 2-3, wherein the computer program is for performing a cryptographic secure multi-party computation protocol.

5. The method (900) of any preceding claim, wherein the predetermined progress estimation mapping has been previously determined by calibrating the progress estimation mapping with respect to a measured use of a resource.

6. The method (900) of any preceding claim, comprising executing a subroutine by: determining, based on the execution counter, a forked execution counter and an evolved execution counter; executing the subroutine, comprising evolving the forked execution counter; and: executing a remainder of the computer program, comprising evolving the evolved execution counter.

7. The method (900) of any preceding claim, comprising performing a given number of iterations of a loop by: performing an iteration of the loop, comprising: evolving an iteration execution counter, wherein the execution-independent part of the iteration execution counter is determined such that, for different iterations that are in the same current control flow position within the iteration, the execution-independent part is the same; and determining an iteration progress estimate based on the iteration execution counter; determining a progress estimate for the execution of the program based on the iteration progress estimate.

8. The method (900) of claim 7, further comprising performing a further iteration of the loop at least in part concurrently with the first iteration, and wherein the progress estimate for the execution of the program is not based on a progress estimate of the further iteration.

9. The method (900) of any preceding claim, comprising performing multiple operations concurrently by: performing a respective operation, comprising evolving a respective operation execution counter; and determining a respective operation progress estimate for the respective operation based on the respective operation execution counter; and determining a progress estimate based on the respective operation progress estimates.

10. The method (900) of any preceding claim, wherein the progress estimate represents a completed proportion of the execution of the computer program.

11. A computer-implemented method (1000) of calibrating a progress estimation mapping for use in the computer-implemented method according to any preceding claim, comprising: executing (1010) the computer program, comprising evolving (1015) an execution counter, wherein the execution counter is indicative of a current control flow position of a computer program; wherein the execution counter comprises an executionindependent part; and wherein the execution-independent part of the execution counter is determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same; wherein executing the computer program further comprises measuring (1017) a current cumulative use of a resource; determining (1020) a progress estimation mapping, wherein the progress estimation mapping maps a respective execution independent part to a respective progress estimate, wherein the respective progress estimate is determined (1025) by comparing the current cumulative use of the resource to an overall use of the resource.

12. The method (1000) of claim 11 , wherein the resource is time, network traffic, or CPU usage.

13. A device (200) for estimating progress of an execution of a computer program, comprising: a data interface (220) for accessing respective progress data (030) representing respective entries of a predetermined progress estimation mapping, wherein a respective entry maps an execution-independent part of a respective execution counter to a respective progress estimate; wherein an execution counter is indicative of a control flow position of the computer program; wherein the execution-independent part of the execution counter is determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same; and wherein the respective progress estimate is indicative of a progress in the execution corresponding to the control flow position indicated by the execution counter; a processor subsystem (240) configured to: execute the computer program, comprising evolving the execution counter; determine a progress estimate for the execution of the computer program according to the execution-independent part of the execution counter and according to the progress estimation mapping; and output the progress estimate.

14. A device (100) for calibrating a progress estimation mapping for use in the computer-implemented method according to any one of claims 1-11, comprising: a data interface (120) for accessing respective progress data (030) representing respective entries of a progress estimation mapping, wherein a respective entry maps an execution-independent part of a respective execution counter to a respective progress estimate; wherein an execution counter is indicative of a control flow position of a computer program; wherein the execution-independent part of the execution counter is determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same; and wherein the respective progress estimate is indicative of a progress in the execution corresponding to the control flow position indicated by the execution counter; a processor subsystem (140) configured to: execute the computer program, comprising evolving the execution counter, and further comprising measuring a current cumulative use of a resource; determine a progress estimation mapping, wherein the progress estimation mapping maps a respective execution independent part to a respective progress estimate, wherein the respective progress estimate is determined by comparing the current cumulative use of the resource to an overall use of the resource.

15. A transitory or non-transitory computer-readable medium (1100) comprising data (1110) representing one or more of: instructions which, when executed by a processor system, cause the processor system to perform the method according to any one of claims 1-10; instructions which, when executed by a processor system, cause the processor system to perform the method according to any one of claims 11-12; respective entries of a progress estimation mapping, wherein a respective entry maps an execution-independent part of a respective execution counter to a respective progress estimate; wherein an execution counter is indicative of a control flow position of the computer program; wherein the execution-independent part of the execution counter is determined such that, for different executions of the computer program that are in the same current control flow position, the execution-independent part is the same; and wherein the respective progress estimate is indicative of a progress in the execution corresponding to the control flow position indicated by the execution counter.

Images