Small changes.

git-svn-id: https://yap.svn.sf.net/svnroot/yap/trunk@1816 b08c6af1-5177-4d33-ba66-4b1c6b8b522a

docs/index/iclp07.tex

@@ -95,46 +95,49 @@
 
 \section{Introduction}
 %=====================
-The WAM~\cite{Warren83} has been both a blessing and a curse for
-Prolog systems. Its ingenious design has allowed implementors to get
-byte code compilers with decent performance --- it is not a fluke that
-most Prolog systems are still based on the WAM. On the other hand,
-\emph{because} the WAM gives good performance in many cases,
-implementors have felt reluctant to explore alternatives that
-drastically depart from its basic philosophy.
+The WAM~\cite{Warren83} has mostly been a blessing but occasionally
+also a curse for Prolog systems. Its ingenious design has allowed
+implementors to get byte code compilers with decent performance --- it
+is not a fluke that most Prolog systems are still based on the WAM. On
+the other hand, \emph{because} the WAM gives good performance in many
+cases, implementors have not incorporated in their systems many
+features that drastically depart from WAM's basic characteristics.
 %
-For example, first argument indexing makes sense for many Prolog
-applications. For applications accessing large databases though is
-clearly sub-optimal; for long time now, the database community has
-recognized that good indexing mechanisms are the basis for fast query
+For example, first argument indexing is sufficient for many Prolog
+applications. However, it is clearly sub-optimal for applications
+accessing large databases; for a long time now, the database community
+has recognized that good indexing is the basis for fast query
 processing.
 
 As logic programming applications grow in size, Prolog systems need to
 efficiently access larger and larger data sets and the need for any-
 and multi-argument indexing becomes more and more profound. Static
-generation of multi-argument indexing is one alternative. However,
-this alternative is often unattractive because it may drastically
-increase the size of the generated byte code unnecessarily. Static
-analysis techniques can partly address this concern, but in
+generation of multi-argument indexing is one alternative. The problem
+is that this alternative is often unattractive because it may
+drastically increase the size of the generated byte code and do so
+unnecessarily. Static analysis can partly address this concern, but in
 applications that rely on features which are inherently dynamic (e.g.,
 generating hypotheses for inductive logic programming data sets during
-runtime) they are inapplicable or grossly inaccurate. Another
-alternative, which has not been investigated so far, is to do flexible
-indexing on demand during program execution.
+runtime) static analysis is inapplicable or grossly inaccurate.
+Another alternative, which has not been investigated so far, is to do
+flexible indexing on demand during program execution.
 
-This is precisely what we advocate in this paper. More specifically,
-we present a minimal extension to the WAM that allows for flexible
+This is precisely what we advocate with this paper. More specifically,
+we present a small extension to the WAM that allows for flexible
 indexing of Prolog clauses during runtime based on actual demand. For
 static predicates, the scheme we propose is partly guided by the
 compiler; for dynamic code, besides being demand-driven by queries,
-the method needs to cater for code updates during runtime. In our
-experience these schemes pay off. We have implemented \JITI in two
-different Prolog systems (Yap and XXX) and have obtained non-trivial
-speedups, ranging from a few percent to orders of magnitude, across a
-wide range of applications. Given these results, we see very little
-reason for Prolog systems not to incorporate some form of indexing
-based on actual demand from queries. In fact, we see \JITI as only the
-first step towards effective runtime optimization of Prolog programs.
+the method needs to cater for code updates during runtime. Where our
+schemes radically depart from current practice is that they generate
+new byte code during runtime, in effect doing a form of just-in-time
+compilation. In our experience these schemes pay off. We have
+implemented \JITI in two different Prolog systems (Yap and XXX) and
+have obtained non-trivial speedups, ranging from a few percent to
+orders of magnitude, across a wide range of applications. Given these
+results, we see very little reason for Prolog systems not to
+incorporate some form of indexing based on actual demand from queries.
+In fact, we see \JITI as only the first step towards effective runtime
+optimization of Prolog programs.
 
 This paper is structured as follows. After commenting on the state of
 the art and related work concerning indexing in Prolog systems
@@ -231,11 +234,6 @@ support for indexing that the WAM provides, but we will extend this
 support with the technique of \JITI that we describe in the next
 sections.
 
-%\begin{itemize}
-%\item Just-In-Time and dynamic compilation techniques (VITOR, IS THERE
-%  ANYTHING FOR PROLOG?)
-%\end{itemize}
-
 
 \section{Indexing in the WAM} \label{sec:prelims}
 %================================================
@@ -853,6 +851,12 @@ simply be regenerated.
 
 \section{Demand-Driven Indexing of Dynamic Predicates} \label{sec:dynamic}
 %=========================================================================
+We have so far lived in the comfortable world of static predicates,
+where the set of clauses to index is fixed beforehand and the compiler
+can take advantage of this knowledge. Dynamic code introduces several
+complications. However, note that most Prolog systems do provide
+indexing for dynamic predicates. In effect, they already deal with
+these issues.
 
 
 \section{Performance Evaluation} \label{sec:perf}