diogo
/
yap-6.3
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

typos 

git-svn-id: https://yap.svn.sf.net/svnroot/yap/trunk@1826 b08c6af1-5177-4d33-ba66-4b1c6b8b522a
This commit is contained in:
vsc 2007-03-10 19:45:00 +00:00
parent 570bce634d
commit 7917cbcac4
1 changed files with 5 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
docs/index/iclp07.tex
View File

@ -1189,13 +1189,13 @@ Table~\ref{tab:ilpmem} discusses the memory cost paid in using
execution. Because dynamic memory expands and contracts, we chose a execution. Because dynamic memory expands and contracts, we chose a
point where memory usage should be at a maximum. The first two numbers point where memory usage should be at a maximum. The first two numbers
show data usage on \emph{static} predicates. Static data-base sizes show data usage on \emph{static} predicates. Static data-base sizes
range from 146MB (\texttt{IE-Protein|_Extraction} to less than a MB range from 146MB (\texttt{IE-Protein\_Extraction} to less than a MB
(\texttt{Choline}, \texttt{Krki}, \texttt{Mesh}). Indexing code can be (\texttt{Choline}, \texttt{Krki}, \texttt{Mesh}). Indexing code can be
more than the original code, as in \texttt{Mutagenesis}, or almost as more than the original code, as in \texttt{Mutagenesis}, or almost as
much, eg, \texttt{IE-Protein\_Extraction}. In most cases the YAP \JITI much, eg, \texttt{IE-Protein\_Extraction}. In most cases the YAP \JITI
adds at least a third and often a half to the original data-base. A adds at least a third and often a half to the original data-base. A
more detailed analysis shows the source of overhead to be very more detailed analysis shows the source of overhead to be very
different from dataset to dataset. In \texttt{IE-Protein|_Extraction} different from dataset to dataset. In \texttt{IE-Protein\_Extraction}
the problem is that hash tables are very large. Hash tables are also the problem is that hash tables are very large. Hash tables are also
where most space is spent in \texttt{Susi}. In \texttt{BreastCancer} where most space is spent in \texttt{Susi}. In \texttt{BreastCancer}
hash tables are actually small, so most space is spent in hash tables are actually small, so most space is spent in
@ -1209,10 +1209,9 @@ The size of reflects the search space, and is to some extent
independent of the program's static data, although small applications independent of the program's static data, although small applications
such as \texttt{Krki} do tend to have a small search space. ALEPH's such as \texttt{Krki} do tend to have a small search space. ALEPH's
author very carefully designed the system to work around overheads in author very carefully designed the system to work around overheads in
accessing the data-base, so indexing should not be as important. In accessing the data-base, so indexing should not be as critical. The
fact, indexing has a much lower space overhead in this case, low overheads suggest that the \JITI is working well, as confirmed in
suggesting it is not so critical. A more detailed analysis shows tha a more detailed analysis: most space is spent on hashes tables and on
indexing is working well: most space is spent on hashes tables and on
internal nodes of tree, and relatively little space is spent on internal nodes of tree, and relatively little space is spent on
\TryRetryTrust chains. \TryRetryTrust chains.