No abstract

Smartphone consumers, app developers, and even mobile systems researchers operate under the assumption that performance differences between identical smartphones should be small. Consumers pick a model to purchase and don't consider that the specific device they leave the store with may vary quite dramatically from the identical models it sat next to on the shelf. App rating systems typically collect the model from reviewers, but not more detailed informationagain, assuming that all instances of a particular model perform similarly. Even mobile systems researchers will conduct studies using small numbers of devices that fail to account or control for inherent differences between identical phones. Unfortunately seemingly-identical smartphones can in fact have very different performance characteristics. Note that we are not referring to differences in battery or Flash performance caused over time by wear. Inherent differences would separate two brand-new phones still in the original packaging. Our experiments show up to 20% performance and energy consumption differences between otherwise identical devices. These differences result from process variation in the manufacture of smartphone CPUs, which causes some CPUs to perform much more poorly than others. This paper explains the causes of this variation, measures its impacts, and discusses implications for smartphone researchers, software developers, and consumers.

One of the reasons programming mobile systems is so hard is the wide variety of environments a typical app encounters at runtime. As a result, in many cases only post-deployment user testing can determine the right algorithm to use, the rate at which something should happen, or when an app should attempt to conserve energy. Programmers should not be forced to make these choices at development time. Unfortunately, languages leave no way for programmers to express and structure uncertainty about runtime conditions, forcing them to adopt ineffective or fragile ad-hoc solutions.We introduce a new approach based on structured uncertainty through a new language construct: the maybe statement. maybe statements allow programmers to defer choices about app behavior that cannot be made at development time, while providing enough structure to allow a system to later adaptively choose from multiple alternatives. Eliminating the uncertainty introduced by maybe statements can be done in a large variety of ways: through simulation, split testing, user configuration, temporal adaptation, or machine learning techniques, depending on the type of adaptation appropriate for each situation. Our paper motivates the maybe statement, presents its syntax, and describes a complete system for testing and choosing from maybe alternatives.

No abstract

No abstract