Improving SDRAM access energy efficiency for low-power embedded systems DRAM (dynamic random-access memory) energy consumption in low-power embedded systems can be very high, exceeding that of the data cache or even that of the processor. This paper presents and evaluates a scheme for reducing the energy consumption of SDRAM (synchronous DRAM) memory access by a combination of techniques that take advantage of SDRAM energy efficiencies in bank and row access. This is achieved by using small, cachelike structures in the memory controller to prefetch an additional cache block(s) on SDRAM reads and to combine block writes to the same SDRAM row. The results quantify the SDRAM energy consumption of MiBench applications and demonstrate significant savings in SDRAM energy consumption, 23%, on average, and reduction in the energy-delay product, 44%, on average. The approach also improves performance: the CPI is reduced by 26%, on average. Many embedded applications are memory intensive, especially multimedia applications. In such applications, main memoryaccess constitutes a significant This work was supported in part by the National Science Foundation under Grant No. NSF CCR-0311738. Author's address: Jelena, Trajkovic, Alexander V. Veidenbaum, and Arun Kejariwal, Center for Embedded Computer Systems, University of California, Irvine, California 92697; email: jelenat@ ics.uci.edu Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or direct commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or permissions@acm.org. C 2008 ACM 1539 -9087/2008 /04-ART24 $5.00 DOI 10.1145 /1347375.1347377 http://doi.acm.org/ 10.1145 portion of the overall energy consumption [Barr and Asanovic 2003; Kim et al. 2003 ]. Thus in order to minimize the latter, it is critical to reduce the (DRAM) main memory energy consumption. Most of the research in the area of lowpower systems has focused on reducing the energy consumption of the processor. On the contrary, this research studies the energy consumption of both the processor and the DRAM main memory. It investigates an architectural approach for reducing the main memory energy consumption without sacrificing overall performance.. Research in the area of low-power embedded processors, that is, processors that are optimized for low energy consumption and cost and do not aim for high performance, has identified the data and instruction caches [Wilkes 1965; Smith 1982; 1991] as the major consumers of power in the processor. These low-cost/low-power systems use only level-one (L1) caches and do not deploy a level-2 cache (which is standard in high-performance processors). Thus, much of the prior research to reduce the embedded processor energy consumption has focused on L1 caches.. However a main memory composed of commodity DRAM consumes orders of magnitude more energy per access than a cache access (see Tables II and III) . Even though an L1 cache significantly reduces the total number of access to main memory, the total energy expended in accessing memory can be very large. For instance, Barr and Asanovic [2003] showed that DRAM consumes more energy than the processor in a PDA.. As will be shown below, in some embedded applications the total energy of main memory accesses is an order of magnitude higher than the total data cache energy consumption. Thus, it is very important to both study and optimize DRAM access for energy consumption. Synchronous DRAM (SDRAM) memory is one of the main types of DRAM used today. This research will, therefore, focus on a system consisting of a low-power processor and a single SDRAM memory IC (integrated circuit) to study main memory energy consumption. Some of the techniques previously proposed for cache optimization can be adapted and extended for this purpose.. The energy of an SDRAM access can be divided into two main components: the energy of a bank/row activation (activate-precharge pair) and the energy of a read or write access to an active bank/row. The activate-precharge pair consumes over 60% of the total memory access energy (as per the manufacturer's data [Micron] ), as shown in Figure 1 . The figure quantifies energy components of a 64 MB SDRAM memory [MicronDataSheet] . These were obtained using Micron's System Power Calculator [Micron] . Each bar on the graph shows the activate-precharge and write components of the total energy. The figure shows the total energy for writing 16 bytes of data (one cache line), two separate 16-byte writes, and two 16-byte writes "combined" in one activation-precharge. For separate writes, we assume that a bank/row is precharged after each access. This mode is chosen because of the following: the energy of an "idle" state after precharge is significantly smaller (6.6 mW) than the energy of an "idle" state after activate command (82.5 mW). The figure also presents data for three and four accesses, performed separately or combined. The read components of the total energy follow a similar pattern. The SDRAM organization allows the bank/row to be left "on" after an access, which permits additional read/write access to the corresponding bank/row without incurring the activate/precharge cost on each access. Reading or writing twice the amount of data within the same activate-precharge cycle does not double the energy consumption, but only increases it by approximately 32%. This property of SDRAM is the key to the optimization techniques proposed in this paper. However, if a bank/row is left in the "on" state, but not accessed, extra energy is consumed as compared to the "idle" SDRAM state when little energy is consumed. The SDRAM can even be put into a "sleep mode" (clock not running), where only static energy, defined as the energy consumed when no signal activity occurs (i.e., no switching), is consumed. Initiating a new access to a "sleeping" SDRAM incurs additional delays. Thus any access energy optimization needs to take these different SDRAM characteristics into account. The details of SDRAM energy consumption will be further discussed in Section 3. In this work, we take into account static and dynamic energy 1 consumption of SDRAM.. Even simple embedded processors use a data cache and access memory only on cache misses or write-backs. A write-back data cache is typically used to reduce the write traffic and to aggregate writes into blocks. Thus, the memory is read/written in cache blocks (lines), one block at a time. However, reading/writing multiple memory blocks (from the DRAM) at a time would be more energy efficient within a single activate-precharge pair, but CPU cache controllers do not do that. In such a case, it may be very advantageous to change 1 Dynamic energy is defined as the energy consumed when signals are active (i.e., switching). the architecture to perform multiblock reads and writes from memory. We assume that we cannot change the processor architecture to accomplish this and, therefore, will add such a capability to the memory controller. Arguably, the architectural extension will work even better if integrated into the processor.. As will be shown in Section 5.2, the aforementioned new capability will lead to significant energy savings. Multiblock memory reads are similar to hardware prefetching, especially to stream buffers [Jouppi 1990] , which have been shown to work very well. Multiblock writes are similar to write combining [Smith 1982 ], but, in our case, they combine multiple cache blocks (beyond individual words). These techniques in our case target energy reduction rather than performance improvement. They are performed in our proposal in the memory controller and do not involve the CPU cache. One can argue that an increase in the cache line size can achieve the same reduction in energy consumption. However, in Section 5.2.4, we show that doubling the line is not competitive with the techniques proposed in this work. In the rest of this paper, we will use the terms fetching/prefetching and write combining for describing DRAM access in our system.. Accessing multiple lines outside of the processor requires intermediate storage. This research proposes to use a small amount of such storage in the memory controller. Additional lines will be fetched into this storage on each read. Writes to the same SDRAM row will be buffered first and combined into a multiple-line SDRAM write whenever possible.. The main contribution of this article is adapting both prefetching and write combining for SDRAM energy reduction, in particular, combining multiple cache line writes to the same SDRAM row. A second goal of this research is to minimize performance degradation or even to improve execution time while saving energy. The small buffers (mentioned above) used for prefetching/combining act as a "memory cache" and can significantly improve read performance, something similar to store-to-load forwarding [Hennessy and Patterson 2006] . "Regular" prefetching can sometimes degrade execution time by interfering with "regular" memory access without supplying useful data. It can also (1) "pollute" the cache; (2) require additional storage and CPU complexity, if not prefetched in the cache. Prefetching at the memory controller avoids most of these problems by overlapping a (reduced) delay of reading additional lines with the transfer of the missed line to the CPU cache. Write buffering at the memory enables the processor to continue execution and not wait for the SDRAM write access to finish.. Numerous potential cache organizations, sometimes even configurable on a per-page basis (e.g., ARM processors), especially with respect to write policy and write buffering have been proposed in the past. For instance, a write-through cache (or a write-back cache) that does not perform write-allocate may employ a write-combining buffer that attempts to assemble a block from individual writes rather than writing single words to memory. The reader is referred to Zhang et al. [2005] for a list of popular embedded processors and their (different) cache configurations. To be practical we had to choose one cache organization to evaluate. Our choice, a write-back write-allocate L1 data cache [Smith 1982] typically has a better performance than most other alternative organizations.. This organization does not require post-L1 write buffering except perhaps to perform a read miss fetch before completing the write, i.e., for performance optimization. Such a "victim" buffer [Hennessy and Patterson 2006] does not perform multiple-line writes to memory and is thus orthogonal to our approach (although it will provide some performance improvement by reducing read miss latency). Therefore, the baseline processor organization assumed in this article has no post-L1 cache write buffer.. The rest of the article is organized as follows: Section 2 presents related work. Section 3 describes the SDRAM energy components for read and write access. Section 4 presents architectural modifications and describes the energy-saving techniques of our approach. Experimental results demonstrating the benefits of the approach are presented in Section 5. Conclusions are presented in Section 6. In this article, a novel approach for reducing energy consumption for SDRAM memory access in embedded systems was proposed. It was shown that SDRAM energy consumption is, on average, 2.66× higher than that of a data cache for a low-power low-cost embedded processor making DRAM energy consumption minimization very important. We introduced architectural additions to the memory controller of a fully parameterizable unit that consists of a small high-speed fetch buffer and a write-combine buffer. This allowed DRAM read prefetching and combined write access to the main memory. Since prefetched data resides in a fast and small cachelike fetch buffer, an access to it is significantly cheaper, both in terms of time and energy consumption. Combining multiple cache-line write accesses leads to gains without any penalty. Writes are buffered in a small (eight entries) fully associative buffer waiting to be combined with any subsequent access to the same SDRAM row. Separate buffers are advocated for simultaneous use of read and write combining.. The results demonstrate that a significant reduction in memory energy consumption and delays can be achieved by read prefetching and write combining. The latter also reduces the overall execution time, which, in turn, minimizes the static energy consumption. Even with small size buffers, 256 byte/512 byte for prefetching and 128 byte for write combining, an average 23% DRAM energy reduction is achieved. The DRAM energy-delay (ED) product is improved, on average, by over 40%. The CPI is reduced by 26%, on average. Further reduction in ED and CPI can be obtained if the proposed buffers were integrated in the CPU.. Prefetching or write combining can be powered down individually to better tune them to a given application. In order to utilize power down, compiler analysis, profiling or user directives could be used. The proposed technique can be applied to programs regions, such as loops or functions, where it is profitable and turned off in other program regions. For instance, the technique would not be effective for accesses with long strides, such as reading an array A[33i+7] in a loop.. The proposed approach requires simple hardware suitable to embedded systems. In a resource constrained environment of embedded systems running multimedia or other type of applications, these energy savings provide a significant benefit. As future work, we plan to evaluate the impact of technology scaling on the efficacy of the proposed apporach. The impact of the proposed architecture is evaluated by comparing the memory energy consumption, energy-delay product, and CPI relative to the baseline configuration. The following legend is used:. -"FetchN M" for read fetch of N lines with a buffer of M lines (N − 1 lines are prefetched); -"WCB P" for write combining of two accesses with a buffer of P lines; -"WCB PxQ" for write-combining of (Q +1) accesses with a buffer of P entries x Q lines; -"FetchN M+WCB PxQ" for a hybrid configuration. Table III shows memory energy per benchmark relative to the data cache memory consumption for the baseline model. These large ratios were observed inspite of the fact that the average cache miss rate for the entire suite was 3.5%. Montagnaro et al. [1996] showed that the data cache consumes 16% of the overall processor energy. For MiBench benchmarks the main memory consumes an average of 2.6 times the energy of the data cache that is quantified. This demonstrates that the DRAM energy optimization is more important than that of the data cache. The worst-case difference is 15×, which means that the DRAM consumes approximately twice the energy used by the processor. There is a large body of prior work on prefetching, write buffers, and wordlevel write combining buffers that is briefly summarized below. Techniques for reducing energy consumption in main memory are also described. Many architectural approaches for reducing energy consumption in embedded processors have been proposed. To the best of our knowledge architectural solutions for SDRAM energy reduction have not been proposed so far. For a software-based solution see Kim et al. [2003] , for instance.. Numerous prefetching algorithms have been proposed for fetching cache lines based on history driven prediction of future memory accesses. For instance, a stream buffer [Jouppi 1990 ] prefetches consecutive lines triggered by a miss. Prefetching schemes differ mainly in how they predict which block to fetch rather than in how many blocks to fetch. A variable-length prefetching mechanism proposed in Dahlgren et al. [1993] changes the number of blocks prefetched based on their utilization. Macroblocks were proposed as a fixed-size superline in Johnson et al. [1997] . A detection mechanism is used to identify the use of multiple lines within a macroblock and fetch the entire macroblock on future misses. However, superline detection requires a large hardware predictor to keep track of access history. An "adaptive line size" (ALS) cache was proposed for predicting the line size for the next fetch upon a line replacement in Veidenbaum et al. [1999] . Solihin et al. [2002] describe a method for prefetching based on correlation of memory addresses with an engine that resides in L2 cache that gives significant performance gain even with a low hit rate in the prefetch buffer. Since the engine is placed in L2 cache, it misses potential correlations that may lead to better prefetching. All of the prior schemes (except stream buffers) described above require a complex mechanism for detection and prediction of the next fetch size. In contrast, our work uses a simple mechanism and requires little hardware support. None of the prefetching proposals targets energy reduction.. Adding a write buffer is a common optimization that allows the processor to continue execution as soon as the data is written to the buffer. Thus, the major part of memory update is done independent of the processor execution. Smith [1979] gives a study of performance impact of write buffer and write merging.. Jouppi discusses write buffers and write caches and evaluates their performance for both write-back and write-through schemes [Jouppi 1993; Farkas et al. 1994] . Merging is introduced to improve performance of write buffers. This approach combines incoming write request with requests already residing in the write buffer, resulting in a more efficient bus and memory usage. The techniques has been applied to architectures like Alpha 21164, UltraSparc III, StrongARM, MIPS R4300i, and XScale. XScale allows combining requests for four word-aligned addresses. None of these attempt to combine multiple line write-backs to the memory.. Low-power mode is present in most state-of-the-art DRAMs. A significant amount of energy can be saved by setting as many memory chips as possible to sleep mode [Lebeck et al. 2000] . Likewise, efforts have been made in reducing memory energy consumption based on different compression techniques. For instance, Abali and Franke [2000] describe and evaluate a computer system that supports hardware main memory compression. Likewise, Ekman and Stenström [2005] proposed a main-memory compression scheme. As the compression ratio of applications dynamically changes, so does the real memory size that is managed by the operating system (OS). For such systems, OS changes are necessary to support main memory compression. These changes include the management of the free pages pool as a function of the physical memory utilization and the effective compression ratio, coupled with zeroing pages at free time rather than at allocation time. Kim et al. [2003] identify successive memory accesses to different rows and banks as a source for increased latency and energy consumption in memory. They use block-based layouts instead of a traditional one and determine the best block size such that the number of requests to different rows or banks is minimized. Rixner et al. [2000] proposed a memory-scheduling technique for efficient use of the memory bandwidth. Similarly, Goossens et al. [2004] proposed a technique for efficient exploitation of the bandwidth between the SDRAM and the on-chip interconnect. However, the above do not address the issue of minimization of power consumption of the SDRAM.

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 B 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 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 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 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 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 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 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 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 O O O 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 O O O O O O 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 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 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 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 O O O 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 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 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 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 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 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 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 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 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 B O O O O O O O O O O O O O O O O O O O B


On the Expressiveness and Complexity of ATL Abstract. ATL is a temporal logic geared towards the specification and verification of properties in multi-agents systems. It allows to reason on the existence of strategies for coalitions of agents in order to enforce a given property. In this paper, we first precisely characterize the complexity of ATL model-checking over Alternating Transition Systems and Concurrent Game Structures when the number of agents is not fixed. We prove that it is ∆ P 2 -and ∆ P 3 -complete, depending on the underlying multi-agent model (ATS and CGS resp.). We also consider the same problems for some extensions of ATL. We then consider expressiveness issues. We show how ATS and CGS are related and provide translations between these models w.r.t. alternating bisimulation. We also prove that the standard definition of ATL (built on modalities "Next", "Always" and "Until") cannot express the duals of its modalities: it is necessary to explicitely add the modality "Release". Model checking. Temporal logics were proposed for the specification of reactive systems almost thirty years ago [CE81, Pnu77, QS82] . They have been widely studied and successfully used in many situations, especially for model checking -the automatic verification that a finite-state model of a system satisfies a temporal logic specification. Two flavors of temporal logics have mainly been studied: linear-time temporal logics, e.g. LTL [Pnu77] , which expresses properties on the possible executions of the model; and branching-time temporal logics, such as CTL [CE81, QS82] , which can express requirements on states (which may have several possible futures) of the model.. Plan of the paper. Section 2 contains the formal definitions needed in the sequel. Section 3 deals with the model-checking questions and contains algorithms and complexity analysis for ATSs and CGSs. Section 4 contains our expressiveness results: we first prove that ATSs and CGSs have the same expressive power w.r.t. alternating bisimulation (i.e., any CGS can be translated into an equivalent ATS, and vice-versa). We then present our expressiveness results concerning ATL modalities.. 2. Definitions 2.1. Concurrent Game Structures. Concurrent game structures are a multi-player extension of classical Kripke structures [AHK02] . Their definition is as follows: Definition 2.1. A Concurrent Game Structure (CGS for short) C is a 6-tuple (Agt, Loc, AP, Lab, Mov, Edg) where:. • Agt = {A 1 , ..., A k } is a finite set of agents (or players); • Loc and AP are two finite sets of locations and atomic propositions, resp.;. • Lab : Loc → 2 AP is a function labeling each location by the set of atomic propositions that hold for that location; • Mov: Loc × Agt → P(N) {∅} defines the (finite) set of possible moves of each agent in each location.. • Edg : Loc × N k → Loc, where k = |Agt|, is a (partial) function defining the transition table. With each location and each set of moves of the agents, it associates the resulting location.. The intended behaviour is as follows [AHK02] : in a location ℓ, each player A i chooses one possible move m A i in Mov(ℓ, A i ) and the next location is given by Edg(ℓ, m A 1 , ..., m A k ). We write Next(ℓ) for the set of all possible successor locations from ℓ, and Next(ℓ, A j , m), with m ∈ Mov(ℓ, A j ), for the restriction of Next(ℓ) to locations reachable from ℓ when player A j makes the move m.. The way the transition table Edg is encoded has not been made precise in the original definition. Following the remarks of [JD05] , we propose two possible encodings:. Definition 2.2.. • An explicit CGS is a CGS where the transition table is defined explicitly.. • An implicit CGS is a CGS where, in each location ℓ, the transition function is defined by a finite sequence ((ϕ 0 , ℓ 0 ), ..., (ϕ n , ℓ n )), where ℓ i ∈ Loc is a location, and ϕ i is a boolean combination of propositions A j = c that evaluate to true iff agent A j chooses move c. The transition table is then defined as follows: Edg(ℓ, m A 1 , ..., m A k ) = ℓ j iff j is the lowest index s.t. ϕ j evaluates to true when players A 1 to A k choose moves m A 1 to m A k . We require that the last boolean formula ϕ n be ⊤, so that no agent can enforce a deadlock.. Besides the theoretical aspect, the implicit description of CGSs may reveal useful in practice, as it allows to not explicitly describe the full transition table.. The size |C| of a CGS C is defined as |Loc| + |Edg|. For explicit CGSs, |Edg| is the size of the transition table. For implicit CGSs, |Edg| is the sum of the sizes of the formulas used for the definition of Edg. In this paper, we considered the basic questions of expressiveness and complexity of ATL. We precisely characterized the complexity of ATL, ATL + , EATL and ATL ⋆ model-checking, on both ATSs and CGSs, when the number of agents is not fixed. These results complete the previously known results about these formalisms (and corrects some of them). It is interesting to see that their complexity classes (∆ P 2 or ∆ P 3 ) are unusual in the area of modelchecking. We also showed that ATL, as originaly defined in [AHK97, AHK98, AHK02], is not as expressive as it could be expected, and we argue that the modality "Release" should be added in its definition.

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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Abstract Combinatorial Programs and Efficient Property Testers AbstractProperty testing is a relaxation of classical decision In this paper, we consider Property Testing problems, that is, problems of determining whether a given function has a predetermined property or is "far" from any function having the property. A notion of property testing was first explicitly formulated by Rubinfeld and Sudan [25] , who * Research supported in part by NSF grant CCR-0105701, by DFG grant Me872/8-1, and by the Future and Emerging Technologies program of the EU under contract number IST-1999-14186 (ALCOM-FT).. were motivated mainly by its connection to program checking. This notion arises naturally in the context of program verification [7, 25] , learning theory, and, in a more theoretical setting, in probabilistically checkable proofs [6] . In [17] , the study of property testing for combinatorial objects was initiated. In this and other more recent papers (see, the excellent surveys in [13, 16, 24] and the references therein), various algorithms have been proposed for testing graph and hypergraph properties, for testing geometric properties, for testing properties of metrics and matrices, for testing properties of regular languages and branching problems, for testing monotonicity, properties of Boolean functions, etc.. A property testing algorithm (property tester) is a randomized algorithm that distinguishes (with low error probability) between the functions that have a predetermined property and functions that are "far" from any function having the property. A good property tester is one that looks only at a small fraction of the function values. There are two error models for property testing algorithms. In this paper we consider only the one-sided error model, in which the tester must accept every function that has the property and must reject with probability at least 2 3 every function that is "far" from having the property. To specify the notion of being "far" from having a property, one has to define a distance measure between functions. For a given parameter , a function is -far from having a property if it has distance bigger than from any function having the property. Since property testing is a relaxation of the traditional decision problem, it is often possible to design algorithms that are much faster than their "classical" counterparts. In particular, there exist many property testing algorithms whose complexity is sublinear, or even independent of the input size (see, e.g., [13, 16, 24] ). This, in turn, resulted in development of sublinear-time approximation algorithms (in the "traditional" sense) for many classical combinatorial problems, including bisection, metric Max-cut, clustering problems, estimating the cost of the minimum spanning tree, etc. (see, e.g., [4, 9, 10, 12, 14, 17, 19, 20] ).. Although many efficient testing algorithms are known, most of them have been analyzed using ad-hoc techniques designed specially for the problem at hand. There is still insufficient methodology and a very few tools that could help in the analysis of efficient testers for new problems. Goldreich et. al. [17] (see also Theorem 4.3 in [13] ) presented a fairly general framework (for the two-sided-error model; see [18] for a characterization in a one-sided-error model) of studying testing of certain graph partitioning problems. They were able to apply this framework to some graph problems, including graph coloring, clique, cut, and bisection. Another general approach, which uses the Szemerédi regularity lemma, has been proposed recently for studying graph problems and problems on matrices [3, 14, 21] . Even if this method is very powerful (and in particular, it allowed to prove that all first order graph properties without a quantifier alternation of type ∀∃ have property testers whose complexity is independent of the size of the input graph), there are still some limitations of this approach. Furthermore, even though the bounds obtained by using the regularity lemma lead to the complexity bounds that are often independent from the input size, their dependence on the approximation parameter is often enormous (see, the "tower" bounds in [3] and superpolynomial lower bounds in [1] ).

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 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 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 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 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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


Secure and Efficient Key Management in Mobile Ad Hoc Networks Abstract-In mobile ad hoc networks, due to unreliable wireless media, host mobility and lack of infrastructure, providing secure communications is a big challenge in this unique network environment. Usually cryptography techniques are used for secure communications in wired and wireless networks. The asymmetric cryptography is widely used because of its versatileness (authentication, integrity, and confidentiality) and simplicity for key distribution. However, this approach relies on a centralized framework of public key infrastructure (PKI). The symmetric approach has computation efficiency, yet it suffers from potential attacks on key agreement or key distribution. In fact, any cryptographic means is ineffective if the key management is weak. Key management is a central aspect for security in mobile ad hoc networks. In mobile ad hoc networks, the computational load and complexity for key management is strongly subject to restriction of the node's available resources and the dynamic nature of network topology. In this paper, we propose a secure and efficient key management framework (SEKM) for mobile ad hoc networks. SEKM builds PKI by applying a secret sharing scheme and an underlying multicast server group. In SEKM, the server group creates a view of the certification authority (CA) and provides certificate update service for all nodes, including the servers themselves. A ticket scheme is introduced for efficient certificate service. In addition, an efficient server group updating scheme is proposed. Mobile ad hoc networks are special type of wireless networks in which a collection of mobile hosts with wireless network interfaces may form a temporary network, without the aid of any fixed infrastructure or centralized administration. In mobile ad hoc networks, nodes within their wireless transmitter ranges can communicate with each other directly (assume that all nodes have the same transmission range), while nodes outside the range have to rely on some other nodes to relay messages. Thus a multi-hop scenario occurs, where the packets sent by the source host are relayed by several intermediate hosts before reaching the destination host. Every node functions as a router. The success of communication highly depends on the other nodes' cooperation.. While mobile ad hoc networks can be quickly and inexpensively setup as needed, security is a critical issue compared to wired or other wireless counterparts. Many passive and active security attacks could be launched from the outside by malicious hosts or from the inside by compromised hosts [10] [12].. Cryptography is an important and powerful tool for security services, namely authentication, confidentiality, integrity, and non-repudiation. It converts readable data (plaintext) into meaningless data (ciphertext). Cryptography has two dominant flavors, namely symmetric-key (secret-key) and asymmetrickey (public-key) approach. In symmetric-key cryptography, the same key is used to encrypt and decrypt the information, while in the asymmetric-key approach, different keys are used to convert and recover the information. Although the asymmetric cryptography approach possesses versatileness (authentication, integrity, and confidentiality) and simplicity for key distribution, symmetric-key algorithms are generally more computation-efficient than the public-key approach. There is a variety of symmetric or asymmetric algorithms available, such as DES, AES, IDEA, RSA, and EIGamal [1] [2] [11] . Threshold cryptography [3] is a scheme quite different from the above two approaches. In Shamir's (k, n) secret sharing scheme, a secret is split into n pieces according to a random polynomial. The secret can be recovered by combining k pieces based on Lagrange interpolation. Secret splitting, reconstruction, and verification is quickly reviewed in Section 3. These cryptography tools are widely used in wired and wireless networks, obviously they could also be used in mobile ad hoc networks.. Key management is a basic part of any secure communication. Most cryptosystems rely on some underlying secure, robust, and efficient key management system. Key management deals with key generation, storage, distribution, updating, revocation, and certificate service, in accordance with security policies. Key management primitives and a trust model are presented in Section 3. The outline of key management is described below. First, secrecy of key itself must be assured in the local host system. Second, secure network communications involve key distribution procedure between communication parties, in which the key may be transmitted through insecure channels. Key confidentiality, integrity, and ownership must be enforced in the whole procedure. Third, a framework of trust relationships needs to be built for authentication of key ownership. While some frameworks are based on a centralized Trusted Third Party (TTP), others could be fully distributed. For example, a Certificate Authority is the TTP in PKI, Key Distribution Center (KDC) is the TTP in the symmetric system, meanwhile in PGP, no such a trusted entity is assumed.. Fourth, the key could be expired or have been revoked within its valid period.. We introduce here a secure and efficient key management scheme (SEKM). In SEKM, the system public key is distributed to the whole network. Like some schemes described in Section 2, in SEKM, the trust of the central authority (CA) is distributed to a subset of nodes (not all nodes), which could be nodes with normal or better equipment. The major contribution of our scheme is that SEKM is designed to provide efficient share updating among servers and to quickly respond to certificate updating, which are two major challenges in a distributed CA scheme. The basic idea is that server nodes form the underlying service group for efficient communication.. For efficiency, only a subset of the server nodes initiates the share update phase in each round. A ticket based scheme is introduced for efficient certificate updating. Normally, because of share updating, recently joining servers could be isolated from the system if they carry outdated certificates. Our scheme does not isolate new servers, and is open for regular nodes for easy joining and departing. SEKM creates a view of CA and provides secure and efficient certificate service in the mobile and ad hoc environment. The framework of SEKM is described in Section 4.. This paper is organized as follows: Section 2 reviews related work. Section 3 discusses key management and trust model in mobile ad hoc networks. Details of the SEKM scheme are described in Section 4. In Section 5, we conclude the paper and discuss possible future work. Throughout the paper, we use terms node and host interchangeably. Security is an important issue for mobile ad hoc networks. For security we mainly consider the following attributes: availability, confidentiality, integrity, authentication, authorization and non-repudiation. Certain security mechanisms and protocols have been designed and proposed for ad hoc wireless network. Key management is a the central aspect of the security of mobile ad hoc networks, and it is still a weak point. In this paper we propose a key management scheme, SEKM, which creates a PKI structure for this type of networks in mobile ad hoc networks. In SEKM, server nodes form a mesh-based server group. SEKM is based on the secret sharing scheme, where the system secret is distributed to a group of server nodes. The server group creates a view of CA. The advantage is that in SEKM it is easier for a node to request service from a well maintained group rather than from multiple "independent" service providers which may be spread in a whole area. It is much easier for servers to coordinate within the group rather than with the entire network during the secret share updating phase.. A detailed SEKM framework and operational phases are described in this paper. In SEKM, the server group provides certificate update service for all nodes including the servers themselves. A ticket scheme is introduced for efficient certificate service. Meanwhile, an efficient server group periodical updating scheme is proposed. In our future work we will evaluate the performance of SEKM by simulation, and we will extend SEKM to multiple server groups in large networks and in partitioned networks. Recently, security has become a hot research topic in mobile ad hoc networks. Several secure routing protocols have being proposed in the literature. For example, SRP [22] , SEAD [20] , and SAODV [19] address security attacks in routing protocols and propose different means to counter particular threats. However, almost all of them rely on the existence of a public key management system. Even in TESLA [21] , delivery and authentication of the first element in hash chain requires the asymmetric key management framework. So the existence of an effective key management framework is fundamental to secure routing protocols. There are some other research papers which focus on either secure data transmission, intrusion detection, or key management in mobile ad hoc networks. Although these topics are closely related, however we emphasize key management and ignore the rest of these topics here, we will address those topics in the future work.. Zhou and Hass [7] propose a secure key management scheme by employing (t, n) threshold cryptography. The system can tolerate t − 1 compromised servers. However, this scheme doesn't describe how a node can contact t servers securely and efficiently in case the servers are scattered in the whole area. A share refreshing scheme is proposed to counter mobile adversaries. However, efficient and secure distributions of secret shares are not addressed.. Luo, Kong, and Zerfos [9] propose a localized key management scheme called URSA. In this scheme all nodes are servers. The advantage of this scheme is efficiency and secrecy of local communication as well as system availability; on the other hand, it reduces the system security especially when nodes are not well protected. One problem is that in case the threshold k is much larger than the network degree d, nodes will have to keep moving to get certificates updated. The second critical issue is the convergence in the share updating phase. The third critical issue is that too much offline configuration is required before accessing the networks.. Yi, Naldurg, and Kravets [8] propose a scheme called MOCA key management. In their approach, certificate service is distributed to Mobile Certificate Authority (MOCA) nodes, which are physically more secure and powerful than other nodes. In their scheme, a node could locate k+α MOCA nodes either randomly, through the shortest path, or based on freshest path in its route cache. But the critical question is how nodes can discover those paths securely since most secure routing protocols are based on the establishment of a key service.. Capkun, Buttyan, and Hubaux [17] propose a fully distributed scheme. It has the advantage of configuration flexibility. However, it lacks of any trusted security anchor in the trust structure. Lots of certificates need to be generated. Every node should collect and maintain up-to-date a certificate repository. Certificate chaining is used for authentication of public keys. The certificate graph, which is used to model this web of trust relationship, may not be strongly connected, especially in the mobile ad hoc scenario. In that case nodes within one component may not be able to communicate with ones in different components. Certificate conflicting is just another example of a potential problem in this scheme. A scheme with improved certificate repository maintenance could be introduced.. Recently, Yi and Kravets [18] propose a composite trust model. In their scheme they combine the central trust model and the fully distributed trust model. This scheme takes advantage of the positive aspects of two different trust systems. Actually, it is a compromise between security and flexibility. Some authentication metrics, such as confidence value, are introduced in order to glue two trust systems. However, assignment of confidence value properly is a challenge and problematic.. In summary, the schemes proposed in [7] [8] [9] are based on the secret sharing technique. Zhou focuses on the share updating procedure, Yi's scheme emphasizes efficient communications among MOCA nodes. Luo's approach addresses the problem of share updating and certificate service in a localized environment. Capkun discusses the problem of key repository maintenance and certificate chaining in a fully distributed way.

O O O B I O B I I I O B I 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 B I O O B I O O O O O B O B I I I O B I I 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 B I O O O B I I I O O O O O O B I O O O O O B I 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 B I 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 B I 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 B I I I 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 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 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 B I I I B I O O O O O O O O O O O O O O O O O O B I O B I 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 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 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 B I O O O O B I 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 B O O O O O B I I I 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 B I O O O O O O O B O B I I 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 B I I I O 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 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 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 O B O O O O O O O B I I I 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 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 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 B I I 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 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 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 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 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 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 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


On the complexity of binary samples Consider a class H of binary functions h : X → {−1, +1} on an interval X = [0, B] ⊂ IR. Define the sample width of h on a finite subset (a sample) Sbe the space of all samples in X of cardinality and consider sets of wide samples, i.e., hypersets which are defined as A β,h = {S ∈ S : ω S (h) ≥ β}. Through an application of the Sauer-Shelah result on the density of sets an upper estimate is obtained on the growth function (or trace) of the class {A β,h : h ∈ H}, β > 0, i.e., on the number of possible dichotomies obtained by intersecting all hypersets with a fixed collection of samples S ∈ S of cardinality m. The estimate is 2 2 B/(2β) i=0 m− i .06E30 · 68Q32 · 68Q25 · 03C13 · 68R05Let B > 0 and define the domain as X = [0, B]. In this paper we consider the class H of all binary functions h : X → {−1, +1} which have only simple discontinuities, i.e., at any point x the limits h(x + ) = lim z→x + h(z) from the right and similarly from the left h(x − ) exist (but are not necessarily equal). A main theme of our recent work has been to characterize binary functions based on their behavior on a finite subset of X. In [2] it was shown that the problem of learning binary functions from a finite labeled sample can improve the generalization error-bounds if the learner For any logical expression A denote by I{A} the indicator function which takes the value 1 or 0 whenever the statement A is true or false, respectively. Let be any fixed positive integer. We denote by S the space of all samples S ⊂ X of size . On S , consider the following sets of wide samples,. We refer to such sets as hypersets. It will be convenient to associate with these sets the indicator functions on S which are denoted by h β,h (S) = I Aβ,h (S).. These are referred to as hyperconcepts and we may write h for brevity. For any fixed width parameter γ > 0, define the hyperclass. In words, H γ consists of all sets of subsets S ⊂ X of cardinality on which the corresponding binary functions h are wide by at least γ . The aim of the paper is to compute the complexity of the hyperclass H γ that corresponds to the class H. Since the domain X is infinite, then so is H γ , and hence, one cannot simply measure its cardinality. Instead, we apply a standard combinatorial measure of the complexity of a family of sets as follows: let Y be an arbitrary domain and G an infinite class of subsets of Y. For any subset S = {y 1 , . . . , y n } ⊂ Y let. where G |S = {[I G (y 1 ), . . . , I G (y n )] : G ∈ G}. The vector [I G (y 1 ), . . . , I G (y n )] is sometimes referred to as a labeling or a dichotomy of the sample S. The growth function (see for instance [1] ) is defined as. It measures the rate at which the number of dichotomies, obtained by intersecting subsets G of G with a finite set S, increases with respect to the cardinality n of S in the extreme case, i.e., for the maximal possible S. This quantity is also known as the trace of G, see for instance [3] .. Since we are interested in hypersets as opposed to simple sets G (as above) then we consider the trace on a finite collection ζ ⊂ S of samples (instead of a finite sample S as above). It will be convenient to define the cardinality of such a collection as the cardinality of the union of its component sets, i.e., for any given finite collection ζ ⊂ S let. and we use m to denote a possible value of |ζ |. As a measure of complexity of H γ we compute the growth as a function of m, i.e.

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 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 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 B I 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 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


Improving Application Launch Performance on Solid State Drives Abstract Application launch performance is of great importance to system platform developers and vendors as it greatly affects the degree of users' satisfaction. The single most effective way to improve application launch performance is to replace a hard disk drive (HDD) with a solid state drive (SSD), which has recently become affordable and popular. A natural question is then whether or not to replace the traditional HDD-aware application launchers with a new SSD-aware optimizer. We address this question by analyzing the inefficiency of the HDD-aware application launchers on SSDs and then proposing a new SSD-aware application prefetching scheme, called the Fast Application STarter (FAST). The key idea of FAST is to overlap the computation (CPU) time with the SSD access (I/O) time during an application launch. FAST is composed of a set of user-level components and system debugging tools provided by Linux OS (operating system). Hence, FAST can be easily deployed in any recent Linux versions without kernel recompilation. We implement FAST on a desktop PC with an SSD running Linux 2.6.32 OS and evaluate it by launching a set of widely-used applications, demonstrating an average of 28% reduction of application launch time as compared to PC without a prefetcher. Application launch performance is one of the important metrics for the design or selection of a desktop or a laptop PC as it critically affects the user-perceived performance. Unfortunately, application launch performance has not kept up with the remarkable progress of CPU performance that has thus far evolved according to Moore's law. As frequently-used or popular applications get "heavier" (by adding new functions) with each new release, their launch takes longer even if a new, powerful machine equipped with high-speed multi-core CPUs and several GBs of main memory is used. This undesirable trend is known to stem from the poor random access performance of hard disk drives (HDDs). When an application stored in an HDD is launched, up to thousands of block requests are sent to the HDD, and a significant portion of its launch time is spent on moving the disk head to proper track and sector positions, i.e., seek and rotational latencies. Unfortunately, the HDD seek and rotational latencies have not been improved much over the last few decades, especially compared to the CPU speed improvement. In spite of the various optimizations proposed to improve the HDD performance in launching applications, users must often wait tens of seconds for the completion of launching frequently-used applications, such as Windows Outlook.. A quick and easy solution to eliminate the HDD's seek and rotational latencies during an application launch is to replace the HDD with a solid state drive (SSD). An SSD consists of a number of NAND flash chips, and does not use any mechanical parts, unlike disk heads and arms of a conventional HDD. While the HDD access latency -which is the sum of seek and rotational latencies -ranges up to a few tens of milliseconds (ms), depending on the seek distance, the SSD shows a rather uniform access latency of about a few hundred micro-seconds (us). Replacing an HDD with an SSD is, therefore, the single most effective way to improve application launch performance.. Until recently, using SSDs as the secondary storage of desktops or laptops has not been an option for most users due to the high cost-per-bit of NAND flash memories. However, the rapid advance of semiconductor technology has continuously driven the SSD price down, and at the end of 2010, the price of an 80 GB SSD has fallen below 200 US dollars. Furthermore, SSDs can be installed in existing systems without additional hardware or software support because they are usually equipped with the same interface as HDDs, and operating systems (OSes) see an SSD as a block device just like an HDD. Thus, end-users begin to use an SSD as their system disk to install the OS image and applications.. Although an SSD can significantly reduce the application launch time, it does not give users ultimate satisfaction for all applications. For example, using an SSD reduces the launch time of a heavy application from tens of seconds to several seconds. However, users will soon become used to the SSD launch performance, and will then want the launch time to be reduced further, just as they see from light applications. Furthermore, users will keep on adding functions to applications, making them heavier with each release and their launch time greater. According to a recent report [1] , the growth of software is rapid and limited only by the ability of hardware. These call for the need to further improve application launch performance on SSDs.. Unfortunately, most previous application launch optimizers are intended for HDDs and have not accounted for the SSD characteristics. Furthermore, some of them may rather be detrimental to SSDs. For example, running a disk defragmentation tool on an SSD is not beneficial because changing the physical location of data in the SSD does not affect its access latency. Rather, it generates unnecessary write and erase operations, thus shortening the SSD's lifetime.. In view of these, the first step toward SSD-aware optimization may be to simply disable the traditional optimizers designed for HDDs. For example, Windows 7 disables many functions, such as disk defragmentation, application prefetch, Superfetch, and Readyboost when it detects an SSD being used as a system disk [2] . Let consider another example. Linux is equipped with four disk I/O schedulers: NOOP, anticipatory, deadline, and completely fair queueing. The NOOP scheduler almost does nothing to improve HDD access performance, thus providing the worst performance on an HDD. Surprisingly, it has been reported that NOOP shows better performance than the other three sophisticated schedulers on an SSD [3] . To the best of our knowledge, this is the first attempt to focus entirely on improving application launch performance on SSDs. Specifically, we propose a new application prefetching method, called the Fast Application STarter (FAST), to improve application launch time on SSDs. The key idea of FAST is to overlap the computation (CPU) time with the SSD access (I/O) time during each application launch. To achieve this, we monitor the sequence of block requests in each application, and launch the application simultaneously with a prefetcher that generates I/O requests according to the a priori monitored application's I/O request sequence. FAST consists of a set of user-level components, a systemcall wrapper, and system debugging tools provided by Linux OS. FAST can be easily deployed in most recent Linux versions without kernel recompilation. We have implemented and evaluated FAST on a desktop PC with an SSD running Linux 2.6.32, demonstrating an average of 28% reduction of application launch time as compared to PC without a prefetcher.. This paper makes the following contributions:. • qualitative and quantitative evaluation of the inefficiency of traditional HDD-aware application launch optimizers on SSDs;. • development of a new SSD-aware application prefetching scheme, called FAST; and. • implementation and evaluation of FAST, demonstrating its superiority and deployability.. The paper is organized as follows. In Section 2, we review other related efforts and discuss their performance in optimizing application launch on SSDs. Section 3 describes the key idea of FAST and presents a lower bound of the application launch time achievable with FAST. Section 4 discusses design issues to implement FAST. Section 5 details the implementation of FAST on Linux OS, while Section 6 evaluates its performance using various real-world applications. Section 7 discusses the applicability of FAST and Section 8 compares FAST with traditional I/O prefetching techniques. We conclude the paper with Section 9. In this section, we summarize traditional application launch optimization techniques for HDDs as well as recent work for SSD performance optimization. We also discuss the effectiveness of the traditional HDD-based launch optimization schemes on SSDs.

O B I I 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 B I I 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 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 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 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 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 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 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O


Finding programming errors earlier by evaluating runtime monitors ahead-of-time Runtime monitoring allows programmers to validate, for instance, the proper use of application interfaces. Given a property specification, a runtime monitor tracks appropriate runtime events to detect violations and possibly execute recovery code. Although powerful, runtime monitoring inspects only one program run at a time and so may require many program runs to find errors. Therefore, in this paper, we present ahead-of-time techniques that can (1) prove the absence of property violations on all program runs, or (2) flag locations where violations are likely to occur. Our work focuses on tracematches, an expressive runtime monitoring notation for reasoning about groups of correlated objects. We describe a novel flow-sensitive static analysis for analyzing monitor states. Our abstraction captures both positive information (a set of objects could be in a particular monitor state) and negative information (the set is known not to be in a state). The analysis resolves heap references by combining the results of three points-to and alias analyses. We also propose a machine learning phase to filter out likely false positives. We applied a set of 13 tracematches to the DaCapo benchmark suite and SciMark2. Our static analysis rules out all potential points of failure in 50% of the cases, and 75% of false positives on average. Our machine learning algorithm correctly classifies the remaining potential points of failure in all but three of 461 cases. The approach revealed defects and suspicious code in three benchmark programs. A program's sequence of events over an execution is a rich source of information about the program's behaviour on that execution. Some sequences of runtime events indicate defects in the program: for instance, programs must not advance iterators with no more elements. Runtime monitoring can detect such sequences of events, enabling developers to handle the sequences with reporting or recovery code.. However, runtime monitoring can only detect errors as they occur, and furthermore inspects only one program execution at a time and so may require many executions to find errors. Errors may therefore be hard to find and can remain unnoticed until late in the development process or even until after a program is deployed.. Our research aims to verify runtime monitoring properties ahead-of-time, through static analysis. Static verification can (1) prove the absence of error conditions on all executions, or (2) flag all code locations where errors may possibly occur. We designed a "complete" static analysis-no missed violations-that would report as few false positives as possible. However, to design a complete static analysis, we had to make conservative assumptions, which potentially lead to false positives. To mitigate the impact of false positives, we developed a new (optional) machine learning approach that filters out likely false positives, which enables developers to concentrate on program points that are likely points of failure. Our combined approach enables the programmer to (1) manually inspect all potential points of failure (starting with the likely points of failure), and (2) specify recovery code to gracefully handle all remaining potential points of failure (which she could also inspect manually).. We focus on one particular approach to runtime monitoring: tracematches [2] , a Java language extension. Tracematches are concise yet expressive; they enable developers to specify interesting error situations. Using tracematches, developers can specify traces of interest via regular expressions of symbols with free variables, along with some code to execute if such a trace occurs on a program execution. A symbol's free variables bind heap objects at runtime. A tracematch triggers when its regular expression matches a suffix of the current execution trace with a consistent variable binding. For example, tracematches can monitor for inappropriate use of iterators; the regular expression "next(i) next(i)" over the alphabet {hasNext(i), next(i)} matches if a program calls the next() method twice on an iterator i without any intervening call to hasNext(). Figure 1 shows our complete analysis approach for tracematches (an explanation follows). The fact that tracematch collect wholeprogram points-to information [18] interprocedural flow-insensitive analysis [7] collect intraprocedural flow-sensitive alias information events bind variables to heap objects at runtime is the key challenge for any static analysis of tracematches. In the above example, the variable i would be bound at the first next(i) event and matched at the second next(i) event.. Because heap objects are often shared by different methods in a program, and because any method could cause an event on a bound object, one might think that any nontrivial static analysis of tracematches would have to be both interprocedural and flow-sensitive. In previous work [7] we tried such an approach and failed: we found that a precise analysis of tracematches requires must-alias information for strong updates. Such information is very expensive to compute at a whole-program level. Our earlier work further showed that an interprocedural but flow-insensitive analysis could only eliminate the partial matches of tracematches that could not be completed for trivial reasons, e.g. iterators which receive calls to hasNext() but never to next(). We therefore took a step back and determined where and how tracematches matched in our benchmarks. To our surprise, many tracematches described mostly-local patterns, often confined to a single method. This led us to the principal finding of this paper: A suite of carefully-designed intraprocedural flow-sensitive analyses (top of Figure 1 ) can successfully reason about tracematch states, if intelligently combined with precise local alias information and inexpensive whole-program summary information.. Note that tracematches are much harder to analyze than typestate [19] . In typestate, the type system associates a state with each individual object of a given type. Static typestate analyses can therefore track the possible states of each of a program's allocation sites individually [11] . Many tracematches, however, have multiple free variables. In such situations, multiple objects share a joint state. A naive attempt must therefore track the states of all combinations of allocation sites-an exponential blowup. To avoid this blowup, we instead encode knowledge about entire equivalence classes of objects using constraints. Our abstraction associates two kinds of information with each state q: positive information x = o (object o is in state q, bound to tracematch variable x) and negative information x = o (any object except o may be in q and bound to x). In our benchmarks, the combination of positive and negative information enables us to eliminate most false positives.. As the Figure shows, our static analysis can be useful in various cases. In the ideal case (A), the analysis reports that the program can never trigger the tracematch at runtime, e.g. if we can prove that all iterators are checked for having a next element before they are advanced. We use the term shadow [15] to denote a program point corresponding to a runtime event of interest. If no shadows remain, the program satisfies the monitored property.. If shadows do remain, we identify potential points of failure. Such points may directly cause the tracematch body to execute, e.g. any next-shadow in the iterator example. Using a machine learning approach, we then classify each potential point of failure to determine whether or not it is a likely point of failure. The programmer can then inspect (B) the filtered list of likely points of failure, along with useful context information. In the future, we plan to provide a visualization tool that the programmer can use to browse (C) all potential points of failure in program code.. To enable the programmer to recover from runtime errors at points where errors are unlikely to occur (but are still possible), we provide an option to (D) generate an optimized instrumented program that includes runtime monitoring code only at points where our static analysis could not rule out potential matches statically. Because our approach is complete, this monitor catches all actual errors.. We have implemented our static analysis as an extension to the AspectBench Compiler [3] . We applied the analysis to 103 combinations of tracematches with SciMark2 [17] and the entire DaCapo benchmark suite [5] , and found that 38 of these combinations showed potential property violations. Our static analysis ruled out all potential points of failure in 50% of these cases; overall, it ruled out 75% of the potential points of failure. For all but 5 benchmark/tracematch combinations, fewer than 10 such points remained.. We found actual property violations in 5 cases. In Jython and bloat, this violation pointed out actual errors. In PMD, we found dubious code which was fixed in a later revision. Our machine learning algorithm correctly classified the remaining potential points of failure in all but 3 of 461 cases. The contributions of this paper include:. • an analysis abstraction for tracking runtime monitor states, including the information that an object is or is not in a certain state, along with. • a unified set of rules for manipulating the analysis abstraction based on static alias information; Figure 2 : Example program with shadows. • a machine learning algorithm to identify likely points of failure among potential points of failure; and. • an implementation of our static analyses and their evaluation on realistically-sized benchmark programs.. We next proceed with two introductory examples before explaining our static analysis approach in Section 3 and our classification approach using machine learning in Section 4. The evaluation follows in Section 5, followed by a discussion of related work and conclusions. We compare our work to software for anomaly detection, to typestate-based approaches and PQL, to another recent static analysis for tracematches, as well as a shape analysis and the restrict pointer annotation. We evaluated the effectiveness of our analysis and classification algorithm using the 99 combinations of nine tracematches with the ten benchmarks of the current version 2006-10-MR2 of the DaCapo benchmark suite [5] and with SciMark2 [17] . SciMark2 uses stopwatches to collect execution times and we applied four additional tracematches to validate the correct use of these stopwatches. Altogether this leads to a total of 103 tested tracematch/benchmark combinations. Table 2 briefly describes our tracematches.. For many of the 103 benchmark/tracematch combinations, the flow-insensitive analysis from previous work [7] detected that the tracematch never triggers. However, 38 combinations have remaining potential points of failure. We applied our flow-sensitive analysis and classification to these cases.

O O B O O O B O O B I O O O O O O O O B O O B O O O O O B B O O B O O O O O O O B B O O B I O O O B O O O O O O O O O B O O O B 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 B I O O B O O O O O O O O O O B I O O B O O B 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 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 B I B O O O O O B O O O O O O O O O O O O O B I B O O O O O O O B 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 B 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 B O B I 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 B 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 B I O O O B I B I 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 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 B I 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 B O O O O O O O O B O O O O O O B O O O B B O O O O O O O O B 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 B O O 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 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 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 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 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 B 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 B O O O 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 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 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 O O O O O O O O O O O O O O O O O O O O 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 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 B I O O O O O O O O O O O O B 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 B O O O O O O O B B O O O B B O O O O O O O B 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 I O O O O O O B O B O O O O O O O O O B O B 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 B O B O O O O O O O B O B B O O O B O O O B B 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 B I B O O O O O B I O O O O O O O O O O O O O B O O O B O O O O B 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 B O O O O O O O O O O O O O O O B I 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 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 B I B O O O O O O O B O O O O O O O O O O O B O O O B B O B B B 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 B B O O O O O O O O O B O O O O B I B O O O O O B O O O O B 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 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 B I O O O O O O O B 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 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 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 B O O O O B O O O O O


Theory, analysis and applications of 2D global illumination We investigate global illumination in 2D and show how this simplified problem domain leads to practical insights for 3D rendering.We first derive a full theory of 2D light transport by introducing 2D analogs to radiometric quantities such as flux and radiance, and deriving a 2D rendering equation. We use our theory to show how to implement algorithms such as Monte Carlo raytracing, path tracing, irradiance caching, and photon mapping in 2D, and demonstrate that these algorithms can be analyzed more easily in this domain while still providing insights for 3D rendering.We apply our theory to develop several practical improvements to the irradiance caching algorithm. We perform a full second-order analysis of diffuse indirect illumination, first in 2D, and then in 3D by deriving the irradiance Hessian, and show how this leads to increased accuracy and performance for irradiance caching. We propose second-order Taylor expansion from cache points, which results in more accurate irradiance reconstruction. We also introduce a novel error metric to guide cache point placement by analyzing the error produced by irradiance caching. Our error metric naturally supports anisotropic reconstruction and, in our preliminary study, resulted in an order of magnitude less error than the "split-sphere" heuristic when using the same number of cache points. Simulating the propagation of light within a virtual scene is a challenging problem. This transport is described by the rendering equation [Kajiya 1986 ], which states that the lighting arriving at any point on a surface in a scene depends on all other points in the scene. This definition results in an infinitely recursive and infinitely dimensional equation for computing global illumination.. While there are many approaches for solving the rendering equation numerically, each one has strengths and weaknesses. Unfortunately, theoretical and empirical analysis of these approaches can be very difficult, due to the mathematical and computational complexity inherent with the rendering equation in general and with any method in particular. Furthermore, this combined complexity makes it difficult for people to visualize, reason about, and grasp the underlying concepts that are present in the equations-making it more difficult to discover high-level structures in the system and to exploit them in solutions. In this article we present a theoretical framework to make this analysis and development more feasible.. A common recipe for dealing with such highly complex problems is to formulate a similar, but simplified problem which is easier to analyze, perform the necessary derivations or analysis, and then try to adapt the results to the original problem. We take this approach. We derive a full theory of light transport in 2D, examine this simplified formulation, and apply the resulting analysis to various practical situations in 3D light transport algorithms. A major benefit of this approach is that while the key problem remains intact, the underlying concepts and mathematical equations are greatly simplified; thus, they are easier to analyze and can be explored more efficiently. In the remainder of this article we first define our 2D world and derive a theory of light transport in 2D (Section 3). This builds upon 2D counterparts to common radiometric terms and results in the derivation of a 2D reflection and rendering equation. Based on this framework, we discuss in Section 4 how to implement a variety of global illumination algorithms in 2D and show examples of how this simplified domain allows for more intuitive analysis. In Section 5 we perform a first-and second-order analysis of global illumination in 2D. As a concrete use-case, we discuss several ways to apply these derivatives to irradiance caching in 2D (Section 6). In Section 7 we extend our second-order analysis of global illumination to 3D and demonstrate (Section 7) how this can be used to improve irradiance caching in a number of practical ways, including higher-order extrapolation, an improved error metric, and anisotropic reconstruction. We presented a comprehensive theory of 2D global illumination which allowed us to implement and easily analyze standard global illumination algorithms in 2D. We used our framework to perform a second-order analysis of global illumination and extended this analysis to obtain practical improvements for irradiance caching in 3D. We showed, for the first time, that a principled error metric derived from a second-order Taylor expansion of the irradiance provides practical benefits over the long-standing splitsphere heuristic. Our analysis suggests future work in a number of directions.. We performed derivations and initial analysis of our Hessianbased error metrics on simple scenes in 2D and 3D. We are confident that our initial exploration will result in a more practical irradiance caching algorithm after more careful analysis on a large collection of complex scenes. We leave this practical investigation as future work to our theoretical analysis.. Our process of extending 2D Hessians to 3D highlighted a previously overlooked issue in the stratified gradient formulation which prevents generalization to Hessians. Though our Hessian-based error metrics compare favorably to the split-sphere approaches, our 2D analysis shows that occlusion-aware Hessians could provide further improvements. We believe the most promising approach for obtaining an occlusion-aware Hessian is to consider the movement of the corners of each stratum instead of the edges. This was done previously for irradiance Jacobians for polygonal scenes [Arvo 1994] and Hessians of radiosity [Holzschuch and Sillion 1995, 1998 ]; [Holzschuch 1996] .. Our error metric computes radii by assuming a first-order Taylor expansion from cache points and using the second-order expansion only to approximate the remaining error. Though we found that second-order Taylor expansion provides some benefits in reconstruction error, care must be taken when computing the maximum radii to avoid overshooting the ground-truth solution. To use second-order expansion, the principled approach would be to derive a third-order derivative of the irradiance (a rank-2 tensor) to approximate the remaining error. Unfortunately, the resulting complexity would likely outweigh the advantages. Instead, we could naïvely use second-order expansion together with our radius calculation, though overshooting would need to be resolved. Investigating a practical solution for second-order expansion could be a promising avenue for future work.. Another avenue of future work could investigate different definitions of error minimized by the radius computation. We investigated a number of choices for error, including average error, average squared error, relative error, and integrated squared difference, but found that minimizing total error produced results with the lowest RMS error over the image. However, though we minimize total integrated error for each cache point, we reported the RMS error for the image. These two metrics are related but distinct. A exciting possibility for future work is to couple the error metric used to access the quality of the rendered image with the error threshold minimized by the radius computation. This could confirm that the radius calculation in fact minimizes the desired error over the image. It may also be possible to incorporate elements of perceptual error metrics such as visible difference predictors [Daly 1993] and structural similarity [Wang et al. 2004 ] directly into the radius calculation. Several previous researchers have considered the simplified 2D domain for some subset of light transport. Our work also extends existing work in global illumination and illumination gradients.

B 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 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 B O O O O O B O O O O O O O B I 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 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 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 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 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 B I 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 O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O 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 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 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 B I 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 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 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 B O O B I O O O O O O O O O B I B 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 O O O O O O O O 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 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 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 B I O O O