Search

Discusses several arguments on the need for more experimentation among computer scientists and practitioners. Why computer play a dominant role; Major difference of computer science from other sciences; Purpose of scientists for experimenting; Benefit of balance experiment in computer science; Defense of computer scientists against experimentation. INSET: How to experiment.

The article reports on the International Conference on Software Engineering (ICSE) 2003 held in Portland, Oregon. The article discusses three papers that were selected for representing the best of ICSE 2003. The first paper "Scaling Step Wise Refinement," by D. Batory, J.N. Sarvela and A. Rauschmayer, is about development of computer software. The second paper is "Fragment Class Analysis for Testing of Polymorphism in Java Software" by A. Rountev, A. Milanova and B.C. Ryder, and the third paper is "Modular Verification of Software Components in C," by S. Chaki, F. Clarke, A. Groce, S. Jha and H. Veith. These two papers concern validation of software. The article also names some persons who devoted their time and energy in organizing ICSE 2003. The author suggests that managing the complexity of modern software systems is a grand challenge. Throughout the conference, there were exhibits, posters and informal research demonstrations as well as an onsite newsletter describing memorable moments, humor and fascinating facts.

The article discusses a case study of parallelizing the Bzip2 program for multicore software engineering. Graduate computer science students participated, working in independent teams of two to parallelize Bzip2 in a competition. The strategies used by the teams are described, including the use of a mixture of OpenMP and PThreads. It indicates that parallelizing a sequential program might not be possible right way. Refactorings improve code modularity and remove unnecessary data dependencies.

Software design patterns package proven solutions to recurring design problems in a form that simplifies reuse. We are seeking empirical evidence whether using design patterns is beneficial. In particular, one may prefer using a design pattern even if the actual design problem is simpler than that solved by the pattern, i.e., if not all of the functionality offered by the pattern is actually required. Our experiment investigates software maintenance scenarios that employ various design patterns and compares designs with patterns to simpler alternatives. The subjects were professional software engineers. In most of our nine maintenance tasks, we found positive effects from using a design pattern: Either its inherent additional flexibility was achieved without requiring more maintenance time or maintenance time was reduced compared to the simpler alternative. In a few cases, we found negative effects: The alternative solution was less error-prone or required less maintenance time. Although most of these effects were expected, a few were surprising: A negative effect occurs although a certain application of the Observer pattern appears to be well justified and a positive effect occurs despite superfluous flexibility (and, hence, complexity) introduced by a certain application of the Decorator pattern. Overall, we conclude that, unless there is a clear reason to prefer the simpler solution, it is probably wise to choose the flexibility provided by the design pattern because unexpected new requirements often appear. We identify several questions for future empirical research. [ABSTRACT FROM AUTHOR]

Using design patterns is claimed to improve programmer productivity and software quality. Such improvements may manifest both at construction time (in faster and better program design) and at maintenance time (in faster and more accurate program comprehension). This paper focuses on the maintenance context and reports on experimental tests of the following question: Does it help the maintainer if the design patterns in the program code are documented explicitly (using source code comments) compared to a well-commented program without explicit reference to design patterns? Subjects performed maintenance tasks on two programs ranging from 360 to 560 LOC including comments. Both programs contained design patterns. The controlled variable was whether the use of design patterns was documented explicitly or not. The experiments thus tested whether pattern comment lines (PCL) help during maintenance if patterns are relevant and sufficient program comments are already present. It turns out that this question is a challenge for the experimental methodology: A setup leading to relevant results is quite difficult to find. We discuss these issues in detail and suggest a general approach to such situations. The experiment was performed with Java by 74 German graduate students and then repeated with C++ by 22 American undergraduate students. A conservative analysis of the results supports the hypothesis that pattern-relevant maintenance tasks were completed faster or with fewer errors if redundant design pattern information was provided. Redundant means that the information carried in pattern comments is also available in different form in other comments. The contribution of this article is twofold: It provides the first controlled experiment results on design pattern usage and it presents a solution approach to an important class of experiment design problems for experiments regarding documentation. [ABSTRACT FROM AUTHOR]

Finding optimal parameters for acceleration structures for raytracing is key to improved performance. Previous research has shown that a speedup of over 10% of rendering time is possible. Some parameters are interdependent which complicates the process of finding an optimal configuration. It is hence interesting to find them efficiently. Autotuning is an automatic optimization scheme able to search for optimal configurations and has been applied successfully to kD-trees in the past, which we apply today on BVHs. The more parameters to optimize, the more difficult it is to find optimal solutions. In this article, we analyze in detail the behavior of the parameters and their impact on acceleration structure building and rendering time. We show the interdependence and context sensitivity (i.e., scene, viewpoint) of the parameters. Based on the use case, this allows to target only crucial parameters. Convergence speed towards an optimal configuration is essential. To find better parameters, the autotuner needs to build the acceleration structure over and over, changing parameters every time. We introduce a hybrid model-based prediction and online autotuning method to address this issue. The prediction model allows for both instantaneous near-optimal configurations when inputs are known or similar, and efficient search of the configuration space when inputs are completely new. Online autotuning outperforms configurations recommended in literature by up to 11% median. The prediction model achieves 95% of the maximum speedup of the autotuner while reducing 90% of its overhead. Thus, hybrid online autonuning enables always-on tuning in ray tracing.