A*

A* Modeling and Synthetic Applications

Motivation and Scope

'A'* stands for a set of application models -- any one application model of this set represents a specific class of applications which exhibit similar decomposition, and similar mapping of semantics to workload components, and thus similar execution structure. For example, the set 'bag of independent homogenous tasks' exhibits a well defineable set of execution properties, but can ultimately represent a large number of application instances (which are individually defined by their individual application semantics). A* modeling can be used and parametrized to create Synthetic Applications, i.e. application descriptions which truthfully represent the execution properties of the respective application class (system load, overall performance, etc), without actually performing the application's semantics.

Application Skeletons provide similar properties, and also faithfully recreate the execution properties for a certain (parametrizable) sets of applications. The main difference is that skeletons are derived from actual applications, perhaps via traces or via developer/user knowledge, and thus possibly more truthful, while the creation of Synthetic Applications is model driven, and thus possibly easier to reason about. More specifically, the model driven approach should allow (via model parametrization) to reason about (static and dynamic) infrastructure properties, and to adapt application properties, such as coordination and communication models, or application decomposition, accordingly.

Coverage

While A* focuses, obvisouly, on the upper level of the modeling stack, the resulting synthetic application can, just like skeletons, be represented throughout the complete stack, down to a workload executed on infrastructure resources -- the application model acts as a generator for artificial input to the overall modeling and execution stack.

As motivated above, we expect individual application models to represent very well defined classes of applications, which can potentially be very small. While we have no evidence, yet, the intuition is that smaller application classes will lead to simpler application models, and to more powerful reasoning abilities. We expect to cover applications of the following classes, among others:

• bag of homogeneous, undependent tasks
• set of heterogeneous, dependent tasks
• master-worker type applications
• loosely coupled ensembles of tightly coupled applications (incl. replica-exchange like applications)
• (simple) data driven workflows (including possibly MapReduce like applications)

---

Unsorted notes - please ignore

terminology:

• skeletons: generator of artificial workloads according to some recipe
• frameworks: translates app semantics to workloads
• system workloads: derivation of workloads, adds resource consumption details

modeling vs. experiments:

• Analytical Application Models
• Application Simulation
• Application Emulation
• Experiments on artificial applications
• Experiments on real applications

descriptions vs. model

• descriptions need an underlying model