March 2012 - Triton-commits - mailman3.cels.anl.gov

Triton-private Repository branch, master, updated. b7ff51ef65018ba738e7bbb658c78d883a020755
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via b7ff51ef65018ba738e7bbb658c78d883a020755 (commit) from 87d5e01a8135c10cc05e8a85f4e4127afd207958 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit b7ff51ef65018ba738e7bbb658c78d883a020755 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 23:17:57 2012 -0500 shorter abstract ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 19 ++++++++----------- 1 files changed, 8 insertions(+), 11 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index 7ed70bc..5e7e2e9 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -109,13 +109,11 @@ Argonne, IL 60439\\ \begin{abstract} High-performance computing (HPC) and distributed systems rely on a diverse collection of system software to provide application services, including file -systems, schedulers, web services, and fault detectors. Such system software +systems, schedulers, and web services. Such system software services must manage highly concurrent requests, interact with a wide range of resources, and scale well in order to be successful. Unfortunately, no single programming model for distributed system software currently offers -optimal performance and productivity for all these tasks. In addition, many -concurrent server architectures introduce software complexity that interferes -with algorithm development and hinders software maintenance and portability. +optimal performance and productivity for all these tasks. While numerous libraries, languages, and language extensions have been developed in recent years to simplify parallel computation, they do not address the challenges of distributed system software in which concurrency @@ -127,17 +125,16 @@ model designed to implement distributed system software with high development productivity and run-time efficiency. \aesop is a superset of the C language that describes blocks of code to be executed concurrently without dictating whether that concurrency will be provided by a threading, event, or other model. This -decoupling of algorithm description and run-time implementation enables system +decoupling enables system software to adjust to different architectures, device APIs, and workloads -without any change to the core algorithm implementation. \aesop also provides -a set of language constructs that enable more expressive control over -concurrent execution than is typically found in multithreaded or event-driven -programming models. +without any change to the core algorithm implementation. \aesop also +provides additional language constructs to simplify common system software +development tasks. -We evaluate \aesop by implementing a simple file server and comparing its +We evaluate \aesop by implementing a basic file server and comparing its performance, memory efficiency, and developer productivity with several thread-based and event-based implementations. \aesop is shown to provide -competitive -- and, in some cases, superior -- performance to traditional +competitive performance to traditional distributed system software development models while at the same time reducing code complexity and enhancing developer productivity. \end{abstract} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 87d5e01a8135c10cc05e8a85f4e4127afd207958
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via 87d5e01a8135c10cc05e8a85f4e4127afd207958 (commit) from db6ec9a44f89d90c79084fa36c4c74dde923efaf (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 87d5e01a8135c10cc05e8a85f4e4127afd207958 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Thu Mar 15 23:16:07 2012 -0500 remove lonely subsection ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/intro.tex | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index ffda69a..5640a1b 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -109,8 +109,6 @@ functionality that is not available in a traditional multithreaded or event-driven framework -- for example the ability to cleanly cancel outstanding operations. -\subsection{Summary of contributions} - The contributions of this paper can be summarized as follows: \begin{itemize} \item Description of a new programming model and language, \aesop, hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. db6ec9a44f89d90c79084fa36c4c74dde923efaf
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via db6ec9a44f89d90c79084fa36c4c74dde923efaf (commit) from 9b070a9efc8a20f089817238aba5042d9a518059 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit db6ec9a44f89d90c79084fa36c4c74dde923efaf Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 23:10:15 2012 -0500 shorten description of server implementations ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 23 ++++++++--------------- 1 files changed, 8 insertions(+), 15 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 3851a1b..b9803b4 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -101,27 +101,23 @@ pool with 4 threads. The thread-per-client server spawns a dedicated thread for each client connection. All requests for a given client are handled within the same thread. This model -uses synchronous socket operations and synchronous file read and write operations. -When the client disconnects, its associated thread is destroyed. +uses synchronous socket and file I/O functions. \paragraph*{Thread-per-client-nb} The thread-per-client-nb server is identical to the thread-per-client server except that it uses asynchronous socket calls in place of synchronous -socket calls. For example, in order to send a message, a thread will -perform asynchronous sends until it encounters the \code{EWOULDBLOCK} error code. -It then polls the socket until it is ready and continues sending data. -We implemented this version to investigate the possible performance difference -between the synchronous and asynchronous socket calls when -all other factors remain equal. +socket calls and uses \code{poll()} to determine when a socket can make +progress. +We implemented this version to isolate the performance difference resulting +from asynchronous socket access when all other factors remain equal. \paragraph*{Thread-per-operation} The thread-per-operation server uses an event loop to watch all client connections for activity. When a new request is available, a thread is -spawned, and the request is handled completely from within that thread. When -the request is complete, the thread is destroyed. Synchronous socket operations -and standard file read and write functions are used in this implementation. +spawned, and the request is handled completely from within that thread. +This implementation uses synchronous socket and file I/O functions. \paragraph*{Thread-pool} @@ -129,10 +125,7 @@ The thread-pool server is similar to the thread-per-operation server in that it uses an event loop to watch connected client connections for activity. However, instead of creating a new thread to service each active client, the connection is added to a queue. A fixed-size thread pool is used to service -the connections from the queue. The thread pool was implemented following -best practices for scalable condition-variable performance as described in -\cite{hp-cond-variable}. - +the connections from the queue. \paragraph*{Event} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 9b070a9efc8a20f089817238aba5042d9a518059
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via 9b070a9efc8a20f089817238aba5042d9a518059 (commit) from fccaeaf765f0475fa4f5937b213cfd25d83c3f39 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 9b070a9efc8a20f089817238aba5042d9a518059 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Thu Mar 15 23:10:13 2012 -0500 reduce code listing size ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index e605ae3..7ed70bc 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -24,7 +24,7 @@ captionpos=b, columns=fullflexible, morekeywords={__blocking,pwait,pbranch,pbreak}, numbers=left, -basicstyle=\footnotesize\ttfamily, +basicstyle=\scriptsize\ttfamily, breaklines=true, framexleftmargin=0em, boxpos=c, hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. fccaeaf765f0475fa4f5937b213cfd25d83c3f39
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via fccaeaf765f0475fa4f5937b213cfd25d83c3f39 (commit) from e3141bf06d0d66f18b588a8245d75acd22e6ab3e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit fccaeaf765f0475fa4f5937b213cfd25d83c3f39 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 23:02:21 2012 -0500 shorter description of request types ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 54 ++++++++++---------------------------- 1 files changed, 14 insertions(+), 40 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 51328d2..3851a1b 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -30,46 +30,20 @@ acknowledgment is received) in order to analyze individual request latency. %\subsubsection{Experiment - Test Cases} The protocol implemented by our test server recognizes four -requests. - -%There are four distinct test cases run against each server implementation. -%All file I/O is done using O\_DIRECT file access mode in order to bypass the -%Linux buffer cache and ensure that disk is involved in each I/O transfer. -%The number of requests and size of request were chosen to keep the -%total run time of each test case reasonable. - -\paragraph*{Read} - -The client sends a request containing a file name and a size. The server -then opens the file, reads the contents up to the size specified, and returns the -data to the client. All file I/O is performed using \code{O_DIRECT} mode, in -order to bypass the Linux buffer cache and to ensure that the storage device -is involved in each I/O transfer. For the read test, each client instance -sequentially issued sixteen 4 KiB requests. In order to avoid interference, each request -accessed a unique file. - -\paragraph*{Write} - -The write request is similar to the read request except that the client -provides the data to be written to the file. The server receives the data, -creates the file, writes the data (using \code{O_DIRECT}), and responds -to the client indicating the request completed successfully. As with the read -test, for the write test, each client issued sixteen requests, with each request -containing 4 KiB of data. With each request, a unique file was created. - -\paragraph*{Read-null} - -The read-null request is identical to a read request except that the actual -I/O operation is not performed. Instead, the server sends a response -consisting of undefined data. For the read-null test, each client issued -4,096 requests of 4 KiB each. - -\paragraph*{Write-null} - -Like the read-null request, the write-null request is the same as a write -request except that the server skips the actual I/O write. Even though the -client includes the data with the request, it is discarded by the server. For -the write-null test, each client issued 4,096 requests of 4 KiB each. +requests: write, read, write-null, and read-null. +In the write case, the server receives a request containing the file name, +access size, and a data payload. It creates the specified file, +writes the data (using \code{O_DIRECT}), and responds +to the client. The read case is similar to the write case, except that data +is read from the specified file and sent to the client. Write-null and +read-null are variants of write and read that perform no file access. The +write-null payload is simply discarded by the server, while the read-null +payload transmitted to the client consists of uninitialized memory. + +For write and read tests, the client test harness was configured such that +each client process generated 16 requests for 4 KiB of data each. For +write-null and read-null tests each client process generated 4,096 requests +for 4 KiB of data each. %\subsubsection{Experiment - Server Types} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. e3141bf06d0d66f18b588a8245d75acd22e6ab3e
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via e3141bf06d0d66f18b588a8245d75acd22e6ab3e (commit) from 39c867e5acefc0997dd79ff3cec9600c54c6b0e0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit e3141bf06d0d66f18b588a8245d75acd22e6ab3e Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 22:51:38 2012 -0500 cite less network references for common things ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/context.tex | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/context.tex b/papers/2011/aesop/context.tex index aab7885..e979ea3 100644 --- a/papers/2011/aesop/context.tex +++ b/papers/2011/aesop/context.tex @@ -256,15 +256,14 @@ the posting of multiple I/O operations without waiting for their completion. Network sockets offer multiple potential asynchronous APIs that follow the select/poll paradigm or an operating system specific variant. -InfiniBand~\cite{IBVerbs,balaji2006azc} offers a post/poll interface to +InfiniBand offers a post/poll interface to send/receive queues through the {\tt -libibverbs} API~\cite{ITAPI,RDMA_2010}. Myrinet~\cite{Myrinet_1995} provides a rich +libibverbs} API~\cite{IBVerbs}. Myrinet provides a rich API through the MX interface~\cite{MX_Guide_2006} that offers asynchronous -send/receive operations with test, probe, and callback registration. However, -straightforward use of the callbacks blocks the network progress thread. The +send/receive operations with test, probe, and callback registration. The IBM Deep Computing Messaging Framework (DCMF)~\cite{BGP_RMA_2008} primarily offers nonblocking calls for send/receive and one-sided put/get -communication. MPI-2~\cite{gropp1999ump,snir1995mcr} offers nonblocking +communication. MPI-2~\cite{gropp1999ump} offers nonblocking messaging calls for point-to-point communication. %% \color{red}PHC: the following paragraph needs some work. You can't hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 39c867e5acefc0997dd79ff3cec9600c54c6b0e0
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via 39c867e5acefc0997dd79ff3cec9600c54c6b0e0 (commit) from 5a84b5ad1e358b3407479c70bd241c5444431436 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 39c867e5acefc0997dd79ff3cec9600c54c6b0e0 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 22:46:13 2012 -0500 less verbose discussion of poll/epoll etc. ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/context.tex | 16 +++++----------- 1 files changed, 5 insertions(+), 11 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/context.tex b/papers/2011/aesop/context.tex index 6e3cd87..aab7885 100644 --- a/papers/2011/aesop/context.tex +++ b/papers/2011/aesop/context.tex @@ -254,10 +254,11 @@ the posting of multiple I/O operations without waiting for their completion. %File system services make heavy use of nonblocking APIs for both %network and disk access. -Network sockets offers multiple potential APIs, including nonblocking APIs -and polling. Use of InfiniBand~\cite{IBVerbs,balaji2006azc} through the {\tt -libibverbs} API offers a post/poll interface to send/receive -queues~\cite{ITAPI,RDMA_2010}. Myrinet~\cite{Myrinet_1995} provides a rich +Network sockets offer multiple potential asynchronous APIs that follow the +select/poll paradigm or an operating system specific variant. +InfiniBand~\cite{IBVerbs,balaji2006azc} offers a post/poll interface to +send/receive queues through the {\tt +libibverbs} API~\cite{ITAPI,RDMA_2010}. Myrinet~\cite{Myrinet_1995} provides a rich API through the MX interface~\cite{MX_Guide_2006} that offers asynchronous send/receive operations with test, probe, and callback registration. However, straightforward use of the callbacks blocks the network progress thread. The @@ -266,13 +267,6 @@ offers nonblocking calls for send/receive and one-sided put/get communication. MPI-2~\cite{gropp1999ump,snir1995mcr} offers nonblocking messaging calls for point-to-point communication. -Unix systems have traditionally offered the select/poll paradigm, in which -file descriptors are collected into a data structure; the waiting process then -makes a function call that does not return until some file descriptor makes -progress (or an exception occurs). Epoll~\cite{EPOLL_WWW}, available in -Linux, offers a similar model but is typically more scalable for large numbers -of file descriptors. - %% \color{red}PHC: the following paragraph needs some work. You can't %% actually use select, poll, or epoll on files in practice. Maybe %% just cut all of that and just point out the POSIX AIO stuff? There hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 5a84b5ad1e358b3407479c70bd241c5444431436
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via 5a84b5ad1e358b3407479c70bd241c5444431436 (commit) from 630554da980acddc578d008783ad45da64ea50c0 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 5a84b5ad1e358b3407479c70bd241c5444431436 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 22:40:32 2012 -0500 bibliography spacing hack ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 1 + papers/2011/aesop/bibspacing.sty | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 0 deletions(-) create mode 100644 papers/2011/aesop/bibspacing.sty Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index 18c3ab7..e605ae3 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -12,6 +12,7 @@ \usepackage{xspace} \usepackage[textsize=footnotesize]{todonotes} \usepackage{comment} +\usepackage{bibspacing} \graphicspath{{./}} \DeclareGraphicsExtensions{.pdf,.jpeg,.png} diff --git a/papers/2011/aesop/bibspacing.sty b/papers/2011/aesop/bibspacing.sty new file mode 100644 index 0000000..06e6190 --- /dev/null +++ b/papers/2011/aesop/bibspacing.sty @@ -0,0 +1,23 @@ +\newdimen\bibindent +\setlength\bibindent{1em} +\newdimen\bibspacing +\setlength\bibspacing\z@ +\renewenvironment{thebibliography}[1]{% + \section*{\refname + \@mkboth{\MakeUppercase\refname}{\MakeUppercase\refname}}% + \list{\@biblabel{\@arabic\c@enumiv}}% + {\settowidth\labelwidth{\@biblabel{#1}}% + \leftmargin\labelwidth + \listparindent-1em + \advance\leftmargin\labelsep + \itemsep\z@skip % should this be commented out? + \parsep\z@skip % should this be commented out? + \@openbib@code + \usecounter{enumiv}% + \let\p@enumiv\@empty + \renewcommand\theenumiv{\@arabic\c@enumiv}}% + \sloppy\clubpenalty4000\widowpenalty4000% + \sfcode`\.\@m} + {\def\@noitemerr + {\@latex@warning{Empty `thebibliography' environment}}% + \endlist} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 630554da980acddc578d008783ad45da64ea50c0
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via 630554da980acddc578d008783ad45da64ea50c0 (commit) from 66207d42846951a8d83b811a835342bfe4226101 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 630554da980acddc578d008783ad45da64ea50c0 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 22:36:56 2012 -0500 shorten text about C bindings to Aesop libraries ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/model.tex | 7 ++----- 1 files changed, 2 insertions(+), 5 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/model.tex b/papers/2011/aesop/model.tex index 4c47b1f..ab861f0 100644 --- a/papers/2011/aesop/model.tex +++ b/papers/2011/aesop/model.tex @@ -92,11 +92,8 @@ other blocking functions. Thence, the starting function of an \aesop program must be blocking. \aesop libraries form an exception to this rule. To simplify calling \aesop libraries from C and other languages, one can generate C function stubs for a -blocking \aesop function. These stubs can be either synchronous, in which case -the stub returns only after the blocking function completed, or asynchronous, -in which case the stub returns as soon as progress can no longer be made. -In order to handle completion in the latter case, a callback, called when the -blocking function completes, can be specified. +blocking \aesop function. These stubs provide either synchronous or +asynchronous bindings to \aesop libraries. % cancellation hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 66207d42846951a8d83b811a835342bfe4226101
by noreply＠mcs.anl.gov 15 Mar '12

15 Mar '12

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Triton-private Repository". The branch, master has been updated via 66207d42846951a8d83b811a835342bfe4226101 (commit) from 45933bc2e3817459b37c6fc12fe41e95eb9f3e63 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 66207d42846951a8d83b811a835342bfe4226101 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 22:33:45 2012 -0500 cut pvfs sm text that duplicates intro text ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 2 +- papers/2011/aesop/related.tex | 17 ++++------------- 2 files changed, 5 insertions(+), 14 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index a94e0ae..51328d2 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -249,7 +249,7 @@ write test is shown. \centering \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-lat.pdf} \caption{Write latency (1,024 clients).\label{fig:writelat}} -\vspace{-.15in} +\vspace{-.2in} \end{figure} \subsection{Memory Efficiency} diff --git a/papers/2011/aesop/related.tex b/papers/2011/aesop/related.tex index c33afaf..da68a03 100644 --- a/papers/2011/aesop/related.tex +++ b/papers/2011/aesop/related.tex @@ -21,21 +21,12 @@ The PVFS state machine model is essentially a formal framework for event-driven programming. This approach has proved successful in achieving high performance in large-scale production HPC environments~\cite{pvfs-bgp-sc09}, but it shares many of the same developer -productivity challenges found in other event-driven models. First, all -algorithms must be split into functions on boundaries according to the -location of asynchronous operations, rather than according to logical -functionality. Second, the state machine engine uses a fixed function -prototype for each state machine function, meaning that arguments are passed -between state functions via an opaque struct that is shared across the entire -state machine. This makes automatic dependency checking between states -impossible (e.g., did the previous state function set all of the struct fields -needed by the current state function?) and leads to a new class of bugs that -do not typically appear in traditional C code. Additionally, PVFS SMs perform -all non-asynchronous computation on a single core, which is an undesirable -model given the advent of many-core servers. Moreover, PVFS SM code does not +productivity challenges found in other event-driven models; +it disrupts control flow, requires programmers to perform stack +ripping, and utilizes only a single compute core to execute event handlers. +Moreover, PVFS SM code does not resemble traditional C code, making it difficult to reason about many development challenges. - These drawbacks introduce a learning curve for researchers and an additional maintenance workload for maintainers. In this work, we seek to learn from the lessons of PVFS SM development and present a programming model that provides hooks/post-receive -- Triton-private Repository

1 0