From 033cf78870b08d03154c92de7d05187656d36571 Mon Sep 17 00:00:00 2001 From: Mike Demmer Date: Sat, 26 Mar 2005 01:30:45 +0000 Subject: [PATCH] more spelling fixes --- doc/paper2/LLADD.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/paper2/LLADD.tex b/doc/paper2/LLADD.tex index 063459a..98fb12d 100644 --- a/doc/paper2/LLADD.tex +++ b/doc/paper2/LLADD.tex @@ -387,7 +387,7 @@ and deployment efforts. \rcs{Potential conclusion material after this line in the .tex file..} %Section~\ref{sub:Linear-Hash-Table} -%validates the premise that the primatives provided by \yad are +%validates the premise that the primitives provided by \yad are %sufficient to allow application developers to easily develop %specialized-data structures that are competitive with, or faster than %general purpose primatives implemented by existing systems such as @@ -1406,7 +1406,7 @@ need a map from bucket number to bucket contents (lists), and we need to handle The simplest bucket map would simply use a fixed-size transactional array. However, since we want the size of the table to grow, we should -not assume that it fits in a contiguous range of pages. Insteed, we build +not assume that it fits in a contiguous range of pages. Instead, we build on top of \yad's transactional ArrayList data structure (inspired by Java's structure of the same name). @@ -1464,7 +1464,7 @@ for short lists, providing fast overflow bucket traversal for the hash table.} \end{figure} Given the map, which locates the bucket, we need a transactional -linked list for the contents of the bucket. The trivial implemention +linked list for the contents of the bucket. The trivial implementation would just link variable-size records together, where each record contains a $(key,value)$ pair and the $next$ pointer, which is just a $(page,slot)$ address. @@ -1476,7 +1476,7 @@ the list on the same page: thus we use a list of lists. The main list links pages together, while the smaller lists reside with that page. \yad's slotted pages allows the smaller lists to support variable-size values, and allow list reordering and value resizing -with a single log entry (since everthing is on one page). +with a single log entry (since everything is on one page). In addition, all of the entries within a page may be traversed without unpinning and repinning the page in memory, providing very fast @@ -1710,7 +1710,7 @@ significantly better than Berkeley DB's with both filesystems.} % %The final test measures the maximum number of sustainable transactions %per second for the two libraries. In these cases, we generate a -%uniform number of transactions per second by spawning a fixed nuber of +%uniform number of transactions per second by spawning a fixed number of %threads, and varying the number of requests each thread issues per %second, and report the cumulative density of the distribution of %response times for each case. @@ -1718,7 +1718,7 @@ significantly better than Berkeley DB's with both filesystems.} %\rcs{analysis / come up with a more sane graph format.} Finally, we developed a simple load generator which spawns a pool of threads that -generate a fixed number of requests per second. We then meaured +generate a fixed number of requests per second. We then measured response latency, and found that Berkeley DB and \yad behave similarly. @@ -1734,7 +1734,7 @@ define custom latching/locking semantics, and make use of, or implement a custom variant of nested top actions. The fact that our straightforward hashtable is competitive -with Berkeley BD shows that +with Berkeley DB shows that straightforward implementations of specialized data structures can compete with comparable, highly-tuned, general-purpose implementations. Similarly, it seems as though it is not difficult to implement specialized @@ -1753,7 +1753,7 @@ transactional systems. %This section uses: %\begin{enumerate} %\item{Custom page layouts to implement ArrayList} -%\item{Addresses data by page to perserve locality (contrast w/ other systems..)} +%\item{Addresses data by page to preserve locality (contrast w/ other systems..)} %\item{Custom log formats to implement logical undo} %\item{Varying levels of latching} %\item{Nested Top Actions for simple implementation.} @@ -2236,10 +2236,10 @@ is more expensive then making a recursive function call. We considered applying some of the optimizations discussed earlier in the paper to our graph traversal algorithm, but opted to dedicate this section to request reordering. Diff based log entries would be an -obvious benifit for this scheme, and there may be a way to use the +obvious benefit for this scheme, and there may be a way to use the OASYS implementation to reduce page file utilization. The request reordering optimization made use of reusable operation implementations -by borrowing ArrayList from the hashtable. It cleanly seperates wrapper +by borrowing ArrayList from the hashtable. It cleanly separates wrapper functions from implementations and makes use of application-level log manipulation primatives to produce locality in workloads. We believe these techniques can be generalized to other applications in future work.