Diff | EPFL Graph Search

diff est une commande Unix qui permet de comparer deux fichiers et d’en afficher les différences. Son utilisation typique consiste à calculer les changements entre une version d’un fichier et une version plus ancienne du même fichier. Diff affiche les changements ligne par ligne pour un fichier texte, mais ne gère pas toujours de façon conviviale la différence de Byte Order Mark. Les implémentations modernes prennent également en compte les fichiers binaires. La sortie est appelée un "diff", un patch, ou une rustine puisque la sortie permet de transformer le premier fichier binaire en le second par le programme Unix patch. Histoire La première version de diff a été livrée avec la d’Unix en 1974, elle avait été écrite par Douglas McIlroy. L’article de recherche a été publié en 1976 et coécrit avec James W. Hunt qui a développé un prototype initial de la commande. Diff peut être utilisé avec ed pour créer des scripts d’édition automatique. En 1985, Larry Wall a écrit un u

Striking a New Balance Between Program Instrumentation and Debugging Time

Ricardo Bianchini, Olivier Crameri, Willy Zwaenepoel

Although they are helpful in many cases, state-of-the-art bug reporting systems may impose excessive overhead on users, leak private information, or provide little help to the developer in locating the problem. In this paper, we explore a new approach to bug reporting that uses partial logging of branches to record the path leading to a bug. We use static and dynamic analysis (both in isolation and in tandem) to identify the branches that need to be logged. When a bug is encountered, the system uses symbolic execution along the partial branch trace to reproduce the problem and find a set of inputs that activate the bug. The partial branch log drastically reduces the number of paths that would otherwise need to be explored by the symbolic execution engine. We study the tradeoff between instrumentation overhead and debugging time using an open-source Web server, the diff utility, and four coreutils programs. Our results show that the instrumentation method that combines static and dynamic analysis strikes the best compromise, as it limits both the overhead of branch logging and the bug reproduction time. We conclude that our techniques represent an important step in improving bug reporting and making symbolic execution more practical for bug reproduction.

Acm Order Department, P O Box 64145, Baltimore, Md 21264 Usa2011

Quantifying the Performance Differences Between PVM and TreadMarks

Sandhya Dwarkadas, Willy Zwaenepoel

We compare two systems for parallel programming on networks of workstations: Parallel Virtual Machine (PVM) a message passing system, and TreadMarks, a software distributed shared memory (DSM) system. We present results for eight applications that were implemented using both systems. The programs are Water and Barnes-Hut from the SPLASH benchmark suite; 3-D FFT, Integer Sort (IS) and Embarrassingly Parallel (EP) from the NAS benchmarks; ILINK, a widely used genetic linkage analysis program; and Successive Over-Relaxation (SOR) and Traveling Salesman (TSP). Two different input data sets were used for five of the applications. We use two execution environments. The first is an 155 Mbps ATM network with eight Sparc-20 model 61 workstations; the second is an eight processor IBM SP/2. The differences in speedup between TreadMarks and PVM are dependent on the application, and, only to much a lesser extent, on the platform and the data set used. In particular, the TreadMarks speedup for six of the eight applications is within 15% of that achieved with PVM. For one application, the difference in speedup is between 15% and 30%, and for one application, the difference is around 50%. More important than the actual differences in speedups, we investigate the causes behind these differences. The cost of sending and receiving messages on current networks of workstations is very high, and previous work has identified communication costs as the primary source of overhead in software DSM implementations. The observed performance differences between PVM and TreadMarks are therefore primarily a result of differences in the amount of communication between the two systems. We identified four factors that contribute to the larger amount of communication in TreadMarks:1) extra messages due to the separation of synchronization and data transfer, 2) extra messages to handle access misses caused by the use of an invalidate protocol, 3) false sharing, and 4) d iff accumulation for migratory data. We have quantified the effect of the last three factors by measuring the performance gain when each is eliminated. Because the separation of synchronization and data transfer is a fundamental characteristic of the shared memory model, there is no way to measure its contribution to performance without completely deviating from the shared memory model. Of the three remaining factors, TreadMarks’ inability to send data belonging to different pages in a single message is the most important. The effect of false sharing is quite limited. Reducing diff accumulation benefits migratory data only when the diffs completely overlap. When these performance impediments are removed, all of the TreadMarks programs perform within 25% of PVM, and for six out of eight experiments, TreadMarks is less than 5% slower than PVM.

1997

Quantifying the Performance Differences Between PVM and TreadMarks

Sandhya Dwarkadas, Willy Zwaenepoel

1997