Towards NFC payments using a lightweight architecture for the Web of Things The Web (and Internet) of Things has seen the rapid emergence of new protocols and standards, which provide for innovative models of interaction for applications. One such model fostered by the Web of Things (WoT) ecosystem is that of contactless interaction between devices. Near Field Communication (NFC) technology is one such enabler of contactless interactions. Contactless technology for the WoT requires all parties to agree one common definition and implementation and, in this paper, we propose a new lightweight architecture for the WoT, based on RESTful approaches. We show how the proposed architecture supports the concept of a mobile wallet, enabling users to make secure payments employing NFC technology with their mobile devices. In so doing, we argue that the vision of the WoT is brought a step closer to fruition. Users have long been accustomed to consuming services offered over the Internet using web browsers. However, with Apple and Google's launch of the smartphone era in 2007-8, users have also started to consume services and acquire vast amounts of information when they are on the move. This trend has grown exponentially since then, with smartphones dominating today's cell phone markets. A separate but related trend has been that of an increasing number of hitherto standalone devices and sensors now being endowed with wired/wireless connectivity. Together, these two have given rise to the Internet of Things (IoT), a global information network consisting of trillions of smart objects in the world we live in [1] .. One of the enablers of the IoT is NFC technology. This technology is currently governed by the ISO/IEC 18092:2013 standard [2] , which regulates the way two inductively coupled devices operating at 13.56 MHz can communicate through a Radio Frequency (RF) interface using a standardised transmission protocol. This contactless technology can be used as a short-range peer-to-peer communication method between any mobile devices provided it is NFC-enabled via an appropriate chip.. Contactless technology for the IoT requires all parties to agree one common definition and implementation. Having different implementation of one technology blocks interoperability, confuses users and raises the market entry barrier for companies. The idea of having a technology in mobile phones allowing everybody to participate in the IoT will only work if tags, devices, readers and application work seamlessly together and if there is an open market for these components. To this end, in this paper, we propose a new lightweight architecture for the Web of Things (WoT), based on REpresentational State Transfer (RESTful) approaches. Taking the particular case of NFC-enabled mobile payments, we show how it supports the proposed architecture and that the WoT, rather than being a distant promise over the horizon, is indeed a component part of daily lives for an increasing number of consumers. This paper, which is built on our previous work [3] , has the following main contributions:. -Application of the light weight architecture [3] to NFC-enabled mobile payments:. NFC-based payments are believed to be one of the emerging areas in mobile commerce, but have been largely overlooked by current IoT/WoT research [4] [5] [6] [7] [8] [9] [10] [11] . This, in spite of the fact that mobile phone providers have started to equip smart phones with NFC tags, which will greatly facilitate and improve on the current payment practice. -Flexible, secure and personalized payment applications/transactions:. This work exploits cloud computing services in order to manage NFC payment applications. The potential outcome is to ensure flexible and secure management, personalization and ownership of the payment applications. Our proposed architecture supports intelligent profiling functions by managing customized information relevant to each user in certain environments, which updates the service offers and user profiles dynamically.. The rest of the paper is organised as follows. Sections 2 and 3 respectively describe the fundamental technologies and research challenges. The aim is to establish a ratio-nale for the proposed approach. Section 4 presents the proposed architecture and Sect. 5 illustrates an application scenario that's implemented within the proposed architecture. Section 6 introduces the case of NFC-based mobile payment and specifically looks at how the proposed architecture facilitates them. Section 7 then concludes the paper. Users have long been accustomed to consuming services offered over the Internet using web browsers. This trend has grown exponentially since then, penetrating the consumer smartphone market as well. A separate but related trend has been that of an increasing number of standalone devices/sensors now communication wired/wireless. Together, these two have given rise to the IoT. We have proposed a new lightweight architecture for NFC applied for payment over the WoT. This approach is grounded in a NFC cloud wallet scenario, and we show how RESTful services can be used as an advantage. We see this as an incremental step towards further eliminating the borders between smart objects, services and the data consumed by mobile clients. Future research should further explore the possibilities for strengthening and standardizing such a service environment, expanding the proposed architecture, as well as addressing important issues such as privacy and real-time response needs.

O B O O O B B O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O B O O O O O B I O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O B I I O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O B O O O O O O O O O O O O B O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O


Time-Domain Orthogonal Finite-Element Reduction-Recovery Method for Electromagnetics-Based Analysis of Large-Scale Integrated Circuit and Package Problems Abstract-A time-domain orthogonal finite-element reductionrecovery method is developed to overcome the large problem sizes encountered in the simulation of large-scale integrated-circuit and package problems. In this method, a set of orthogonal prism vector basis functions is developed. Based on this set of bases, an arbitrary 3-D multilayered system such as a combined package and die is reduced to a single-layer system with negligible computational cost. More importantly, the reduced single-layer system is diagonal and, hence, can be solved readily. From the solution of the reduced system, the solution of the other unknowns is recovered in linear complexity. The method entails no theoretical approximation. It applies to any arbitrarily shaped multilayer structure involving inhomogeneous materials or any structure that can be geometrically modeled by triangular prism elements. In addition, it permits nonlinear device modeling and broadband simulation within one run. Numerical and experimental results have demonstrated its accuracy and high capacity in simulating on-chip, package, and die-package interface problems. In this paper, a set of orthogonal prism vector basis functions have been developed. These bases are complete in representing fields. In addition, they enforce the tangential continuity of the electric field and the normal continuity of the electric flux across material interfaces. Based on this set of bases, a timedomain OrFE-RR method was developed to solve large-scale IC and package problems. This method is capable of reducing a 3-D layered system matrix to a single-layer system matrix with negligible cost, irrespective of the original problem size. In addition, the reduced single-layer system matrix is diagonal and, hence, can be solved readily. From the solution of the reduced system, the solutions of other unknowns are recovered in linear complexity. The method applies to any arbitrarily shaped multilayer structure involving inhomogeneous materials. It entails no theoretical approximation. Numerical and experimental results have demonstrated its superior performance in simulating onchip, package, and combined die-package problems.

O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O


Modeling people's place naming preferences in location sharing Most location sharing applications display people's locations on a map. However, people use a rich variety of terms to refer to their locations, such as "home," "Starbucks," or "the bus stop near my house." Our long-term goal is to create a system that can automatically generate appropriate place names based on real-time context and user preferences. As a first step, we analyze data from a two-week study involving 26 participants in two different cities, focusing on how people refer to places in location sharing. We derive a taxonomy of different place naming methods, and show that factors such as a person's perceived familiarity with a place and the entropy of that place (i.e. the variety of people who visit it) strongly influence the way people refer to it when interacting with others. We also present a machine learning model for predicting how people name places. Using our data, this model is able to predict the place naming method people choose with an average accuracy higher than 85%. The past few years have seen the launch of a number of "friend finder" applications which let people share their location with others [2, 4-6, 14, 23, 38, 46] . Many of these applications typically provide coordinate-based location estimates and show people's locations on a map.. These visualizations are a good match for navigation and emergency response applications which require absolute locations. However, they fail to capture the nuances people often use when referring to their location in interactions with others. People usually do not describe their locations to others as, for example, "40.443 north, -79.941 west" or "5837 Centre Ave." Instead, they often rely on a wide and rich range of terms such as "home," "Starbucks," "near Liberty Bridge," or "Chicago." These kinds of place descriptions let people modulate the amount of information they disclose to account for both privacy and utility considerations -the latter referring to how useful a given piece of information is likely to be to a particular individual in a given context. These examples illustrate the complex nature of place naming. A given location may be referred to in different ways depending on the situation.. Being able to computationally generate place names that capture these nuances could make location sharing applications more useful, enabling people to share more meaningful information based on particular circumstances and giving them a wider range of privacy options. For example, a person might be willing to let people know they are at "home", but uncomfortable showing them their home on a map or disclosing its street address. In addition, generating meaningful place names could render the integration of location information with other services more valuable. For example, a person could share her current location as a status message in an instant messaging client or on a social networking site, or show a text label denoting the place a photo was taken in a photo sharing application. This level of integration is less meaningful if location information is limited to a dot on a map.. In short, today there is a gap between how people actually name places and what technology can offer [51] . Reversegeocoding systems can translate geo-coordinates into street addresses and neighborhoods, but these kinds of names only provide information from a geographical perspective and do not always match how people would refer to places. As a first step towards building a place naming system, we collected data through a two-week study with 26 participants in two different cities, where we examined preferences for how people name places. We recorded the location traces of our participants over this time period, and followed up with participants to understand what factors influenced how they named the places they visited. By analyzing and modeling all the place names collected in our study, we were able to identify several patterns. In brief, this paper makes the following research contributions:. • By positioning place naming into a hierarchical framework, we identify two major methods that people use to tailor the place names they want to disclose in location sharing, namely choosing a perspective to describe the place (semantic, geographic, or hybrid) and tuning the granularity of disclosure.. • We identify factors that influence the way people refer to a location, including some factors that had not been examined previously, such as a recipient's perceived familiarity with the location (in the sharer's view) and a location's entropy, a measure that estimates how many different people visit that place.. • By applying machine learning to model people's place naming preferences, our approach offers more flexibility and effectiveness in predicting the method and granularity of how people refer to a place, with an average accuracy higher than 85% in our experiments. : The other factor we examined is place entropy. A place with high entropy was visited by more users and is more likely to be a public place, and vice versa. For all the places our participants visited in Pittsburgh, the average entropy value is 2.07 (SD=1.37, max=5.10, min=0.02847). We grouped place entropy into 6 intervals in base two log scale. Surprisingly, we observed a consistent positive correlation between the place entropy and the sharing of geographic information (see Figure 5d) . Also, the granularity keeps on getting finer when the entropy increase. It suggests that people are willing to share more information about their absolute position when they are in public places. It could also indirectly suggest that people have less privacy concerns when they are in public.. All these observations illustrate the dynamics and the complexity of people's place naming preferences. They also give us important clues of how to model users' preferences. Most existing location sharing applications present users' location information on a map. However, sharing location in the form of appropriate place descriptions can provide more meanings and accommodate users' preferences better. We studied the information people want to disclose in location sharing through a two-week-long study with 26 participants. We identified two general ways for manipulating the information shared. We also proposed a hierarchy for how people name places. We examined the impact of different attributes on people's sharing preferences, and found that the recipient's familiarity with the place and the place's entropy can greatly influence how a place is referred to. By applying machine learning techniques, we were able to predict place naming categories with an average accuracy of higher than 85%. Our findings suggest that it might be possible to develop more useful location sharing applications where appropriate place names are automatically (or semi-automatically) modulated. In future work, we plan to explore additional dimensions that might influence place naming, conduct larger scale studies with more diverse sets of participants. Future work will also look at the design, implementation, and evaluation of a location sharing system which presents dynamically generated place descriptions. Little work has been done in generating place descriptions according to different contexts or in statistically modeling people's preferences. However, there are several directions closely related to place naming. We have organized the work into five themes: contextual meaning of places, location sharing applications, place discovery, computing models of places, and grassroots place labeling.

O O B I O O B I O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O B I O O O O O O O O O O O


Formalizing the LLVM intermediate representation for verified program transformations This paper presents Vellvm (verified LLVM), a framework for reasoning about programs expressed in LLVM's intermediate representation and transformations that operate on it. Vellvm provides a mechanized formal semantics of LLVM's intermediate representation, its type system, and properties of its SSA form. The framework is built using the Coq interactive theorem prover. It includes multiple operational semantics and proves relations among them to facilitate different reasoning styles and proof techniques.To validate Vellvm's design, we extract an interpreter from the Coq formal semantics that can execute programs from LLVM test suite and thus be compared against LLVM reference implementations. To demonstrate Vellvm's practicality, we formalize and verify a previously proposed transformation that hardens C programs against spatial memory safety violations. Vellvm's tools allow us to extract a new, verified implementation of the transformation pass that plugs into the real LLVM infrastructure; its performance is competitive with the non-verified, ad-hoc original. Compilers perform their optimizations and transformations over an intermediate representation (IR) that hides details about the target execution platform. Rigorously proving properties about these IR transformations requires that the IR itself have a well-defined formal semantics. Unfortunately, the IRs used in main-stream production compilers generally do not. To address this deficiency, this Figure 1 . The LLVM compiler infrastructure paper formalizes both the static and dynamic semantics of the IR that forms the heart of the LLVM compiler infrastructure.. LLVM [19] (Low-Level Virtual Machine) uses a platformindependent SSA-based IR originally developed as a research tool for studying optimizations and modern compilation techniques [16] . The LLVM project has since blossomed into a robust, industrial-strength, and open-source compilation platform that competes with GCC in terms of compilation speed and performance of the generated code [16] . As a consequence, it has been widely used in both academia and industry.. An LLVM-based compiler is structured as a translation from a high-level source language to the LLVM IR (see Figure 1 ). The LLVM tools provide a suite of IR to IR translations, which provide optimizations, program transformations, and static analyses. The resulting LLVM IR code can then be lowered to a variety of target architectures, including x86, PowerPC, and ARM (either by static compilation or dynamic JIT-compilation). The LLVM project focuses on C and C++ front-ends, but many source languages, including Haskell, Scheme, Scala, Objective C and others have been ported to target the LLVM IR. This paper introduces Vellvm-for verified LLVM-a framework that includes a formal semantics and associated tools for mechanized verification of LLVM IR code, IR to IR transformations, and analyses. The description of this framework in this paper is organized into two parts.. The first part formalizes the LLVM IR. It presents the LLVM syntax and static properties (Section 2), including a variety of well-formedness and structural properties about LLVM's static single assignment (SSA) representation that are useful in proofs about LLVM code and transformation passes. Vellvm's memory model (Section 3) is based on CompCert's [18] , extended to handle LLVM's arbitrary bit-width integers, padding, and alignment issues. In developing the operational semantics (Section 4), a significant challenge is adequately capturing the nondeterminism that arises due to LLVM's explicit undef value and its intentional underspecification of certain erroneous behaviors such as reading from uninitialized memory; this underspecification is needed to justify the correctness of aggressive optimizations. Vellvm therefore implements several related operational semantics, including a nondeterministic semantics and several deterministic refinements to facilitate different proof techniques and reasoning styles.. The second part of the paper focuses on the utility of formalizing the LLVM IR. We describe Vellvm's implementation in Coq [10] and validate its LLVM IR semantics by extracting an executable interpreter and comparing its behavior to that of the LLVM reference interpreter and compiled code (Section 5). The Vellvm framework provides support for moving code between LLVM's IR representation and its Coq representation. This infrastructure, along with Coq's facility for extracting executable code from constructive proofs, enables Vellvm users to manipulate LLVM IR code with high confidence in the results. For example, using this framework, we can extract verified LLVM transformations that plug directly into the LLVM compiler. We demonstrate the effectiveness of this technique by using Vellvm to implement a verified instance of SoftBound [21] , an LLVM-pass that hardens C programs against buffer overflows and other memory safety violations (Section 6).. To summarize, this paper and the Vellvm framework provide:. • A formalization of the LLVM IR, its static semantics, memory model, and several operational semantics; • Metatheoretic results (preservation and progress theorems) relating the static and dynamic semantics; • Coq infrastructure implementing the above, along with tools for interacting with the LLVM compiler; • Validation of the semantics in the form of an extracted LLVM interpreter; and • Demonstration of applying this framework to extract a verified transformation pass for enforcing spatial memory-safety. Although we do not consider it in this paper, our intention is that the Vellvm framework will serve as a first step toward a fullyverified LLVM compiler, similar to that of Leroy et al.'s CompCert [18] . Our Coq development extends some of CompCert's libraries and our LLVM memory model is based on CompCert's memory model. The focus of this paper is the LLVM IR semantics itself, the formalization of which is a necessary step toward a fullyverified LLVM compiler. Because much of the complexity of an LLVM-based compiler lies in the IR to IR transformation passes, formalizing correctness properties at this level stands to yield a significant payoff, as demonstrated by our SoftBound case study, even without fully verifying a compiler. Mechanized language semantics There is a large literature on formalizing language semantics and reasoning about the correctness of language implementations. Prominent examples include: Foundational Proof Carrying Code [2] , Foundational Typed Assembly Language [11] , Standard ML [12, 30] , and (a substantial subset of) Java [15] .. Verified compilers Compiler verification has a considerable history; see the bibliography [18] for a comprehensive overview. Other research has also used Coq for compiler verification tasks, including much recent work on compiling functional source languages to assembly [5, 8, 9] .. Vellvm is closer in spirit to CompCert [18] , which was the first fully-verified compiler to generate compact and efficient assembly code for a large fragment of the C language. CompCert also uses Coq. It formalizes the operational semantics of CompCert C, several intermediate languages used in the compilation, and assembly languages including PowerPC, ARM and x86. The latest version of CompCert also provides an executable reference interpreter for the semantics of CompCert C. Based on the formalized semantics, the CompCert project fully proves that all compiler phases produce programs that preserve the semantics of the original program. Optimization passes include local value numbering, constant propagation, coalescing graph coloring register allocation [6] , and other back-end transformations. CompCert has also certified some advanced compiler optimizations [32] [33] [34] using translation validation [22, 26] . The XCERT project [29, 31] Other mechanization efforts The verified software tool-chain project [3] assures that the machine-checked proofs claimed at the top of the tool-chain hold in the machine language program. Typed assembly languages [7] provide a platform for proving back-end optimizations. Similarly, The Verisoft project [1] also attempts to mathematically prove the correct functionality of systems in automotive engineering and security technology. ARMor [37] guarantees control flow integrity for application code running on embedded processors. The Rhodium project [17] uses a domain specific language to express optimizations via local rewrite rules and provides a soundness checker for optimizations. Validating LLVM optimizations The CoVac project [36] develops a methodology that adapts existing program analysis techniques to the setting of translation validation, and reports on a prototype tool that applies their methodology to verification of the LLVM compiler. The LLVM-MD project [35] validates LLVM optimizations by symbolic evaluation. The Peggy tool performs translation validation for the LLVM compiler using a technique called equality saturation [28] . These applications are not fully certified.

O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O


Committees Of Learning Agents We describe how machine learning and decision theory is combined in an application that supports control room operators of a combined heating and power plant to cope with the overwhelming complexity of situations when severe plant disturbancies occur. The application is designed as an assistant, rather than as an automatic system that intervenes directly in the operator/plant loop. The application is required to handle vague and numerically imprecise background information in the construction of classifier committees. A classifier committee (or ensemble) is a classifier created by combining the predictions of multiple sub-classifiers. The presented method combines classifiers into a committee by using computational methods for decision analysis that are designed to work when the information at hand is imprecise. The application evaluates and make priorities between classified alarms according to credibilities that depend on the current context. Machine learning techniques are used to construct classifiers that recognize various malfunctions in a process, determine whether a situation is normal or not, and make priorities among alarms. The modern society has become more and more dependent on complex systems for control and support of basic services like heating, electricity, and water. While most such operations are, under normal circumstances, well goverened by algorithms from control theory, unexpected situations are often not handled with the desired precision. This paper describes an application dealing with the handling of unexpected events in a combined heat and power plant in a major populated area in Sweden. The plant has a capacity of 135 MW electricity and 230 MW heat and supplies a major part of the surrounding urban area with approximately 28000 GWh of heat and 500 GWh of electricity annualy.. 1 Several unscheduled halts during an operational season were due to the personnel not being able to interpret and handle incoming information caused by some malfunctioning sub-system. The cost of a halt exceeds $ 15,000 per hour. If the halt extends over a longer period, it 1 might become critical to the service level of the city. Thus, it was found to be an important task to try and minimise the unscheduled plant halts by developing an application with the ability to recognise and evaluate severe problems as they arise in run-time. No single computer science technique seemed appropriate, which led to the current design involving machine learning and computational decision theory.. We describe how machine learning techniques where combined with decision theory to handle vague and numerically imprecise background information in the construction of classifier committees. We present how the predictions of several sub-classifiers were combined into a committe. This was guided by a measure of confidence in each sub-classifier that was expressed as an interval. The reason for expressing the confidence measure as an interval rather than a point-value is to increase the robustness of the committee. The resulting committee then evaluated the combined predictions of the sub-classifiers and decided on response to the current situation with respect to a set of available actions.. Process control in today's power plants is most often handled by a computer system, which ensures that the processes are kept within given limits and that the entities in a process (pumps, engines, valves etc.) are stable w.r.t. parameters and directions given by operators or by the control system itself. When deviations from a normal situation occur, the control system sends alarm messages to the operators, who pursue the necessary actions based on given recommendations or their own experience. When large deviations occur, the safety routines in the control system might stop some or all of the subsystems of the process.. In normal run-time situations, the level of communication between the control system and the operators is satisfactory, with few alarms occurring infrequently. However, when a large disturbance occurs, the communication is far from satisfactory. For example, after a short power failure, the control system may stop pumps and sub-processes or the position of rolls may change. In such situations, the safety routines normally start to interfere, and a huge stream of alarm messages will follow. Instead of being helped by the messages, the operators become swamped by the information flow, and they often have to make more or less informed guesses of what causes the abnormal situation. Furthermore, such decisions have to be made under severe time pressure. Large monetary values are at stake, both if the plant is unnecessarily shut down and if it is left running resulting in severe damage to the equipment. It would therefore be of great help to the operators if an amended control system could discriminate between normal and abnormal situations. In the former case, the system would act in one mode, resulting in few alarms being sent every now and then, while in the latter case, the system would recognize, evaluate, and give priority to some alarms that are sent to the operators.. Consider a scenario where a control room operator is in charge of running a highly complex process. The control system is partly based on a rule-based alarm system. When alarms occur, the operator (which might be a human or a software component) needs to respond, either by ignoring the alarm or by some action based on the current state of the process. More formally, the operator faces a situation involving a choice between a finite set of strategies (e.g. actions) having access to a finite set of triggered alarms.. In a situation involving committees of classifiers, modelled as in Section 4, several kinds of data are present. Given a set of alarms, these are interpreted by the classifiers who provide probabilities for the possible causes of the alarms. Some of the classifiers may also be more reliable than others in a certain context. Furthermore, the operator may have access to assessments expressing the costs of the various causes depending of which actions could be performed.. The operator is determined to select strategies from this information. However, for the operator to carry out his tasks and to acquire sufficient and reliable knowledge, it is fundamental that he is able to evaluate information gathered from different classifiers, some of which might be quite unreliable. The dynamic adaptation taking place over time as the operators interact with their environment, and with the classifiers, is affected by the means available to assess and evaluate imprecise information. We will now consider this problem in some more detail.. In the remainder of the article we will first, in Section 2, give a brief introduction to classifier committees. In section 3, we describe how classifiers are constructed while in Section 4, we describe how the classifiers are combined based on a measure of confidence in each classifier, and finally in Section 5, we will present some concluding remarks. We have shown in an application how a set of vague and numerically imprecise information can be used to evaluate potentially critical situations arising in complex alarm systems by using a set of classifiers. The classifiers are trained using machine learning techniques and their relative performances are measured in relevant contexts, resulting in a weight ranking. The application considers the problem with respect to the different classifiers as well as the analysis of the different situations involved. These aspects are modelled into information frames consisting of systems of linear expressions stating inequalities and interval assessments. The situations may be evaluated relative to a variety of principles, for example generalizations of the principle of maximizing the expected utility. Contractions are introduced as an automated sensitivity analysis. This concept allows us to investigate critical variables and the stability of the solutions. Although this systems was originally designed to be used at a combined heating and power plant, the results from this application will be applied to a similar case in the paper and pulp industry in order to further develop and generalise the methods and demonstrate their more general applicability.

B O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O B I O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


An integrated hardware-software approach to flexible transactional memory There has been considerable recent interest in both hardware and software transactional memory (TM) We have described a transactional memory system, RTM, that uses a pair of hardware mechanisms to accelerate software transactions: alert-on-update (AOU) provides fast event-based communication for conflict detection; programmable data isolation (PDI) allows a processor to hide speculative writes from other processors and to continue to use speculatively read and written lines despite potentially conflicting writes on other processors.. RTM's fast-path (fully hardware-supported) transactions require cache space only for speculative writes; lines that have only been read can safely be evicted, as can nontransactional data. Transactions that nonetheless overflow hardware resources fall back gracefully to software, and interoperate smoothly with fast-path transactions. All transactions employ a software contention manager, enabling the use of adaptive or application-specific policies.. Our results show that RTM outperforms RSTM by an average of 3.5× on a single thread and 2× on 16 threads. The simpler RTM-Lite system, which relies on AOU but not PDI, is effective at eliminating validation overhead, but loses to RTM for transactions that modify large objects. Echoing the findings of previous software TM studies, we find significant performance differences between eager and lazy conflict detection, with neither outperforming the other in all cases; this supports the need for policy flexibility.. In future work, we plan to explore a variety of topics, including performance sensitivity to processor organization parameters; simplified protocols (without transactional loads); implementations for other coherence protocols (e.g., MOESI or directory-based); additional hardware assists; nested transactions; gradual fall-back to software, with ongoing use of whatever fits in cache; other styles of RTM software (e.g., word-based, blocking, and/or indirectionfree); context identifiers for transactions implemented at a shared level of cache; and more realistic applications.

O O O O O O B I O O O O O O O O B O B B I O O O O O B I O O O O O O O B O O O B O O O O O O O O B B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O B O O O O O B O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O B B O O O O O O O O O O O O O B B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B


Game matching number of graphs We study a competitive optimization version of α ′ The archetypal question in extremal graph theory is "how many edges can an n-vertex graph contain without containing a copy of a forbidden subgraph F ?" The answer is the extremal number of F , denoted ex(F ; n). The celebrated theorem of Turán [17] gives a formula for ex(K r ; n) and characterizes the largest graphs not containing K r .. A graph H is F -saturated if F ⊆ H, but F ⊆ H + e whenever e ∈ E(H). Thus the extremal number ex(F ; n) is the maximum size of an F -saturated n-vertex graph. The saturation number of F , denoted sat(F ; n), is the minimum size of an F -saturated n-vertex graph. Erdős, Hajnal, and Moon [5] initiated the study of graph saturation, determining sat(K r ; n).. More generally, for fixed graphs F and G, a subgraph H of G is F -saturated relative to G if F ⊆ H, but F ⊆ H + e whenever e ∈ E(G) − E(H). When edges are successively added to H to reach a subgraph that is F -saturated relative to G, the final number of edges is between the minimum and maximum sizes of such subgraphs. When the edges are chosen by two players with opposing objectives, we obtain a natural game. Definition 1.1. The F -saturation game on a graph G is played by two players, Max and Min. The players jointly construct a subgraph H of G by alternately adding edges of G to H without completing a copy of F . The game ends when H is F -saturated relative to G. Max aims to maximize the length of the game, while Min aims to minimize it. The game F -saturation number of G is the length of the game under optimal play, denoted by sat g (F, G) when Max starts and by sat g (F, G) when Min starts.. The saturation game bears similarities to other games. In a Maker-Breaker game, the players choose edges of a graph G in turn. Maker wins by claiming the edges in a subgraph having a desired property P; Breaker wins by preventing this. For example, Hefetz, Krivelevich, Stojaković, and Szabó [9] studied Maker-Breaker games on K n in which Maker seeks to build non-planar graphs, non-k-colorable graphs, or K t -minors.. In a Maker-Breaker game, one may ask how quickly Maker can win. Breaker then acts like Max in the saturation game, aiming to prolong the game. Hefetz, Krivelevich, Stojaković, and Szabó [10] showed that on K n , Maker can build a spanning cycle within n + 2 turns and can build a k-connected subgraph within (1 + o(1))kn/2 turns. Feldheim and Krivelevich [6] showed that Maker can build a given d-degenerate p-vertex graph within d 11 2 2d+7 p moves (when n is large relative to d and p).. Saturation games were introduced by Füredi, Reimer, and Seress [7] ; they studied the value sat g (K 3 , K n ) as "a variant of Hajnal's triangle-free game". (In Hajnal's original "triangle-free game", the players try to avoid triangles, with the loser being the player forced to create one; see [4, 8, 12, 13, 15, 16] .) Since the F -saturation game always produces an F -saturated graph, trivially n − 1 = sat(K 3 ; n) ≤ sat g (K 3 , K n ) ≤ ex(K 3 ; n) = ⌊n 2 /4⌋. The lower bound on sat g (K 3 , K n ) from [7] is Ω(n lg n). An unpublished result of Erdős states n 2 /5 as an upper bound. Biró, Horn, and Wildstrom [2] improved the leading coefficient in the upper bound, but the correct order of growth remains unknown.. In this paper, we study the P 3 -saturation game. The P 3 -saturated subgraphs of G are the maximal matchings in G, so we call sat g (P 3 , G) the game matching number of G. With α ′ (G) denoting the maximum size of a matching in G (the matching number), we let α. denote the sizes of the matchings produced under optimal play in the Max-start game (where Max plays first) and in the Min-start game (where Min plays first), respectively.. The outcome of an F -saturation game may depend heavily on which player starts. For example, if G arises from K 1,k by subdividing one edge, then sat g (G, 2K 2 ) = k, but sat g (G, 2K 2 ) = 2. The special case of game matching (F = P 3 ) is much better behaved; the main result of Section 2 states that always α. Section 3 examines the relationship between α ′ g (G) and α ′ (G). We obtain a sufficient condition for α ′ g (G) = α ′ (G); it is somewhat technical but is preserved by taking the cartesian product with any other graph. We also prove α. This inequality is sharp; equality holds for many split graphs (a graph is a split graph if its vertex set can be partitioned into a clique and an independent set). We also show that the maximum number of edges in an n-vertex graph such that α ′ (G) = 3k and α ′ g (G) = 2k is 3k 2 + 3k(n − 3k) when n ≥ 6k. Finally, we prove the general upper boundα. µ(G), where µ(G) is the minimum size of a maximal matching in G.. In Section 4, we restrict our attention to forests, where the lower bound in terms of α. , which is sharp (equality holds for the "comb" obtained by adding a pendant edge at each vertex of the path P 4k ). We also prove thatα. when F is a forest, which means that there is no advantage in starting second or skipping a turn. A closely related result is that adding a star component to a forest increases both parameters by 1.. Finally, in Section 5 we consider graphs with small maximum degree. We show that optimal play on the n-vertex path P n produces a maximal matching of size differing from n/7 by less than 3. Note also that the outcome on C n is greater by 1 than the outcome on P n−2 with the other player starting. For a connected 3-regular n-vertex graph G, we prove that always α ′ g (G) ≥ n/3, and we construct such graphs with α ′ g (G) < 7n/18. There are disconnected 3-regular graphs with α. 2 Max-start vs. Min-start Our primary goal in this section is to determine the positive integer pairs (r, s) that are realizable as (α. ) for some graph G. We show first that all pairs with |r − s| ≤ 1 are realizable (except (1, 2) ). The main result is then that these are the only such pairs; in other words, the choice of the starting player makes little difference. As part of the proof, we will show also that vertex deletion cannot increase α ′ g orα ′ g . We state explicitly the special case for game matching of the trivial upper and lower bounds for game saturation:. are bounded above by α ′ (G) and bounded below by µ(G), the minimum size of a maximal matching in G. 2) ), and G may be required to be connected.. Proof. If Min cannot move without leaving another move, then the same is true for a first move by Max, so (1, 2) is not realizable. The complete graph K 2r realizes (r, r). To realize (r, r − 1), add a pendant vertex to K 2r−1 .. To realize (r, r + 1), we present a graph G and give strategies for the second player to ensure α. . These values are optimal, because in each case we will have α. To realize (2k, 2k + 1), take K 4k+2 and discard a perfect matching. When k = 1, the graph after the first move is always K 1,1,2 ; Min moving next can prevent a third move, while Max moving next can guarantee a third move. For k ≥ 2, any move by the first player joins endpoints of two deleted edges, and the second player can play the edge joining the other two endpoints of those edges to reach the same situation in a smaller graph.. To realize (2k−1, 2k) for k ≥ 2, take 2K 2k , delete one edge from each component, creating four special vertices, and restore regularity by adding a different pair of edges on the special vertices. If Min makes a first move involving a special vertex, then Max can move to leave 2K 2k−2 . If Max makes a first move involving a special vertex, then Min can move to leave K 2k−3 + K 2k−1 (we use "+" to denote disjoint union). A first move not involving a special vertex can be mirrored on the vertices of the other large clique to reach the same situation in a smaller graph, except that when k = 2 such a first move by Max can be answered by Min to leave. cannot occur when G is a forest; we prove this in Section 4. Meanwhile, we begin the proof of the general bounds |α. with a simple observation that will also be useful in other contexts. Proof. The right side of each claimed inequality is the result under optimal play after uv is played as the first move. The first player does at least as well as this, with equality (by definition) if and only if uv is an optimal first move.. We facilitate the inductive proof of |α. | ≤ 1 by proving simultaneously that both game matching numbers are monotone under the deletion of vertices.

O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


The role of spreadsheet knowledge in user-developed application success shown to be important in two ways. It influences the quality of the system being developed, but it also acts directly upon the individual impact of the application. Successful use appears to require sufficient knowledge to understand and, if necessary, alter the application. An end user developer is someone who develops applications to support his or her work or the work of other end users. The applications developed are known as user-developed applications (UDAs). End user development of applications forms a significant part of organizational systems development, with the ability to develop small applications forming part of the job requirements for many positions [24] . Spreadsheets are the most commonly used tool for end user development of applications [55] and organizations depend heavily upon spreadsheet applications for both processing and decision making.. Spreadsheet applications are used for a wide variety of organizational tasks. In a survey to determine the types of applications developed by end users, Rittenberg, Senn, and Bariff [41] identified over 130 different types of applications and the majority of these were developed using spreadsheets. Many of these were accounting related but marketing, operations and human resources applications were also heavily represented. The accounting applications most frequently implemented were budget analysis, financial analysis, financial performance forecasting, and 'what-if' analysis. Early studies tended to find that UDAs were typically used for queries, reports and simple analyses (e.g., [42] and [45] ). However, the range of tasks has expanded as the sophistication of both software development tools and user developers has increased. This has led to a degree of convergence with corporate computing, so that the tasks for which UDAs are developed are less distinguishable from tasks for corporate computing applications [34] .. Despite their importance, organizations tend to have little formal evaluation of UDAs and rely heavily on end users' evaluations of system quality and fitness for use [37] . This reliance assumes that end user developers are sufficiently knowledgeable to develop accurate and reliable applications, and that the users of these applications-who are not necessarily the same people as the users who developed them-are sufficiently knowledgeable to use them successfully. This paper reports on a study to investigate the role of spreadsheet knowledge in the successful use of spreadsheet applications. It considers both the spreadsheet knowledge of the user developer and the spreadsheet knowledge of the user and tests a model of the effect of spreadsheet knowledge on the success of a user-developed spreadsheet application. The model of the relationship between spreadsheet knowledge and success which emerges from this study has helped to provide insight into the importance of spreadsheet knowledge for successful use of a spreadsheet application. As Fig. 3 shows, it enables analysis of the different ways in which user developer knowledge and user knowledge affect the success of a spreadsheet application.. In this study, spreadsheet knowledge was shown to be important in two ways. It influences the quality of the system being developed, but it also acts directly upon the individual impact of the application. While users of enterprise systems do not require knowledge of the tools with which systems are developed, successful use of user-developed spreadsheet applications appears to require sufficient knowledge to understand and, if necessary, alter the application.. Thus, problems with the system quality of spreadsheet applications can be partially balanced by the spreadsheet knowledge of the user. This relationship between tool knowledge and individual impact should be explored for other kinds of end user development tools in future research. In the study described here, the success of the spreadsheet application was affected by spreadsheet knowledge. Both of the propositions about the effect of spreadsheet knowledge were supported: the success of the spreadsheet application reflected both the spreadsheet knowledge of the user developer and the spreadsheet knowledge of the user (who was not the developer).. This research further demonstrates that the ways in which each actor's spreadsheet knowledge affects success vary. The spreadsheet knowledge of a spreadsheet developer influences all of the measured indicators of spreadsheet application success by influencing system quality from which users' perceptions of system quality and user satisfaction arise. The overall effect of developer spreadsheet knowledge on the individual impact of spreadsheet use is, however, low. On the other hand, user spreadsheet knowledge is not associated with perceived system quality or user satisfaction. Instead, it has a direct effect on the individual impact of spreadsheet use, an effect independent of, and of a similar magnitude to user satisfaction.. This overview leads to several considerations about the relationships observed in this research. The results of the analysis are summarized in Table 2 and Table 3 and illustrated graphically in Fig. 2 . The goodness of fit measures included in Table 2 indicate a good fit between model and data on all the measured criteria: χ 2 is non-significant, χ 2 /df is less than 3:1, GFI and TLI are greater than 0.9, AGFI is greater than 0.8, and RMSEA is less than 0.05. The model explained a satisfactory proportion of the variance in spreadsheet application success. The R 2 values reported in Fig. 2 show that it explained 23.1% of the variability in system quality, 39.6% of the variability in perceived system quality, 55.3% of the variability in user satisfaction, and 34.0% of the variability in individual impact.. The path coefficients for the model are reported as raw estimates with t values in Table 2 and as standardized estimates in Fig. 2 . While five of the seven hypothesized direct relationships were supported, two-the relationship between user spreadsheet knowledge and perceived system quality, and the direct relationship between system quality and individual impactwere not. Thus, the model was partially supported. The implications of these results for the individual hypotheses are:. • H1 is supported: The system quality of a UDA increases as the end user developer's level of spreadsheet knowledge increases.. • H2 is supported: Perceived system quality increases as system quality increases.. • H3 is not supported: Perceived system quality is not related to the end user's level of spreadsheet knowledge.. • H4 is supported: User satisfaction reflects perceived system quality.. • H5 is supported: Individual impact reflects user satisfaction.. • H6 is supported, but not in the form drawn in the structural model. While individual impact does reflect system quality, its effect is indirect, being mediated by perceived system quality and user satisfaction.. • H7 is supported: Individual impact reflects the level of spreadsheet knowledge of the application user.. In conjunction with Fig. 2 , Table 3 allows us to compare the ways in which user developer spreadsheet knowledge and (non-developer) user spreadsheet knowledge affect spreadsheet application success:. • User developer spreadsheet knowledge affects system quality, and consequently, user perceptions of system quality and user satisfaction with use. Through user satisfaction, it has a weak effect on the individual impact of spreadsheet use.. • Non-developer user spreadsheet knowledge does not affect perceptions of system quality or user satisfaction, but has a relatively strong effect on individual impact.. From Fig. 2 and Table 3 , we can see that the total effect of developer spreadsheet knowledge on individual impact for the user is much lower than the effect of the user's own spreadsheet knowledge. We can also see that the effects of user spreadsheet knowledge and user satisfaction on individual impact are independent of one another, and of about equal weight. This research addresses two principle propositions, based on the two sources of knowledge needed for successful use of a user-developed spreadsheet application: the spreadsheet knowledge of the user developer and the spreadsheet knowledge of the developer:. (a) The spreadsheet knowledge of the user developer affects the success of the spreadsheet application.. (b) The spreadsheet knowledge of the user affects the success of the spreadsheet application.. In this section, we consider the nature of spreadsheet application success and the chain of effects that may mediate the relationship between knowledge and success before proposing a set of hypotheses and a model that enable us to examine the proposed relationship between spreadsheet knowledge and success. Edberg and Bowman [16] noted that there has been little direct empirical examination of the effectiveness of end users as application developers. Similarly, Shayo et al. [54] (p. 8) noted that 'while research continues to grow on IS success, it remains scanty on measurement of end user success'. They attributed this lack of research to the fact that UDAs are rarely tracked formally by organizations and that users may be reluctant to allow measurement of the efficiency or effectiveness of their applications. They suggested that the most commonly used measure of success, user satisfaction, is less threatening and easier to obtain than independent measures. However, this may be problematic because users are asked to place a value on something about which they may not be objective [32] .

O O O B I O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O B I O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O B I I O O O O O O O O O O O O O O O O O O B I O O O O O O O O B I O O O O O O O O O O O B I O O O O O O B I O O O O O O O O O O O O O O O O O O O B I O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O B I O O O B I O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O B I O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O B I O O O O O B I O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Autonomic load-testing framework In this paper, we present a method for performance testing of transactional systems. The methods models the system under test, finds the software and hardware bottlenecks and generate the workloads that saturate them. The framework is autonomic, the model and workloads are determined during the performance test execution by measuring the system performance, fitting a performance model and by analytically computing the number and mix of users that will saturate the bottlenecks.We model the software system using a two-layer queuing model and use analytical techniques to find the workload mixes that change the bottlenecks in the system. Those workload mixes become stress vectors and initial starting points for the stress test cases. The rest of test cases are generated based on a feedback loop that drives the software system towards the worst case behaviour. Performance testing is fundamental in assessing the performance of software components as well as of an entire software system. A major goal of performance testing is to uncover functional and performance problems under load and the root cause of those problems. Functional problems are often bugs, deadlocks and memory management bugs, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICAC '11, June 14-18, 2011 , Karlsruhe, Germany. Copyright 2011 ACM 978-1-4503-0607-2/11/06 ...$10.00. buffer overflows. Performance problems often refer to high response time or low throughput under load.. In practice, the testing is done under operational conditions, that is, the testing is typically based on the expected usage of the system once is deployed and on the expected workload. The workload consists of the types of usage scenarios and the rate of these scenarios. A performance test usually lasts for several hours or even a few days and only tests a limited number of workloads. The major drawback of this approach is that expected usage and scenario rates are hard to predict. As a result, many workloads that the system will face remain uncovered by the stress test.. In this paper we propose an autonomic framework that explores the workload space and searches for points in this space that cause the worst case behaviour for software and hardware components of the system. It is generally known that the performance of a software system is influenced by the hardware and software bottlenecks. Bottlenecks are those resources where the requests are queued and delayed because the processing capacity limits of that resource. When those limits are reached, we say that the bottlenecks are saturated. Consider for example a web based application in which a web server has 100 threads available. When there are more than 100 pending requests, the server is a saturated bottleneck because it has reached its capacity. If the requests keep coming, they will be buffered in a waiting queue that will eventually reach its limits as well. In a software system, there are many bottlenecks and, more importantly, those bottlenecks change as the workload changes.. Finding the workloads that cause the bottlenecks to change is a challenging but rewarding problem. We propose an autonomic load stress testing framework that drives the workloads towards the points that create the bottlenecks and eventually saturate them. We also show that the software performance metrics reach their maximum or minimum for those workloads that cause some bottlenecks to reach their capacity or policy limits. The method uses an analytical representation of the software system, a two-layer queuing model that captures the hardware and software contention for resources. The model is automatically tuned, using online estimators that find the model parameters. The overall testing method is autonomic, based on a feedback loop that generates workloads according to the outputs of the model, monitors the software system under test, extract metrics, analyzes the effects of each workload and plans the new workloads based on the results of the analysis.. The type of software systems that would benefit the most from the proposed method are web based transactional sys- tems. To model the interaction of users with such systems, we define classes of services, or classes in short. A class is a service or a group of services that have similar statistical behavior and have similar requirements. When a user begins interacting with a service, a user session is created. The session will be maintained active until the user logs out or when he is inactive for a specified period of time. If we define N as the number of active users at some moment t, these users can use different classes of services. If we have C classes and Nc is the number of users in class C, then N = N1 + N2 + · · · + NC . N is also called workload intensity or population while combinations of Nc are called workload mixes or population mixes.. The remainder of the paper is organized as follows. Section 2 presents the theoretical foundations of the testing method. Section 3 describes the general testing framework and introduces the testing algorithm. A case study is presented in Section 4 and related work is described in Section 5. Conclusions and further work are presented in Section 6. This paper presented an autonomic performance testing method for stress testing web software systems. The systems are modeled with a two-layer Queuing Network Model. The model is used to find the software and hardware bottlenecks in the system and to give a hint about workloads that will saturate them. These hints are used as initial workloads on the real system and then in a feedback loop that guides the system towards a stress goal.. The workloads are characterized by workload intensity, which is the total number of users, and by the workload mix, which is ratio of users in each class of service. By extracting the switching points from the model, we are able to compute the stress vectors that yield a bottleneck change. Applying a hill-climbing strategy for workload intensity along the stress vectors, we are able to reach the stress goal.. We applied the method to find the workload intensity and workload mix that yields target software and hardware utilization limits or a target response time. The results show that the algorithm is capable to reach the target goal with a small number of iterations and therefore testcases.. Future work includes extending the framework to include more target goals, validate it on large scale software systems and address functional problems uncovered by stress testing. Once we decided the number of classes of services, we run the testing algorithm. At the first step it estimates the demands for each class of service using the Model Tuning Algorithm ( Table 2 shows the values found when the model is calibrated for CPU utilization). We run the framework for 3 stress goals: (a) hardware utilization, (b) web container number threads and (c) response time for each scenario. Transactional systems in the context of autonomic computing have been modeled by several authors as regression models or Queuing Network Models (QNM). Dynamic regression models have been described in [10, 21] . Queuing Network Models were described in [26] as predictive models.. Early work in finding bounds on response time and throughput for one dimension of the workloads (one class) was done in [35, 5, 16, 29] . In [2] the authors showed that in multiple workload mixes, multiple resources systems, changes in workload mixes can change the system bottleneck; the points in the workload mix space where the bottlenecks change are called crossover points, and the sub-spaces for which the set of bottlenecks does not change are called saturation sectors. The same authors, in the same paper, showed analytical relations between the workload mixes and utilization at the saturated bottlenecks as well as analytical expressions for asymptotic (with saturated resources) response times, throughput, and utilization within the saturation sectors. The results were presented for one queuing network layer consisting of hardware resources. In this paper, we considered two layers with the emphasis on the software layer. Moreover, our approach is defined in the context or performance testing.. The paper [19] extended the results from [2] to non-asymptotic conditions (non-saturated resources), and used linear and non-linear programming methods for finding maximum object utilization across all workload mixes. That technique involved only the hardware bottlenecks. In our current approach, we consider the software bottlenecks and we combine the model search for worst case behaviour with a search on the real system. There is no fully automatic method for building the structure of a performance model, however, there are available tools that can help in building a structure of the performance model [1] . Recent papers, like [20, 34, 36] , have shown how to build a tracking filter and a predictive QNM such that the model's outputs always match those of the real system. Performance parameters like the service time, think times, and the number of users can be accurately tracked and fed into a QNM. In our approach, we estimate the demands on the hardware layer using a method similar to [36] To the best of our knowledge, there is no performance model driven testing approach similar the one presented in this paper. Although there are many model driven performance activities, they do not refer to testing. Many researchers have targeted capacity planning of distributed and client-server software systems and specially the web based ones [24, 4, 25] . Amongst those, many approaches have used the widely recognized queuing models to model web applications at operational equilibrium [24, 25, 9] which has resulted in automated building of measurement based performance models [33, 8] or capacity calculators [32] . Others have tried to model the effect of application and server tuning parameters on performance using statistical inference, hypothesis testing and ranking (e.g. [11, 31] ). In a rather different approach some have tried to automate the detection of potential performance regressions, by applying statistics on regression testing repositories [6, 12, 13] . This had enabled developers to identify subsystems that show performance deviations in load tests [22] .. All these approaches have contributed to designing scalable systems, building on-demand performance management systems [17, 27, 15] and performance aware software systems [28] .. In this paper our focus was on model driven testing and on finding a method that drives the system towards a target state where performance metrics of interests can be collected. The model is fundamental in analysing the feasible stress space and in driving the system towards the saturation points. We tested our framework on a a web application deployed over cluster with three Windows XP machines: one Database Server (MySQL) and two Web Servers (Tomcat). Also we had on a machine a Workload Balancer (Apache) to distribute the incoming web requests to the two web servers. Figure 5 shows our deployed testing framework that is a materialization of the logical structure presented earlier in Figure 4 .. On each machine we had installed monitoring tools to be able to measure the performance metrics: Windows XP SNMP agents, JMX and Windows Performance Counters. The workload generator and the analysis of the performance data was on a separate machine. On the cluster we have installed a typical 3-tier applicationan online store-with 3 main scenarios:. • browse -the user is browsing through the available items in the store. Also the user will be able to specify how many items he wants to have in a single page (which is a parameter for the scenario); • buy -the user decides to buy some items and add them in the shopping cart; • pay -the user goes to checkout and pays for the content of the shopping cart;. The two-layer model of the application is the one represented in Figure 1 , earlier in the paper. At the software layer, we have the two software queuing centres, the Web Servers and the Database. The load balancer is not represented in this particular example as a queuing centre because it is performant enough not to queue requests (however, in a general case it should be represented). Therefore, L = W eb, Data .. The hardware layer is made of two queuing centres K = CP U web , CP U data . The application was modeled with Apera tool [1] , developed by one of the authors.. Initially, we have 3 classes of requests, represented by the 3 scenarios, C = {browse, buy, pay}.

O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Practical aggregation of semantical program properties for machine learning based optimization Iterative search combined with machine learning is a promising approach to design optimizing compilers harnessing the complexity of modern computing systems. While traversing a program optimization space, we collect characteristic feature vectors of the program, and use them to discover correlations across programs, target architectures, data sets, and performance. Predictive models can be derived from such correlations, effectively hiding the time-consuming feedback-directed optimization process from the application programmer.One key task of this approach, naturally assigned to compiler experts, is to design relevant features and implement scalable feature extractors, including statistical models that filter the most relevant information from millions of lines of code. This new task turns out to be a very challenging and tedious one from a compiler construction perspective. So far, only a limited set of ad-hoc, largely syntactical features have been devised. Yet machine learning is only able to discover correlations from information it is fed with: it is critical to select topical program features for a given optimization problem in order for this approach to succeed.We propose a general method for systematically generating numerical features from a program. This method puts no restrictions on how to logically and algebraically aggregate semantical properties into numerical features. We illustrate our method on the difficult problem of selecting the best possible combination of 88 available optimizations in GCC. We achieve 74% of the potential speedup obtained through iterative compilation on a wide range of benchmarks and four different general-purpose and embedded architectures. Our work is particularly relevant to embedded system designers willing to quickly adapt the optimization heuristics of a mainstream compiler to their custom ISA, microarchitecture, benchmark suite and workload. Our method has been integrated with the publicly released MILEPOST GCC [14] . Though the combination of iterative compilation and machine learning has been studied for more than a decade and showed great potential for program optimizations, there are surprisingly few research results on the problem of selecting good quality program features. This problem is relevant for effective optimization knowledge reuse, to speedup the search for good optimizations, to build predictive models for compilation heuristics, to select optimization passes and ordering, to build and tune analytical performance models, and more.. Up to now, compiler experts had to manually construct and implement feature extractors that best suit their purpose. Without a systematic way to construct features and evaluate their merits, this task remains a tedious trial and error process relying on what the experts believe they understand about the impact of optimization passes. In a modern compiler like GCC, more than 200 passes compete in a dreadful interplay of tradeoffs and assumptions about the program and the target architecture (itself very complex and rather unpredictable). The global impact of these heuristics can be very far from optimal, even on a major compiler target such as the x86 ISA and its most popular microarchitectural instances. But what about embedded targets which attract less attention from expert developers and cannot afford large in-house compiler groups? What about design-space exploration of the ISA, microarchitecture and compiler?. So far, a limited set of largely syntactical features have been devised to prove that optimization knowledge can be reused and derived automatically from feedback-directed optimization. However, machine learning is only able to recover correlations (hence optimization knowledge) from the information it is fed with: it is critical to select topical program features for a given optimization problem. To our knowledge, this is the first attempt to propose a practical and general method for systematically generating numerical features from a program, and to implement it in a production compiler. This method does not put any restriction on how to logically and algebraically aggregate semantical properties into numerical features, offering a virtually exhaustive coverage of statistically relevant information that can be derived from a program.. This method has been implemented in GCC and applied to a number of general-purpose and embedded benchmarks. We illustrate our method on the difficult problem of selecting the optimal setting of compiler optimizations for improving the performance of an application, and demonstrate its practicality achieving 74% of the available speedup obtained through iterative compilation on a wide range of benchmarks and 4 different general-purpose and embedded architectures. We believe this work is an important step towards generalizing machine learning techniques to tackle the complexity of present and future computing systems. Feature extractor presented in this paper is now available for download within MILE-POST GCC at [14] while experimental data is available at [9] to help researchers reproduce and extend this work. In our work we attempt to overcome two major methodological flaws that limit the dissemination of current and past research on iterative compilation and machine learning compilation, namely:. • the use of proprietary, unreleased or outdated transformation, compilation and feature extraction tools;. • the very limited set of optimizations and features, making it difficult or even impossible to replicate and improve upon previous results.. In an attempt to curb these tendencies, we decided to implement our feature extractor inside the popular, free software, productionquality GCC compiler [13] . Recent versions of GCC achieve performance levels competitive with the best commercial and research compilers. GCC also supports a large number of platforms, a large and fast-growing number of optimizations, and modern intermediate representations facilitating the extraction of semantically rich properties and features. It is a unique tool available for research purposes in compilation of real-world applications. Based on the techniques described in the previous section, we implemented our feature extractor as additional passes in GCC 4.2-4.4 versions [14] . It is invoked on demand after the compiler generates the data needed for producing features. The feature extractor works in two stages:. • extracting a relational representation of the program;. • computing a feature vector based on this representation.

B O O O B O O B I O O O B O O B I O O O O O B O O O O B O O O B O O O B I B O B O B O O O B O B O O O O O O O O B O O B O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B I O O O O O O O O O O O O O O O O B O B O O O O O O O B O O O O O O O B B O O O O O O O B O B O O O O O O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O B O B B O O B O B O O O O O O O O O O O O O O O O B O B I O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O B O B O O O O O O O O B B O B O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O B O B B O O O O O O O B O O O O O O O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O B O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O B O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B O O O O O B B O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O B I B O O O B O O O O O O B O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O B O O O B O O O O O