Abstract
Progress in Prolog applications requires ever better performance and scalability from Prolog implementation technology. Most modern Prolog systems are emulator-based. Best performance thus requires both good emulator design and good memory performance. Indeed, Prolog applications can often spend hundreds of megabytes of data, but there is little work on understanding and quantifying the interactions between Prolog programs and the memory architecture of modern computers. In a previous study of Prolog systems we have shown through simulation that Prolog applications usually, but not always, have good locality, both for deterministic and non-deterministic applications. We also showed that performance may strongly depend on garbage collection and on database operations. Our analysis left two questions unanswered: how well do our simulated results holds on actual hardware, and how much did our results depend on a specific configuration? In this work we use several simulation parameters and profiling counters to improve understanding of Prolog applications. We believe that our analysis is of interest to any system implementor who wants to understand his or her own system's memory performance.

Abstract

Abstract

Abstract
Large-scale applications that require executing very large numbers of tasks are only feasible through parallelism. In this work we present a system that automatically handles large numbers of experiments and data in the context of machine learning. Our system controls all experiments, including re-submission of failed jobs and relies on available resource managers to spawn jobs through pools of machines. Our results show that we can manage a very large number of experiments, using a reasonable amount of idle CPU cycles, with very little user intervention.

Abstract
Ensembles have proven useful for a variety of applications, with a variety of machine learning approaches. While Quinlan has applied boosting to FOIL, the widely-used approach of bagging has never been employed in ILP. Bagging has the advantage over boosting that the different members of the ensemble can be learned and used in parallel. This advantage is especially important for ILP where run-times often are high. We evaluate bagging on three different application domains using the complete-search ILP system, Aleph. We contrast bagging with an approach where we take advantage of the non-determinism in ILP search, by simply allowing Aleph to run multiple times, each time choosing "seed" examples at random.

Abstract