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

Triton-private Repository branch, master, updated. 40274578c7b6ea7c7b8575cb0c88bbdb891ebd63
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 40274578c7b6ea7c7b8575cb0c88bbdb891ebd63 (commit) from b4604689eab9de020ff2f8b89a7fc054a57da900 (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 40274578c7b6ea7c7b8575cb0c88bbdb891ebd63 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 20:45:03 2012 -0500 Gail edits: evaluation ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 210 +++++++++++++++++++------------------- 1 files changed, 107 insertions(+), 103 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index 4f3ffb2..e92b030 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -1,13 +1,12 @@ \label{section:evaluation} -To evaluate \aesop, we implemented a simple TCP network server using a number -of traditional techniques and libraries, and compared the resulting -implementations to the \aesop implementation of the server. We evaluated each -server implementation using three criteria: run time efficiency, memory efficiency +To evaluate \aesop, we implemented a simple TCP network server using traditional techniques and libraries and compared the resulting +implementations with the \aesop implementation of the server. We evaluated each +server implementation using three criteria: run-time efficiency, memory efficiency, and programmer productivity. Each of the servers implements the same request protocol and is evaluated -using the same client test harness. The client is a C program that uses TCP +by using the same client test harness. The client is a C program that uses TCP sockets to send messages to the server. It uses MPI to coordinate processes and generate a highly concurrent workload. @@ -30,70 +29,70 @@ acknowledgment is received) in order to analyze individual request latency. %\subsubsection{Experiment - Test Cases} -The protocol implemented by our test server recognizes four different +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 runtime of each test case reasonable. +%total run time of each test case reasonable. \paragraph*{Read} -The client sends a request containing a file name and a size. The server will -then open the file, read the contents up to the size specified and return the +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 +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 16 4 KiB requests. To avoid interference, each request +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 +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 finally reponds +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 our test, each client issued 16 requests each, with each request +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 +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 -4096 requests of 4 KiB each. +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 +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 4096 requests of 4 KiB each. +the write-null test, each client issued 4,096 requests of 4 KiB each. %\subsubsection{Experiment - Server Types} We implemented the same request protocol in multiple server daemons -in order to contrast different approaches to concurrent +in order to compare different approaches to concurrent request processing. Each server uses the same fundamental coding style to -the degree possible. One server is implemented using the \aesop language, +the degree possible. One server is implemented in the \aesop language, while all other servers are implemented in C. The pthread library was -used where thread support was needed, while the -libev~\cite{libev-web} library was used in all cases that required an -explicit event handling. A short summary of each server implementation follows -below. +used where thread support was needed; the +libev~\cite{libev-web} library was used in all cases that required +explicit event handling. A short summary of each server implementation +follows. %Each server is setup to report the VmHWM stat when the application exits. \paragraph*{\aesop} -The \aesop server is implemented using the \aesop programming language. A +The \aesop server is implemented by using the \aesop programming language. A {\em lonely pbranch} is used to service each client. All operations for a client are handled within a single pbranch. The socket and file operations are -performed with blocking \aesop functions that are provided by the \aesop +performed with blocking \aesop functions provided by the \aesop standard library. On this system, the underlying socket resource uses -non-blocking sockets in an event driven model, with up to 12 threads driving +nonblocking sockets in an event driven model, with up to 12 threads driving the event loops. The file resource uses synchronous I/O calls and a thread pool with 4 threads. @@ -107,74 +106,74 @@ When the client disconnects, its associated thread is destroyed. \paragraph*{Thread-per-client-nb} The thread-per-client-nb server is identical to the thread-per-client -server, except that is uses asynchronous socket calls in place of synchronous +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 in a scenario where +between the synchronous and asynchronous socket calls 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 +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. \paragraph*{Thread-pool} -The thread-pool server is similar to the thread-per-operation server, in that +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 +best practices for scalable condition-variable performance as described in \cite{hp-cond-variable}. \paragraph*{Event} -The event server uses an event loop not only to detect active connections, -but to service them as well. Each request processing step is executed from +The event server uses an event loop not only to detect active connections +but also to service them. Each request-processing step is executed from an event loop callback function. The event server uses asynchronous sockets -and asynchronous file I/O. Note that although this implementation does not use +and asynchronous file I/O. Note that although this implementation does not explicitly create or use threads, the operating system can internally still use multiple threads to drive both the network and disk. \par -All experiments were executed on the Fusion cluster managed by the Argonne -Laboratory Computing Resource Center (LCRC). Fusion is a IBM iDataPlex dx360 -M2 system. It features 320 compute nodes which each consist of two Intel -Nehalem 2.6 GHz Xeon processors and 36 GB of RAM. The compute nodes have hyper -threading disabled. The cluster has an InfiniBand QDR interconnect. Each +All experiments were executed on the Fusion cluster in the Argonne +Laboratory Computing Resource Center. Fusion is an IBM iDataPlex dx360 +M2 system. It features 320 compute nodes, consisting of two Intel +Nehalem 2.6 GHz Xeon processors and 36 GB of RAM. The compute nodes have +hyper-threading disabled. The cluster has an InfiniBand QDR interconnect. Each compute node also has a single SATA 7200 RPM hard disk for local scratch -storage. All disk IO was performed using the local scratch storage and +storage. All disk I/O was performed by using the local scratch storage and client/server communication was done over the IB network using IPoIB. We instantiated 16 clients processes per phyiscal node. The tests were executed -on 65 nodes, one server node and 1 to 64 client nodes. +on 65 nodes; one server node and 1 to 64 client nodes. -\subsection{Runtime Efficiency} +\subsection{Run-time Efficiency} Figure~\ref{fig:write} shows the overall run time of the concurrent write workload for each server implementation as the number of client processes -is scaled from 16 to 1024. In this graph we see that {\aesop} does not +is scaled from 16 to 1,024. In this graph we see that {\aesop} does not perform as well as the other servers for small workloads (delivering 79 -operations per second at the smallest scale, versus 132 ops/s seconds for the +operations per second at the smallest scale, versus 132 ops/s for the thread-per-op server). However, {\aesop} is the fastest server at the largest scale (136 ops/s versus 125 ops/s for the nearest competitors in thread-per-client and thread-per-client-nb). Figure~\ref{fig:read} shows the results of the read experiment. \aesop performs more favorably at small scale for this workload than in the -previously shown write workload. At the largest scale, \aesop completes the -test with 339 operations per second versus 354 ops/s for the fastest server +write workload. At the largest scale, \aesop completes the +test with 339 ops/s versus 354 ops/s for the fastest server (thread-pool), a 4.5\% difference. The event server performs -particularly poorly in all cases, ultimately running the largest scale test +particularly poorly in all cases, ultimately running the largest-scale test with only 212 ops/s. -The small scale results for \aesop may indicate that additional tuning +The small-scale results for \aesop may indicate that additional tuning is needed to improve latency for small test runs. The issue is likely isolated to the write path of the file I/O resource in the \aesop standard library, as we see asymmetric results in the read and write tests for \aesop @@ -186,99 +185,103 @@ write-null (Figure~\ref{fig:writenull}) and read-null (Figure~\ref{fig:readnull}) evaluation. We were unable to isolate a concrete reason for this discrepancy in profiling. One notable difference in the two implementations, however, is that the -thread-per-client server uses blocking socket operations, while the \aesop -socket resource uses non-blocking operations. Based on this observation, +thread-per-client server uses blocking socket operations, whereas the \aesop +socket resource uses nonblocking operations. Based on this observation, we implemented the -thread-per-client-nb server to isolate the impact of non-blocking socket +thread-per-client-nb server to isolate the impact of nonblocking socket operations on performance. The thread-per-client-nb implementation is identical to the thread-per-client implementation except that each socket -uses non-blocking operations and polling to transmit and receive data. As -seen in these tests, the use of non-blocking operations slows down the +uses nonblocking operations and polling to transmit and receive data. As +seen in these tests, the use of nonblocking operations slows the thread-per-client server to the point that it is practically equivalent to the \aesop server at scale. Another notable observation in these graphs is that the \aesop server is -competitive at small scale, and in fact is the fastest implementation in the -16 client process read-null test and nearly the fastest in the 16 client -process write-null test. This supports the observation from the previous +competitive at small scale and, in fact, is the fastest implementation in the +16-client-process read-null test and nearly the fastest in the +16-client-process write-null test. These results support the observation from the previous section that poor \aesop performance at small scale is likely a tuning flaw in the file resource used in the \aesop standard library, rather than a fundamental programming language problem. \begin{figure*}[ht] \centering % - \subfloat[Read performance]{ - \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-ops.pdf} - \label{fig:read} - } % \subfloat[Write performance]{ \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-ops.pdf} \label{fig:write} - \vspace{-2ex} } + \subfloat[Read performance]{ + \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-ops.pdf} + \label{fig:read} + \vspace{-2ex} + } % \par% \vspace{-2ex}% - \subfloat[Read-null performance]{ - \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-null-ops.pdf} - \label{fig:readnull} - } % \subfloat[Write-null performance]{ \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-null-ops.pdf} \label{fig:writenull} } % - \caption{Runtime performance for each test case.\\ + \subfloat[Read-null performance]{ + \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-null-ops.pdf} + \label{fig:readnull} + } % + \caption{Run-time performance for each test case.\\ \footnotesize (X-axis is the number of client instances, each graph has a distinct Y-axis.)} \end{figure*} The test client also measures the latency of each individual request and then -computes the minimum and maximum latency, the first quartile latency and third -quartile latency. The box represents the first and third quartiles and the +computes the minimum and maximum latency, the first quartile latency, and +the third +quartile latency. The box represents the first and third quartiles, and the whiskers are the minimum and maximum values. Figure~\ref{fig:writelat} shows -the request latency for 1024 clients in the case of the write test. From the -figure, it can be seen that the \aesop server implementation exhibits very -similar latency results when comparing to the other implementations. The -thread-per-op and event server variants perform significantly worse. As the +the request latency for 1,024 clients for the write test. From the +figure, one can see that the \aesop server implementation exhibits +similar latency results when compared to the other implementations. The +event server variant performs significantly worse, +however. In the event server case this is likely an artifact of the Linux +asynchronous I/O implementation. As the latency numbers for the other request types show similar results, only the write test is shown. \begin{figure}[ht] \centering \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-lat.pdf} - \caption{Write latency (1024 clients)\label{fig:writelat}} + \caption{Write latency (1,024 clients).\label{fig:writelat}} \end{figure} \subsection{Memory Efficiency} Another aspect of the overall performance is the memory efficiency of each server implementation. In this section we compare the memory usage of the -\aesop server to that of the other server implementations. The memory -utilization of each server was captured during the runtime performance +\aesop server with that of the other server implementations. The memory +utilization of each server was captured during the run-time performance experiments. We recorded the VmHWM stat from the server when the client test was completed. The VmHWM stat is a Linux-specific metric that represents the peak resident set size (RSS) of an executable, where RSS corresponds to the amount of paged-in memory used by the executable. In Figure~\ref{fig:writemem} we see that thread-pool manages to limit the -memory usage even though the client work load increases. This can be +memory usage even though the client work load increases. This result can be explained by the design of the thread-pool, which by limiting the number of active threads used to service client connections also limits the number of concurrent requests. For the other server implementations, memory usage -increases accordingly as the number of clients (and thus number of concurrent +increases accordingly as the number of clients (and thus the number of concurrent requests) increases. Although the \aesop server cannot match the thread-pool -server in terms of memory usage, it does compare favorably to the +server in terms of memory usage, it does compare favorably with the thread-per-client and thread-per-op servers. Note that the thread-per-client -and thread-per-op models consume virtual memory at a much larger rate due to +and thread-per-op models consume virtual memory at a much larger rate +because of the amount of virtual memory allocated to each thread stack. We chose not to -evaluate this metric, however, as the resident memory seems to be a more -relevant metric in practice. As the memory usage for remaining tests (read, -read-null and write-null) was very similar, only the write test results are +evaluate this metric, however, because the resident memory seems to be a more +relevant metric in practice. Since the memory usage for remaining tests (read, +read-null, and write-null) was similar, only the write test results are shown. \begin{figure}[ht] \centering \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-mem.pdf} - \caption{Write memory usage \label{fig:writemem}} + \caption{Write memory usage.\label{fig:writemem}} \end{figure} \subsection{Productivity} @@ -311,37 +314,38 @@ We approximate programmer productivity by measuring code complexity. Table~\ref{tab:complexity} compares the code complexity of each server implemenation using McCabe Cyclomatic Complexity (CC)~\cite{mccabe}, Modified McCabe Cyclomatic Complexity (mod. CC), and -Source Lines of Code (SLOC). The CC and Mod. CC metrics were measured -using the pmccabe tool, version 2.6, created by Paul Bame~\cite{pmccabe}, -while the SLOC metrics were measured using the sloccount tool, +Source Lines of Code (SLOC). The CC and Mod. CC metrics were measured by +using the pmccabe tool, version 2.6, created by Paul Bame~\cite{pmccabe}; +the SLOC metrics were measured using the sloccount tool, version 2.26, created by David A. Wheeler~\cite{sloccount}. -To simplify the comparison, all four servers had no error handling except -for assertions on expected return codes. The protocol definition (ie, -request and acknowledgement structs) as well as helper functions for sending -and receiving were not counted in any of the implementations, as these +In order to simplify the comparison, all four servers had no error handling except +for assertions on expected return codes. The protocol definition (i.e., +request and acknowledgment structs) as well as helper functions for sending +and receiving were not counted in any of the implementations, since these were similar in all four. -The \aesop and thread implementation are very similar in terms of complexity, +The \aesop and thread implementation are similar in terms of complexity, with the slight increase in the thread model due to function calls needed to create and join threads. The thread pool and event model implementation are both much more complex than -the thread or \aesop model. An additional complexity of the event model which -is not captured by these metrics is the fact that control flow is not +the thread or \aesop model. An additional complexity of the event model +that +is not captured by these metrics is that control flow is not preserved across the processing of a given request. For example, servicing a -write operation requires 5 disconnected event handlers. So although the event +write operation requires five disconnected event handlers. Therefore, although the event model appears less complex according to CC and mod. CC, qualitatively it is significantly more challenging to develop. Another productivity aspect that is not well captured by the complexity -metrics is how easy it is to retarget our example server to a new architecture +metrics is how easily our example server can be retargeted to a new architecture or system. In our initial testing, we wanted to tune the \aesop server implementation to perform well on a few test systems. During this testing we -tried different strategies (event based, threads and hybrid models) for +tried different strategies (event based, threads, and hybrid models) for sending and receiving network data, we experimented with multiple threads -driving \aesop and we evaluated different I/O APIs. All of these changes were -done within the \aesop runtime library and never required changing the \aesop +driving \aesop, and we evaluated different I/O APIs. All these changes were +done within the \aesop run-time library and never required changing the \aesop server test code. This type of flexibility allows experimentation to determine the best tuning strategy for any given system without having to redesign the core software algorithms. @@ -363,9 +367,9 @@ actually resembles the event based code. As such, a single thread suffices to handle multiple connections concurrently. \end{comment} -The example server used for evaluation is very simple and differs from real -world code by the absence of error handling, time-out handling and request -throttling. As shown in section~\ref{sec:example}, \aesop provides powerful +The example server used for evaluation is simple and differs from real-world +code by the absence of error handling, time-out handling, and request +throttling. As shown in Section~\ref{sec:example}, \aesop provides powerful primitives to simplify time-out and other error handling. The same cannot be said of the event or threaded models, since neither model offers any help in cancelling an outstanding operation. hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. b4604689eab9de020ff2f8b89a7fc054a57da900
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 b4604689eab9de020ff2f8b89a7fc054a57da900 (commit) from 4d3901fd773a02d30244926d7d65bcf7222f53b6 (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 b4604689eab9de020ff2f8b89a7fc054a57da900 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 20:14:52 2012 -0500 Gail edits: conclusions ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/conclusion.tex | 23 +++++++++++------------ 1 files changed, 11 insertions(+), 12 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/conclusion.tex b/papers/2011/aesop/conclusion.tex index 2f7c015..2183874 100644 --- a/papers/2011/aesop/conclusion.tex +++ b/papers/2011/aesop/conclusion.tex @@ -4,24 +4,23 @@ In this work we have introduced a new programming model and programming language, known as \aesop. \aesop was designed with the explicit goal of supporting distributed system software development. Its primary advantage is that it allows system software developers to express concurrency without -dictating the model (for example threads or event handling) used to provide -that concurrency. It also provides a number of language constructs -simplifying common system software development patterns. Numerous languages +dictating the mechanism used to provide +that concurrency. It also provides a number of language constructs that +simplify common system software development patterns. Numerous languages and language extensions have been developed in recent years to simplify parallel computation, but \aesop is unique in that it addresses the challenges of distributed system software in which concurrency control goes beyond -computational resources but also includes a variety of hardware and +computational resources to include a various hardware and network devices. Using a simple network server for evaluation, we demonstrate that \aesop -offers competitive, and in some cases superior, runtime performance to the +offers competitive, and in some cases superior, run-time performance to the most common system software concurrency models in use today. When considering -programmer productivity, \aesop performs equally well, mainly due to the fact -that is has been specifically designed to implement highly scalable +programmer productivity, \aesop performs equally well, mainly because it has been specifically designed to implement highly scalable distributed services. We expect \aesop to continue to perform well at even larger scales than those -evaluated in this study due to the fact that it does not rely on mapping +evaluated in this study because it does not rely on mapping concurrent execution paths to dedicated operating system threads. We have also found that the \aesop language reduces code complexity while also offering advanced primitives such as cancellation of execution paths and @@ -30,12 +29,12 @@ development environment. We will continue to evaluate and evolve the \aesop language as we use it to implement future production HPC storage services. As part of this -work we will likely extend the language to include additional features. -One example, which exists in prototype form already, is remote procedure -call (RPC) framework that uses \aesop to manage concurrent communication, +work we plan to extend the language to include additional features. +One example, which exists in prototype form already, is a remote procedure +call framework that uses \aesop to manage concurrent communication, timeout, and retry functionality in a transparent manner. We also plan to improve debugging functionality by providing mechanisms to trace control -flow through \aesop blocking functions. This will allow us to generate +flow through \aesop blocking functions. These will allow us to generate more meaningful stack traces that map directly to the original \aesop code rather than the underlying C code that it has been translated to. hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 4d3901fd773a02d30244926d7d65bcf7222f53b6
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 4d3901fd773a02d30244926d7d65bcf7222f53b6 (commit) from 3b68f7c4588856745516e08a3ec29dfb39aa8dff (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 4d3901fd773a02d30244926d7d65bcf7222f53b6 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 20:11:03 2012 -0500 Gail edits: acknowledgements ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index 830314d..fd457a1 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -168,11 +168,10 @@ code complexity and enhancing developer productivity. %The authors would like to thank the Peops. % -This work was supported by the Mathematical, Information, and Computational -Sciences Division subprogram of the Office of Advanced Scientific Computing +This work was supported by the Office of Advanced Scientific Computing Research, Office of Science, U.S. Dept. of Energy, under Contract DE-AC02-06CH11357. We gratefully acknowledge the computing resources provided -on "Fusion," a 320-node computing cluster operated by the +on ``Fusion,'' a 320-node computing cluster operated by the Laboratory Computing Resource Center at Argonne National Laboratory. % trigger a \newpage just before the given reference hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 3b68f7c4588856745516e08a3ec29dfb39aa8dff
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 3b68f7c4588856745516e08a3ec29dfb39aa8dff (commit) from b9d29efc86c8da3e25de71f36b7b69008b79e8a6 (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 3b68f7c4588856745516e08a3ec29dfb39aa8dff Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 20:09:07 2012 -0500 fix bibtex - edits from Gail - use proper url formatting - eliminate urls from citations that don't need them ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.bib | 65 ++++++++++++++++++++++-------------------- 1 files changed, 34 insertions(+), 31 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.bib b/papers/2011/aesop/aesop.bib index f0e24e4..272cccf 100644 --- a/papers/2011/aesop/aesop.bib +++ b/papers/2011/aesop/aesop.bib @@ -15,9 +15,9 @@ } @conference{balaji2006azc, - title={{Asynchronous Zero-copy Communication for Synchronous Sockets in the Sockets Direct Protocol (SDP) over InfiniBand}}, + title={Asynchronous Zero-copy Communication for Synchronous Sockets in the Sockets Direct Protocol {(SDP)} over {InfiniBand}}, author={Balaji, P. and Bhagvat, S. and Jin, HW and Panda, DK}, - booktitle={Proc. Workshop Comm. Architecture for Clusters (CAC 06), IEEE CS Press}, + booktitle={Proceedings of the Workshop Comm. Architecture for Clusters (CAC 06), IEEE CS Press}, year={2006} } @@ -25,14 +25,14 @@ title={{MPI: The Complete Reference}}, author={Snir, M. and Otto, S.W. and Walker, D.W. and Dongarra, J. and Huss-Lederman, S.}, year={1995}, - publisher={MIT Press Cambridge, MA, USA} + publisher={MIT Press, Cambridge, MA} } @book{gropp1999ump, title={{Using MPI: Portable Parallel Programming with the Message Passing Interface}}, author={Gropp, W. and Lusk, E. and Skjellum, A.}, year={1999}, - publisher={MIT Press} + publisher={MIT Press, Cambridge, MA} } @manual{postgresAsync, @@ -107,29 +107,29 @@ @misc{cuda-web, title = {{CUDA} Zone}, author = {{Nvidia Corporation}}, - howpublished = {http://www.nvidia.com/object/cuda\_home.html} + url = {http://www.nvidia.com/object/cuda\_home.html} } @misc{pvfs-web, title = {{The Parallel Virtual File System}}, - howpublished = {http://www.pvfs.org} + url = {http://www.pvfs.org} } @misc{gcd-web, title = {Grand Central Dispatch}, - howpublished = {http://developer.apple.com/technologies/mac/snowleopard/gcd.html}, + url = {http://developer.apple.com/technologies/mac/snowleopard/gcd.html}, author = {{Apple Inc.}} } @misc{libevent-web, - howpublished = {http://monkey.org/~provos/libevent/}, + url = {http://monkey.org/~provos/libevent/}, author = { Nick Mathewson and Niels Provos}, title = {libevent - an event notification library} } @misc{libev-web, - howpublished={http://software.schmorp.de/pkg/libev.html}, + url={http://software.schmorp.de/pkg/libev.html}, author={ Marc Lehmann}, title = {libev} } @@ -147,29 +147,28 @@ author = {Chandra, Robit and Dagum, Leonardo and Kohr, Dave and Maydan, Dror and title = {Parallel programming in OpenMP}, year = {2001}, isbn = {1-55860-671-8}, -publisher = {Morgan Kaufmann Publishers Inc.}, -address = {San Francisco, CA, USA}, +publisher = {Morgan Kaufmann}, +address = {San Francisco, CA}, } @inproceedings{Charles:2005:XOA:1094811.1094852, author = {Charles, Philippe and Grothoff, Christian and Saraswat, Vijay and Donawa, Christopher and Kielstra, Allan and Ebcioglu, Kemal and von Praun, Christoph and Sarkar, Vivek}, title = {X10: an object-oriented approach to non-uniform cluster computing}, -booktitle = {Proceedings of the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications}, +booktitle = {Proceedings of the 20th annual ACM SIGPLAN conference on Object-Oriented Programming, Systems, Languages, and Applications}, series = {OOPSLA '05}, year = {2005}, isbn = {1-59593-031-0}, location = {San Diego, CA, USA}, pages = {519--538}, numpages = {20}, -url = {http://doi.acm.org/10.1145/1094811.1094852}, doi = {http://doi.acm.org/10.1145/1094811.1094852}, acmid = {1094852}, publisher = {ACM}, -address = {New York, NY, USA}, +address = {New York}, } @techreport{upc-intro, -title={Introduction to UPC and Language Specification}, +title={Introduction to {UPC} and Language Specification}, author={Carlson,W and Draper,J.M and Culler,D.E and Yelick,K and Brooks,E and Warren,K}, year={1999}, number={{CCS-TR}-99-157}, @@ -178,7 +177,7 @@ institution={{IDA} Center for Computing Sciences} @article{Chamberlain:2007:PPC:1286120.1286123, author = {Chamberlain, B.L. and Callahan, D. and Zima, H.P.}, -title = {Parallel Programmability and the Chapel Language}, +title = {Parallel Programmability and the {Chapel} Language}, journal = {Int. J. High Perform. Comput. Appl.}, volume = {21}, issue = {3}, @@ -187,7 +186,6 @@ year = {2007}, issn = {1094-3420}, pages = {291--312}, numpages = {22}, -url = {http://portal.acm.org/citation.cfm?id=1286120.1286123}, doi = {10.1177/1094342007078442}, acmid = {1286123}, publisher = {Sage Publications, Inc.}, @@ -198,7 +196,7 @@ keywords = {Chapel, parallel languages, parallel programming, productivity, prog @techreport{fortress, author = {Eric Allen and David Chase and Joe Hallett and Victor Luchangco and Jan-Willem Maessen and Sukyoung Ryu and Guy L. Steele Jr. and Sam Tobin-Hochstadt}, institution = {Sun Microsystems, Inc.}, -title = {{The Fortress Language Specification}}, +title = {The {Fortress} language specification}, url = {http://research.sun.com/projects/plrg/Publications/fortress1.0beta.pdf}, year = 2007, } @@ -317,49 +315,54 @@ year = 2008 @MISC{EPOLL_WWW, title = {/dev/epoll web site}, author = {D. Libenzi}, - note = {http://www.xmailserver.org/linux-patches/nio-improve.html}, + url = {http://www.xmailserver.org/linux-patches/nio-improve.html}, } @MISC{apache-threads, title = {Apache {MPM} worker documentation}, - howpublished = {http://httpd.apache.org/docs/2.0/mod/worker.html} + url = {http://httpd.apache.org/docs/2.0/mod/worker.html} } @MISC{memcached-threads, title = {Multithreading support in Memcached}, - howpublished = {http://code.sixapart.com/svn/memcached/trunk/server/doc/threads.txt} + url = {http://code.sixapart.com/svn/memcached/trunk/server/doc/threads.txt} } @MISC{hp-cond-variable, author = {Hewlet Packard Development Company L.P}, title = {Techniques for Improving the Scalability of Applications Using POSIX Thread Condition Variables.}, - howpublished = {http://h21007.www2.hp.com/portal/download/files/unprot/hpux/MakingConditionVariablesPerform.pdf} + url = {http://h21007.www2.hp.com/portal/download/files/unprot/hpux/MakingConditionVariablesPerform.pdf} } -@INPROCEEDINGS{mccabe, - author = {McCabe, T.J}, - title = {A Complexity Measure}, - booktitle = {IEEE Transactions on Software Engineering, vol.SE-2, no.4}, - year = {1976}, +@article{mccabe, +author = {T.J. McCabe}, +title = {A Complexity Measure}, +journal ={IEEE Transactions on Software Engineering}, +volume = {2}, +issn = {0098-5589}, +year = {1976}, +pages = {308-320}, +doi = {http://doi.ieeecomputersociety.org/10.1109/TSE.1976.233837}, +publisher = {IEEE Computer Society}, +address = {Los Alamitos, CA, USA}, } - @Comment pages = {308--320}, @MISC{pmccabe, author = {Paul Bame}, title = {pmccabe}, - howpublished = {http://parisc-linux.org/~bame/pmccabe/} + url = {http://parisc-linux.org/~bame/pmccabe/} } @MISC{sloccount, author = {David A. Wheeler}, title = {sloccount}, - howpublished = {http://www.dwheeler.com/sloc/} + url = {http://www.dwheeler.com/sloc/} } @INPROCEEDINGS{BDB_1999, author = {Olson, Michael A. and Bostic, Keith and Seltzer, Margo}, title = {Berkeley DB}, - booktitle = {Proc. USENIX}, + booktitle = {Proceedings of USENIX}, year = {1999}, } @Comment location = {Monterey, California}, hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. b9d29efc86c8da3e25de71f36b7b69008b79e8a6
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 b9d29efc86c8da3e25de71f36b7b69008b79e8a6 (commit) from 6946ec275571949bd0389084115d72098bc3425b (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 b9d29efc86c8da3e25de71f36b7b69008b79e8a6 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Thu Mar 15 18:33:59 2012 -0500 fix ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/intro.tex | 15 +++++++++------ 1 files changed, 9 insertions(+), 6 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index 1864482..9929ec8 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -67,13 +67,13 @@ activity and avoids the use of operating system threads to express logical concurrency. Any number of client requests can be tracked and serviced without explicitly allocating a thread to each request. There are drawbacks to this model as well, however. Event-driven architectures break the logical control -flow of software algorithms into into disjoint segments at each point where +flow of software algorithms into disjoint segments at each point where the algorithm interacts with an asynchronous device or operating system service. In effect, it turns the single linear control flow for an algorithm into a state machine with several independent states. Because these states are invoked from a centralized event handler, their interfaces must be -consistent and generalized. This makes it difficult to verify dependencies or -perform type checking between states. Per-request state has to be managed +consistent and generalized, making it difficult to verify design constraints. +Per-request state has to be managed manually by the programmer, often referred to as {\em stack ripping}~\cite{krohn2007ecm}. Pure event-driven models also do not directly address the requirement of multi-core architectures or high performance @@ -82,14 +82,17 @@ Event-driven servers therefore tend to evolve during the development process to take on characteristics of both event-driven and multithreaded services in order to compensate for these issues. -In general there is no clear-cut metric that can be used to identify the best +In general, there is no clear-cut metric that can be used to identify the best concurrent programming model for a given system software project, yet this decision affects every aspect of the design from algorithm implementation to device management. In order to help address this problem, we propose a new programming language and programming model, \aesop, that targets the software engineering challenges associated with developing distributed system software. -Its goal is to improve programmer productivity and architecture flexibility -without compromising the execution efficiency. +Its goal is to improve programmer productivity by presenting a convenient +model for developing distributed system software. The model isolates the +developer from how concurrency is managed, but maintains execution efficiency +by being able to \aesop code to the optimal concurrency model required by the +system or device. \aesop is a superset of the C language. It describes blocks of code that can be executed asynchronously or concurrently, without dictating whether those hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 6946ec275571949bd0389084115d72098bc3425b
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 6946ec275571949bd0389084115d72098bc3425b (commit) from e606bf8f186b91e97df8f571791689c2d199d800 (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 6946ec275571949bd0389084115d72098bc3425b Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Thu Mar 15 17:29:48 2012 -0500 fix ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/intro.tex | 15 ++++++++------- 1 files changed, 8 insertions(+), 7 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index a043005..1864482 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -16,7 +16,7 @@ software engineering requirements: \item maintainable code for complex distributed algorithms, \item portability across diverse architectures, \item management of concurrent operations across multiple hardware devices, -\item and maximum performance on multiple platforms +\item and maximum performance on multiple platforms. \end{itemize} Further complicating matters is the fact that system software services must @@ -42,18 +42,19 @@ produces a natural control flow in algorithm implementations because each thread executes sequentially and issues simple blocking device operations. Thread scheduling and stack management are handled by the operating system. Threads also provide a clear model to express concurrency. There are a number -of challenges to building a multi-threaded service, however. The first is -that it is not always intuitive how to best provision thread resources; For +of challenges to building a multithreaded service, however. The first is +that it is not always intuitive how to best provision thread resources; for network services, threads can be assigned per client, per request, or per underlying device operation, and they may be created on demand or allocated from an existing pool. Each technique or combination of techniques presents tradeoffs in scalability, performance, and readability. Yet it is difficult to -transition between them during the development process. The second challenge +transition between techniques during the development process. The second challenge is the disconnect between the number of threads needed to express logical concurrency and the number of threads needed to make optimal use of local -resources. For example, even if there are 1,000 client requests in flight at -once, the server may have only a few processing cores and a storage device -that can only effectively handle a few operations at a time. This disconnect +resources. For example, the optimal number of concurrent operations for a +storage device will be distinct from the optimal number of threads per +processor core. +This disconnect can cause a seemingly simple thread model to evolve into a more complex framework when taking local resource scheduling constraints into account. hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. e606bf8f186b91e97df8f571791689c2d199d800
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 e606bf8f186b91e97df8f571791689c2d199d800 (commit) from a96e811cdc9cb2069894ae4f04c9fde614b23805 (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 e606bf8f186b91e97df8f571791689c2d199d800 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Thu Mar 15 17:18:20 2012 -0500 fix ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 4 ++-- papers/2011/aesop/intro.tex | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index b77dfc2..830314d 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -115,7 +115,7 @@ no single programming model for distributed system software that 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. -While numerous libraries, languages and language extensions have been +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 control involves a variety of hardware and network devices, not just @@ -125,7 +125,7 @@ In this work we present \aesop, a new programming language and programming 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 if -that concurrency will be provided by a threading, event or other model. This +that concurrency will be provided by a threading, event, or other model. This decoupling of algorithm description and run time implementation enables system software to adjust to different architectures, device APIs, and workloads without any change to the core algorithm implementation. \aesop also provides diff --git a/papers/2011/aesop/intro.tex b/papers/2011/aesop/intro.tex index 9f33301..a043005 100644 --- a/papers/2011/aesop/intro.tex +++ b/papers/2011/aesop/intro.tex @@ -40,7 +40,7 @@ Multithreading is popular for several reasons. First and foremost, this model is widely used and therefore well understood in the development community. It produces a natural control flow in algorithm implementations because each thread executes sequentially and issues simple blocking device operations. -Thread scheduling and stack management is handled by the operating system. +Thread scheduling and stack management are handled by the operating system. Threads also provide a clear model to express concurrency. There are a number of challenges to building a multi-threaded service, however. The first is that it is not always intuitive how to best provision thread resources; For hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. a96e811cdc9cb2069894ae4f04c9fde614b23805
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 a96e811cdc9cb2069894ae4f04c9fde614b23805 (commit) via bee87c37722fcf70642f1f1478ff2c71609b4618 (commit) from 0fbd672fd92e61504bfed378098747a8480c0dd0 (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 a96e811cdc9cb2069894ae4f04c9fde614b23805 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Thu Mar 15 17:13:12 2012 -0500 Align figures, fix font, compress whitespace commit bee87c37722fcf70642f1f1478ff2c71609b4618 Author: Dries Kimpe <dkimpe(a)mcs.anl.gov> Date: Thu Mar 15 17:04:26 2012 -0500 Slight change in figure size ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/evaluation.tex | 16 +++++++++------- papers/2011/aesop/fig/Makefile | 4 ++-- papers/2011/aesop/fig/read-null-ops.gnuplot | 2 +- papers/2011/aesop/fig/read-ops.gnuplot | 2 +- papers/2011/aesop/fig/write-null-ops.gnuplot | 2 +- papers/2011/aesop/fig/write-ops.gnuplot | 2 +- 6 files changed, 15 insertions(+), 13 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/evaluation.tex b/papers/2011/aesop/evaluation.tex index f799673..4f3ffb2 100644 --- a/papers/2011/aesop/evaluation.tex +++ b/papers/2011/aesop/evaluation.tex @@ -206,27 +206,29 @@ in the file resource used in the \aesop standard library, rather than a fundamental programming language problem. \begin{figure*}[ht] - \centering + \centering % \subfloat[Read performance]{ \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-ops.pdf} \label{fig:read} - } + } % \subfloat[Write performance]{ \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-ops.pdf} \label{fig:write} + \vspace{-2ex} } - + \par% + \vspace{-2ex}% \subfloat[Read-null performance]{ \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/read-null-ops.pdf} \label{fig:readnull} - } + } % \subfloat[Write-null performance]{ \includegraphics[keepaspectratio,width=0.45\textwidth]{fig/write-null-ops.pdf} \label{fig:writenull} - } + } % \caption{Runtime performance for each test case.\\ -\footnotesize x-axis is the number of client instances.\\ -\footnotesize (Each graph has a distinct y-axis)} + \footnotesize (X-axis is the number of client instances, each graph has + a distinct Y-axis.)} \end{figure*} The test client also measures the latency of each individual request and then diff --git a/papers/2011/aesop/fig/Makefile b/papers/2011/aesop/fig/Makefile index 66d9db0..2d50f20 100644 --- a/papers/2011/aesop/fig/Makefile +++ b/papers/2011/aesop/fig/Makefile @@ -31,10 +31,10 @@ clean:: read-ops.pdf: read-ops.gnuplot read-ops.data - @echo 'set terminal "pdf" size 4in,2.1in; set output "$@"' | gnuplot - $< + @echo 'set terminal "pdf" size 5in,2.6in; set output "$@"' | gnuplot - $< write-ops.pdf: write-ops.gnuplot write-ops.data - @echo 'set terminal "pdf" size 4in,2.1in; set output "$@"' | gnuplot - $< + @echo 'set terminal "pdf" size 5in,2.6in; set output "$@"' | gnuplot - $< %.pdf: %.gnuplot %.data @echo 'set terminal "pdf" size 5in,3in; set output "$@"' | gnuplot - $< diff --git a/papers/2011/aesop/fig/read-null-ops.gnuplot b/papers/2011/aesop/fig/read-null-ops.gnuplot index 7b53015..f4ddba7 100644 --- a/papers/2011/aesop/fig/read-null-ops.gnuplot +++ b/papers/2011/aesop/fig/read-null-ops.gnuplot @@ -37,7 +37,7 @@ set style rectangle back fc lt -3 fillstyle solid 1.00 border lt -1 set style circle radius graph 0.02, first 0, 0 set dummy x,y set format x "% g" -set format y "% g" +set format y "% 7g" set format x2 "% g" set format y2 "% g" set format z "% g" diff --git a/papers/2011/aesop/fig/read-ops.gnuplot b/papers/2011/aesop/fig/read-ops.gnuplot index 0b4864c..4786e0d 100644 --- a/papers/2011/aesop/fig/read-ops.gnuplot +++ b/papers/2011/aesop/fig/read-ops.gnuplot @@ -37,7 +37,7 @@ set style rectangle back fc lt -3 fillstyle solid 1.00 border lt -1 set style circle radius graph 0.02, first 0, 0 set dummy x,y set format x "% g" -set format y "% g" +set format y "% 7g" set format x2 "% g" set format y2 "% g" set format z "% g" diff --git a/papers/2011/aesop/fig/write-null-ops.gnuplot b/papers/2011/aesop/fig/write-null-ops.gnuplot index c7b487d..3b96f8f 100644 --- a/papers/2011/aesop/fig/write-null-ops.gnuplot +++ b/papers/2011/aesop/fig/write-null-ops.gnuplot @@ -37,7 +37,7 @@ set style rectangle back fc lt -3 fillstyle solid 1.00 border lt -1 set style circle radius graph 0.02, first 0, 0 set dummy x,y set format x "% g" -set format y "% g" +set format y "% 7g" set format x2 "% g" set format y2 "% g" set format z "% g" diff --git a/papers/2011/aesop/fig/write-ops.gnuplot b/papers/2011/aesop/fig/write-ops.gnuplot index 900f978..8c6f6ba 100644 --- a/papers/2011/aesop/fig/write-ops.gnuplot +++ b/papers/2011/aesop/fig/write-ops.gnuplot @@ -37,7 +37,7 @@ set style rectangle back fc lt -3 fillstyle solid 1.00 border lt -1 set style circle radius graph 0.02, first 0, 0 set dummy x,y set format x "% g" -set format y "% g" +set format y "% 7g" set format x2 "% g" set format y2 "% g" set format z "% g" hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 0fbd672fd92e61504bfed378098747a8480c0dd0
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 0fbd672fd92e61504bfed378098747a8480c0dd0 (commit) from 3322eb329f3ac05f54b1e3581e8a7ff95928ec8f (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 0fbd672fd92e61504bfed378098747a8480c0dd0 Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 16:56:21 2012 -0500 minor tweak to finalize title ----------------------------------------------------------------------- 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 92c2ba7..b77dfc2 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -85,7 +85,7 @@ xleftmargin=6ex % can use linebreaks \\ within to get better formatting as desired % I'd like to get AESOP in the title -\title{\aesop: Expressing Concurrency in \\ High Performance System Software} +\title{\aesop: Expressing Concurrency in \\ High-Performance System Software} \author{Dries Kimpe\inst{1} \and Phil Carns\inst{1} \and Kevin Harms\inst{1} hooks/post-receive -- Triton-private Repository

1 0

Triton-private Repository branch, master, updated. 3322eb329f3ac05f54b1e3581e8a7ff95928ec8f
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 3322eb329f3ac05f54b1e3581e8a7ff95928ec8f (commit) from e85b2f6d75c8333e5b1d39d6818149bb4c27471f (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 3322eb329f3ac05f54b1e3581e8a7ff95928ec8f Author: Phil Carns <carns(a)mcs.anl.gov> Date: Thu Mar 15 16:46:13 2012 -0500 gov. license ----------------------------------------------------------------------- Summary of changes: papers/2011/aesop/aesop.tex | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) Diff of changes: diff --git a/papers/2011/aesop/aesop.tex b/papers/2011/aesop/aesop.tex index 865318c..92c2ba7 100644 --- a/papers/2011/aesop/aesop.tex +++ b/papers/2011/aesop/aesop.tex @@ -207,4 +207,14 @@ Laboratory Computing Resource Center at Argonne National Laboratory. \bibliographystyle{IEEEtran} \bibliography{aesop,REFERENCES} +\newpage +The submitted manuscript has been created by UChicago Argonne, LLC, +Operator of Argonne National Laboratory (“Argonne”). Argonne, a +U.S. Department of Energy Office of Science laboratory, is operated +under Contract No. DE-AC02- 06CH11357. The U.S. Government retains +for itself, and others acting on its behalf, a paid-up nonexclusive, +irrevocable worldwide license in said article to reproduce, prepare +derivative works, distribute copies to the public, and perform publicly +and display publicly, by or on behalf of the Government. + \end{document} hooks/post-receive -- Triton-private Repository

1 0