Tool benchmarks

A benchmark was carried through to compare the efficiency of the two tools. The parameters of the machine that was used for the benchmark: P4 2.6GHz with 512KB L2 Cache and 512MB of main memory. Unfortunately MOSEL is not capable to handle models where the number of terminals (NT) is greater than 126, such that the runtime of the benchmarks (which in PRISM especially depend on NT) remain rather small.

Both of the tools were tested with the described model using the following parameters: λ=0.05,µ=0.3,ν =0.2,γ=δ=0.05,τ =0.1. The comparison of the two tools can be seen in Figure 11 and Figure 12. In Figure 13, we can see a more detailed description of the PRISM benchmark (the times of the model construction and model checking are indicated separately).

The following preliminary conclusions can be drawn from benchmark:

• The execution times of the MOSEL system almost stay constant indepen-dently ofNT;

• The execution times of the PRISM system increase rapidly with the increase ofNT.

• The model construction time in PRISM dominates the execution time rather than the model checking time (also [11] reports on the overhead of PRISM for model generation).

Evaluating a probabilistic model checker. . . 71

Figure 11: Results of the 2nd experiment

NT MOSEL PRISM

5 0.7125 0.025 10 0.7135 0.047

20 0.715 0.094

50 0.719 0.219

100 0.725 0.596 120 0.728 0.938

150 - 1.550

200 - 2.377

Figure 12: Total execution times of the MOSEL and the PRISM in seconds

NT Model const. Model checking Total

5 0.015 0.01 0.025

10 0.031 0.016 0.047

20 0.047 0.047 0.094

50 0.141 0.078 0.219

100 0.391 0.205 0.596

120 0.594 0.344 0.938

150 1.071 0.479 1.550

200 1.609 0.768 2.377

Figure 13: Execution times in seconds

72 T. Bérczes, G. Guta, G. Kusper, W. Schreiner, J. Sztrik While MOSEL is thus more efficient for smaller models, with PRISM also larger models can be analyzed. Furthermore, once a PRISM model is constructed, it can be arbitrarily often model checked with different parameter values (the PRISM “Ex-periments” feature). For such scenarios, the model checking time is more relevant than the model construction time.

6. Conclusions

Probabilistic model checkers like PRISM are nowadays able to analyze quantitative behaviors of concurrent systems in a similar way that classical performance analysis tools like MOSEL are. In this paper, we reproduced for the particular example of a retrial queuing system the results of an analysis that were previously generated with the help of MOSEL. The numerical results were virtually identical such that we can put confidence on the quality of the analysis. The construction of the models and the benchmarks of the tools demonstrate the following differences between both tools:

• The PRISM modeling language allows us to decompose a system into multiple components whose execution can be synchronized by combined state transi-tions; this makes the model more manageable than the monolithic MOSEL model. However, the decomposition can be only based on a fixed number of components such thatNT terminals must be still represented by a single PRISM module.

• The state transitions in PRISM are described on a lower level than those in MOSEL: all guard conditions have to be made explicit (while the MOSEL FROMpart of a rule imposes implicit conditions on the applicability of the rule) and all effects have to be exposed (while the MOSELTOpart of a rule imposes implicit effects); on the other side, this makes the PRISM rules more transparent than the MOSEL rules. In any case, the difference is syntactic rather than fundamental.

• Several kinds of analysis can be expressed in the property specification lan-guage of PRISM (by the definition of “rewards” and CSL queries for the long-term values of rewards) on a higher level than in MOSEL (where ex-plicit calculations have to be written). Like in MOSEL, not every kind of analysis can be directly expressed in PRISM; especially the average execu-tion times can be only computed indirectly from the combinaexecu-tion of reward values by external calculations.

• PRISM is also able to answer questions about qualitative system properties such as safety or liveness properties that are beyond the scope of MOSEL.

• The time for an analysis depends in PRISM on the size of the state space of the system while it essentially remains constant in MOSEL (which on the other side puts a rather small limit on the ranges of state variables); the time

Evaluating a probabilistic model checker. . . 73 growth factor in PRISM is is significantly super-linear. While we were thus able to analyze larger systems with PRISM than with MOSEL, it is thus not yet clear whether the analysis will really scale to very large systems.

• As documented by the PRISM web page, the tool is actively used by a large community in various application areas; PRISM is actively supported and further developed (the current release version 3.1.1 is from April 2006, the current development version is from December 2007). On the other hand, the latest version 2.0 of MOSEL-2 is from 2003; the MOSEL web page has not been updated since then.

The use of PRISM for the performance analysis of systems thus seems a promising direction; we plan to further investigate its applicability by analyzing more sys-tems with respect to various kinds of features. While there may be still certain advantages of using dedicated performance evaluation tools like MOSEL, we be-lieve that probabilistic model checking tools are quickly catching up; on the long term, it is very likely that the more general capabilities of these systems and their ever growing popularity will make them also the tools of choice in the performance evaluation community.

References

[1] Almási, B., Roszik, J., Sztrik, J., Homogeneous Finite-Source Retrial Queues with Server Subject to Breakdowns and Repairs, Mathematical and Computer Mod-elling, (2005) 42, 673–682.

[2] Baier, C., Haverkort, B., Hermanns, H., Katoen, J., Model Checking Continuous-time Markov chains by transient analysis, In 12th annual Symposium on Computer Aided Verification (CAV 2000), volume 1855 ofLecture Notes in Com-puter Science, Springer, (2000) 358–372.

[3] Barner, J., Begain, K., Bolch, G., Herold, H., MOSEL — MOdeling, Speci-fication and Evaluation Language, In2001 Aachen International Multiconference on Measurement, Modelling and Evaluation of Computer and Communication Systems, Aachen, Germany, September 11–14, 2001.

[4] Berczes, T., Guta, G., Kusper, G., Schreiner, W., Sztrik, J., Compar-ing the Performance ModelCompar-ing Environment MOSEL and the Probabilistic Model Checker PRISM for Modeling and Analyzing Retrial Queueing Systems, Techni-cal Report 07-17, Research Institute for Symbolic Computation (RISC), Johannes Kepler University, Linz, Austria, December 2007.

[5] Bernardo, M., Hillston, J. (editors), Formal Methods for Performance Eval-uation: 7th International School on Formal Methods for the Design of Computer, Communication, and Software Systems, SFM 2007, volume 4486 ofLecture Notes in Computer Science, Bertinoro, Italy, May 28 – June 2, 2007. Springer.

[6] Cooper, R. B., Introduction to Queueing Theory, North Holland, 2nd edition, 1981.

74 T. Bérczes, G. Guta, G. Kusper, W. Schreiner, J. Sztrik [7] Clarke, E. M., Grumberg, O., Peled, D. A., Model checking, MIT Press,

Cambridge, MA, USA, 1999.

[8] Herzog, U.,Formal Methods for Performance Evaluation, In Ed Brinksma, Holger Hermanns, and Joost-Pieter Katoen, editors, European Educational Forum: School on Formal Methods and Performance Analysis, volume 2090 ofLecture Notes in Com-puter Science, pages 1–37, Lectures on Formal Methods and Performance Analysis, First EEF/Euro Summer School on Trends in Computer Science, Berg en Dal, The Netherlands, July 3-7, 2000, Revised Lectures, 2001. Springer.

[9] Hinton, A., Kwiatkowska, M. Z., Norman, G., Parker, D., PRISM: A Tool for Automatic Verification of Probabilistic Systems, In Holger Hermanns and Jens Palsberg, editors,Tools and Algorithms for the Construction and Analysis of Systems, 12th International Conference, TACAS 2006, Vienna, Austria, March 27–30, volume 3920 ofLecture Notes in Computer Science, Springer, (2006) 441–444.

[10] Hirel, C., Tuffin, B., Trivedi, K. S., SPNP: Stochastic Petri Nets. Version 6.0, In Boudewijn R. Haverkort, Henrik C. Bohnenkamp, and Connie U. Smith, editors, Computer Performance Evaluation: Modelling Techniques and Tools, 11th International Conference, TOOLS 2000, Schaumburg, IL, USA, March 27-31, 2000, Proceedings, volume 1786 of Lecture Notes in Computer Science, Springer, (2000) 354–357.

[11] Jansen, D. N., Katoen, J.-P., Oldenkamp, M., Stoelinga, M., Zapreev, I., How Fast and Fat Is Your Probabilistic Model Checker? An Experimental Perfor-mance Comparison, In Hardware and Software: Verification and Testing, volume 4899 ofLecture Notes in Computer Science, pages 69–85, Proceedings of the Third International Haifa Verification Conference, HVC 2007, Haifa, Israel, October 23–25, 2007, 2008, Springer.

[12] Kwiatkowska, M., Quantitative Verification: Models, Techniques and Tools. In 6th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE), Cavtat near Dubrovnik, Croatia, September 3–7, 2007, ACM Press.

[13] Norman, G., Kwiatkowska, M., Parker, D., Stochastic Model Checking, In M. Bernardo and J. Hillston, editors,Formal Methods for Performance Evaluation:

7th International School on Formal Methods for the Design of Computer, Communi-cation, and Software Systems, SFM 2007, volume 4486 ofLecture Notes in Computer Science, pages 220–270, Bertinoro, Italy, May 28 – June 2, 2007, Springer.

[14] MOSEL — Modeling, Specification, and Evaluation Language, June 2003.

http://www4. informatik.uni-erlangen.de/Projects/MOSEL.

[15] MOSEL-2, September 2007.

http://www.net.fmi.uni-passau.de/hp/projects-overview/mosel-2.html.

[16] PRISM — Probabilistic Symbolic Model Checker, September 2007.

http://www.prismmodelchecker.org.

[17] Roszik, J., Sztrik, J., Virtamo, J.,Performance Analysis of Finite-Source Retrial Queues Operating in Random Environments, International Journal of Operational Research, (2007) 2, 254–268.

[18] Stewart, W. J., Performance Modelling and Markov Chains, InFormal Methods for Performance Evaluation: 7th International School on Formal Methods for the

Evaluating a probabilistic model checker. . . 75 Design of Computer, Communication, and Software Systems, SFM 2007, volume 4486 ofLecture Notes in Computer Science, pages 1–33, Bertinoro, Italy, May 28 – June 2, 2007, Springer.

[19] Sztrik, J., Kim, C. S., Performance Modeling Tools with Applications, Annales Mathematicae et Informaticae, (2006) 33, 125–140.

[20] Unified Modeling Language (UML), version 2.1.1, 2007.

http://www.omg.org/technology/documents/formal/uml.htm.

[21] Wolter, K.(editor),Formal Methods and Stochastic Models for Performance Eval-uation, number 4748 in Lecture Notes in Computer Science, Fourth European Per-formance Engineering Workshop, EPEW 2007, Berlin, Germany, September 27–28, 2007.

Tamás Bérczes, János Sztrik

Faculty of Informatics, University of Debrecen Hungary

e-mail:{tberczes,jsztrik}@inf.unideb.hu Gábor Guta, Wolfgang Schreiner

Research Institute for Symbolic Computation (RISC) Johannes Kepler University

Linz, Austria

e-mail: {Gabor.Guta,Wolfgang.Schreiner}@risc.uni-linz.ac.at Gábor Kusper

Eszterházy Károly College, Eger, Hungary e-mail: gkusper@aries.ektf.hu

Annales Mathematicae et Informaticae 37(2010) pp. 77–84

http://ami.ektf.hu

On the skeleton of a finite transformation semigroup

Attila Egri-Nagy

^ab

, Chrystopher L. Nehaniv

^b

aDepartment of Computing Science, Eszterházy Károly College, Hungary

bSchool of Computer Science, University of Hertfordshire, United Kingdom Submitted 5 October 2010; Accepted 13 December 2010

Dedicated to professor Béla Pelle on his 80^th birthday Abstract

There are many ways to construct hierarchical decompositions of trans-formation semigroups. The holonomy algorithm is especially suitable for computational implementations and it is used in our software package. The structure of the holonomy decomposition is determined by the action of the semigroup on certain subsets of the state set. Here we focus on this struc-ture, the skeleton, and investigate some of its properties that are crucial for understanding and for efficient calculations.

Keywords: transformation semigroup, Krohn-Rhodes decomposition, holon-omy algorithm

MSC:20M20, 20M35, 06A06

1. Introduction

The holonomy decomposition [11, 12, 6, 8, 9, 3] is an important proof technique for the Krohn-Rhodes theory [1, Chapter 5], as it works with transformation semi-groups, instead of abstract ones, and it is relatively close to the computer scientist’s way of thinking. Our computer algebra package,SgpDec[5] is now a mature piece of software, so we can study the holonomy decompositions of semigroups with tens of thousands of elements. Here we concentrate on simpler examples and study the underlying structure of the holonomy decomposition, namely the skeleton of the transformation semigroup [6, 9]. It is important to note that this notion is different from the skeleton of an abstract semigroup (biordered set of idempotents) and from the topological concept with the same name.

77

78 A. Egri-Nagy, C. L. Nehaniv Mathematical preliminaries

A transformation semigroup (X, S)is a finite nonempty set X (the state set) to-gether with a set S of total transformations of X closed under function compo-sition. A semigroup is a monoid if it contains the identity element, the identity map in case of transformations. The action on the points (states) x ∈ X natu-rally extends to set of points: P ·s = {p·s | p ∈ P}, P ⊆ X, s ∈ S. The set O(X) = {X·s | s ∈ S} is the orbit of the state set. For finite transformations we use two different notations. The traditional matrix notation uses two rows, one for the elements ofX and the second for their corresponding images. We also use the linear (one-line) notation defined in [7] with slight modifications described in [4]. The linear notation is a generalization of the cyclic notation for permutations, therefore the cycle decomposition works as usual. However, for collapsing states we use[xi1, . . . , xik;xi]meaning thatxij 7→xifor allj∈ {1, . . . , k}. These expressions can be nested recursively and blended with the cycle notation. This mirrors the fact that graphically a finite transformation is a bunch of cycles decorated with trees (incoming collapses). Examples are abundant in Section 3. The linear nota-tion is proved to be very useful in software implementanota-tions and it is expected to soon have widespread use.

In document Annales Mathematicae et Informaticae (37.) (Pldal 72-80)