February 2012 - Asg - mailman3.cels.anl.gov

Wiki update: File:Aesop-development-env-deliverable-2.3.1-02.2012.pdf
by Wiki update: Asg-private: Rross 29 Feb '12

29 Feb '12

1 0

aesop Repository branch, master, updated. ca39e6e8336c11e389f72f9d68494b438acb910d
by noreply＠mcs.anl.gov 28 Feb '12

28 Feb '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 "aesop Repository". The branch, master has been updated via ca39e6e8336c11e389f72f9d68494b438acb910d (commit) from 67f14a509dfa78f61d90709d50f75a94aee20f59 (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 ca39e6e8336c11e389f72f9d68494b438acb910d Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Tue Feb 28 18:10:21 2012 -0600 Document in aesop-performance.txt when experiment was done. ----------------------------------------------------------------------- Summary of changes: doc/aesop-performance.txt | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) Diff of changes: diff --git a/doc/aesop-performance.txt b/doc/aesop-performance.txt index 4388280..0614c60 100644 --- a/doc/aesop-performance.txt +++ b/doc/aesop-performance.txt @@ -231,6 +231,15 @@ that disk I/O is _not_ involved in those cases. === Experiment +This experiment was executed on Feburary 7, 2012 and Feburary 9, 2012. +The experiment was done using the {aesop} version from Triton and the +client code was from the triton-private repository. A patch was applied +to triton to modify queue usage. + +* triton ba74000dc0a0aaa35754015734c2944d45ed0daf +* triton-private d0cc70d12fba6edabe7478e21784f91588496bf2 +* triton-file-unfair-queue.patch + ==== Experiment System All experiments were executed on the Fusion cluster managed by hooks/post-receive -- aesop Repository

1 0

aesop Repository branch, master, updated. 67f14a509dfa78f61d90709d50f75a94aee20f59
by noreply＠mcs.anl.gov 28 Feb '12

28 Feb '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 "aesop Repository". The branch, master has been updated via 67f14a509dfa78f61d90709d50f75a94aee20f59 (commit) from be5202dc34de2ac56e50a5b51959ceeb76ed5ad8 (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 67f14a509dfa78f61d90709d50f75a94aee20f59 Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Tue Feb 28 17:29:22 2012 -0600 Make use of Aesop name be consistent in aesop-user-guide.txt. Done via {aesop} variable. ----------------------------------------------------------------------- Summary of changes: doc/aesop-user-guide.txt | 3 +- doc/aug_external.txt | 106 +++++++++++++++++++++++----------------------- doc/aug_introduction.txt | 86 +++++++++++++++++++------------------- doc/aug_language.txt | 58 +++++++++++++------------- doc/aug_preface.txt | 22 +++++----- doc/aug_standard.txt | 34 +++++++------- 6 files changed, 155 insertions(+), 154 deletions(-) Diff of changes: diff --git a/doc/aesop-user-guide.txt b/doc/aesop-user-guide.txt index 330a64b..ea0d854 100644 --- a/doc/aesop-user-guide.txt +++ b/doc/aesop-user-guide.txt @@ -1,4 +1,5 @@ -Aesop User Guide +:aesop: Aesop +{aesop} User Guide ================= author v0.1, 2012-01 diff --git a/doc/aug_external.txt b/doc/aug_external.txt index d091ce1..509097b 100644 --- a/doc/aug_external.txt +++ b/doc/aug_external.txt @@ -3,11 +3,11 @@ Interfacing with external C libraries [[ref-aesop-techniques]] -Aesop Techniques +{aesop} Techniques ---------------- -This chapter describes how to call existing C code from an aesop program. -The way to do this depends on if the aesop protoype of the external +This chapter describes how to call existing C code from an {aesop} program. +The way to do this depends on if the {aesop} protoype of the external function should be blocking or not. [[ref-interface-non-blocking]] @@ -20,7 +20,7 @@ made. As an example, consider the `math.h` header. All functions provided by this header are cpu-bound, meaning there is generally no reason to make them -blocking in aesop. To call these functions, simply include the header and +blocking in {aesop}. To call these functions, simply include the header and call them as in a regular C program. Asynchronous Interfaces @@ -33,15 +33,15 @@ notification either through a signal or by calling a user-specified callback function. While it is possible to directly use the asynchronous interface to the -library, doing so does not take advantage of the extra features aesop +library, doing so does not take advantage of the extra features {aesop} provides. For example, overlap (concurrency) has to be managed manually, and -aesop will not be able to cancel ongoing operations. +{aesop} will not be able to cancel ongoing operations. -In addition, in aesop, the functionality offered by the library would +In addition, in {aesop}, the functionality offered by the library would typically be exposed through blocking functions, as I/O depends on external events (i.e. disk, network) and is not cpu bound. -Therefore, it is recommended to create a single blocking aesop function +Therefore, it is recommended to create a single blocking {aesop} function combining the asynchronous operation and its completion or cancellation. There are a number of ways to do this. This section describes using the ResourceBuilder module (<<ref-resourcebuilder>>). An alternative technique is @@ -51,7 +51,7 @@ discussed in <<ref-resource>>. Building Blocking Functions using ResourceBuilder ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -This section discusses how to make a blocking aesop write function on top of +This section discusses how to make a blocking {aesop} write function on top of the POSIX AIO asynchronous I/O functions. @@ -105,7 +105,7 @@ call), and then waits for the slot to be signalled. The signalling happens by the completion of the I/O operation, which will call the `aio_write_complete` callback and complete the slot. -Since the `rb_slot_capture` function is blocking, aesop can switch execution +Since the `rb_slot_capture` function is blocking, {aesop} can switch execution elsewhere until the slot is either completed (by the completion of the write operation) or until the call is cancelled (by a call to `ae_cancel_branches`), in which case the `rb_slot_capture` function will return with an error. @@ -116,9 +116,9 @@ in which case the `rb_slot_capture` function will return with an error. Blocking functions ~~~~~~~~~~~~~~~~~~ -C library functions which should really be blocking in aesop +C library functions which should really be blocking in {aesop} (to improve concurrency and ease of use) generally need some wrapper code to -make them into blocking aesop functions. This section describes how this can +make them into blocking {aesop} functions. This section describes how this can be done using the 'thread' module. @@ -137,7 +137,7 @@ Since there is no asynchronous version of the `open` call, we cannot apply the ResourceBuilder technique (<<ref-resourcebuilder>>). The best way to deal with these functions is to create a thread to call the function without blocking the calling thread. The newly created thread will be -idle while waiting for the operation to complete. However, aesop will use the +idle while waiting for the operation to complete. However, {aesop} will use the parent thread to continue executing other code where possible. The thread module can simplify implementing this technique: @@ -159,10 +159,10 @@ ___blocking int aesop_open (const char * pathname, int flags) In this example, `open_group` is a thread group which was created by an earlier call to `aethread_create_group`. As described in <<ref-thread>>, -provided the `aethread_hint` call is successful, _in the current aesop +provided the `aethread_hint` call is successful, _in the current {aesop} implementation_, the code up to the following blocking call will execute in a thread borrowed from the thread group. As `aethread_hint` is a blocking -function, the aesop thread calling `aesop_open` will switch to other work upon +function, the {aesop} thread calling `aesop_open` will switch to other work upon entering the `aethread_hint` call, making sure execution in other branches continues while the newly created thread will execute the `open` call and sleep until the operation completes. @@ -171,7 +171,7 @@ sleep until the operation completes. .Implementation Detail ===== The thread module relies on the internals of the current -source-to-source translator. Its use and API might change in future aesop +source-to-source translator. Its use and API might change in future {aesop} releases. ===== @@ -180,7 +180,7 @@ releases. //======================================================================== //======================================================================== [[ref-resource]] -Aesop Resources +{aesop} Resources --------------- //======================================================================== //======================================================================== @@ -188,23 +188,23 @@ Aesop Resources In some cases, the techniques outlined in <<ref-aesop-techniques>> cannot be used or do not offer sufficient control. This section provides details on how to write the low level glue code to -directly integrate an external library into aesop. +directly integrate an external library into {aesop}. Resources? ~~~~~~~~~~ -<<ref-whenblocking>> describes how to construct a blocking function in aesop. -However, it is also possible for a pure C library to export an aesop blocking +<<ref-whenblocking>> describes how to construct a blocking function in {aesop}. +However, it is also possible for a pure C library to export an {aesop} blocking function, fully supporting features such as concurrent execution and -cancellation. This is done by creating a new aesop _resource_. +cancellation. This is done by creating a new {aesop} _resource_. -In short, a resource integrates with aesop to export a number of regular and -_blocking_ functions, together with hooks aesop can call to cancel the +In short, a resource integrates with {aesop} to export a number of regular and +_blocking_ functions, together with hooks {aesop} can call to cancel the blocking calls issued by the resource, and to enable the resource to make progress. NOTE: Resources are implemented entirely in C, and therefore cannot use any -of the aesop extenions. +of the {aesop} extenions. Defining Blocking Functions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -222,7 +222,7 @@ ae_define_post (int, rb_slot_capture, rb_slot_t * slot) } ---- -The code above generates the following aesop prototype: +The code above generates the following {aesop} prototype: [source,c] ---- @@ -232,24 +232,24 @@ __blocking int rb_slot_capture (rb_slot_t * slot); The `ae_define_post` macro supports a variable number of arguments, enabling the creation of blocking functions with more than one parameter. -The resource has to provide a matching aesop header file (`.hae') listing the -public (aesop) prototypes of the functions it exports. +The resource has to provide a matching {aesop} header file (`.hae') listing the +public ({aesop}) prototypes of the functions it exports. The function needs to return a single integer argument. This argument can be one of the following: * `AE_SUCCESS`: the blocking function was successfully initiated. * `AE_IMMEDIATE_COMPLETION`: The blocking function already completed. This is - an optimization indicating aesop does not need to switch to another function + an optimization indicating {aesop} does not need to switch to another function to continue execution. In effect, it makes the function behave as a non-blocking function. -* An aesop error code: this indicates that there was a problem starting the +* An {aesop} error code: this indicates that there was a problem starting the blocking call. The blocking function, assuming no immediate completion, needs to do the following: -. Generate an _operation id_ (`ae_op_id_t` type), which can be used by aesop +. Generate an _operation id_ (`ae_op_id_t` type), which can be used by {aesop} to test for completion and to identify the operation in case of cancellation. . Capture the context of the caller, so that execution can continue at this @@ -293,18 +293,18 @@ Capturing the caller's Execution Context ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Within a function created by the `ae_define_post` macro, it is possible to use -the `ae_op_fill` macro to capture the aesop execution context. This macro -takes the internal aesop parameters (similar to the function stack) and stores +the `ae_op_fill` macro to capture the {aesop} execution context. This macro +takes the internal {aesop} parameters (similar to the function stack) and stores them in a `struct ae_op`. The `ae_op` structure contains two members that can be read by the resource. [horizontal] -*user_ptr*:: An internal data member used by aesop. +*user_ptr*:: An internal data member used by {aesop}. *callback*:: This parameter is a pointer to a function `void (*callback) (void -*, T)`, where `T` is the return type of the aesop blocking function being +*, T)`, where `T` is the return type of the {aesop} blocking function being completed. The first parameter (`void *`) needs to be set to the `user_ptr` when calling the function. @@ -329,19 +329,19 @@ Returning data from a blocking call ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Since the return code of a blocking call defined using `ae_define_post` is -always an integer, used by aesop internally, controlling the return value from +always an integer, used by {aesop} internally, controlling the return value from a blocking call cannot be done using a simple `return`. If the call completed immediately (and the blocking function returns -`AE_IMMEDIATE_COMPLETION`) or failed to start (returning an aesop error), the +`AE_IMMEDIATE_COMPLETION`) or failed to start (returning an {aesop} error), the return code for the blocking call can be set through the `__ae_retval` pointer. This pointer is set by `ae_define_post`, and is only accessible within its scope. The type of the pointer is the same as the type listed as the first parameter to the `ae_define_post` function. -If the function was completed at a later point (by calling the aesop provided +If the function was completed at a later point (by calling the {aesop} provided callback), the return code of the blocking function can be passed in as the -second parameter to the callback (the first parameter is used by aesop +second parameter to the callback (the first parameter is used by {aesop} internally). @@ -368,7 +368,7 @@ struct ae_resource * The `resource_name` member is the only mandatory field in this structure. -* The `test` function, if implemented, can be used by aesop to wait for the +* The `test` function, if implemented, can be used by {aesop} to wait for the completion of a specific operation, specified by the `id` parameter. Generally, it is not necessary to implement this function; the `test` function pointer can be set to `NULL`. @@ -387,7 +387,7 @@ The `register_context` and `unregister_context` functions should be set to `NULL`. The `poll_context` function can safely ignore the `context` parameter. ==== -The new resource should be registered with aesop using the `ae_resource_register` +The new resource should be registered with {aesop} using the `ae_resource_register` function. The internal ID for the resource (used in creating an operation ID) is returned in `*newid`. @@ -401,14 +401,14 @@ void ae_resource_unregister (int resource_id); ==== The `ResourceBuilder` and `Thread` resources provide good examples on how to construct a simple resource. Their code can be found in the `resources` -directory in the aesop distribution. +directory in the {aesop} distribution. ==== [[ref-resource-configuration]] Resource Configuration ~~~~~~~~~~~~~~~~~~~~~~ -When a resource is registered with the aesop system using the +When a resource is registered with the {aesop} system using the `ae_resource_register()` function, the resource author has the option of specifying configuration parameters for that resource using the `config_array` field of the required `ae_resource` struct. The @@ -446,7 +446,7 @@ if the resource does not support any configuration parameters. [NOTE] ==== As of February 2012 this functionality is only avaialable to resources, but -in future work we will extend this concept to allow arbitrary Aesop +in future work we will extend this concept to allow arbitrary {aesop} components to register configuration parameters in a similar manner. ==== @@ -458,30 +458,30 @@ Resource Progress A resource can use a number of progress models: First, if the underlying API exported by the resource has its own threads or -progress engine, then it can trigger callbacks that drive the next aesop +progress engine, then it can trigger callbacks that drive the next {aesop} execution state. The POSIX AIO functionality is an example of this. If the underlying functionality is passive, the resource can request polling -from aesop and aesop will drive it by explicit calls to the resource polling +from {aesop} and {aesop} will drive it by explicit calls to the resource polling function specified at registration time. Polling resources can "busy poll" or just indicate specific times when they would like to be polled. A resource is responsible for indicating it has work to do, by calling the -`ae_resource_request_poll` function. After calling this function, aesop will +`ae_resource_request_poll` function. After calling this function, {aesop} will schedule a call to the resource's `poll_context` function. The `ae_resource_request_poll` function is thread-safe and can safely be called from within a signal handler. A combination of these models is also possible. For example, a signal handler or callback can record the completion of a resource function, and request a -poll. When the resource's polling function is subsequently called by aesop, -the resource can complete the action by calling the appropriate aesop +poll. When the resource's polling function is subsequently called by {aesop}, +the resource can complete the action by calling the appropriate {aesop} callback. When to write a resource ~~~~~~~~~~~~~~~~~~~~~~~~ -In the current aesop distribution, there are only 3 resources, listed below. +In the current {aesop} distribution, there are only 3 resources, listed below. * ResourceBuilder * Thread @@ -497,10 +497,10 @@ Whever possible, instead of writing a resource, it is recommended to use `ResourceBuilder` or `Thread` to interface with external components. Using these resources instead of writing a new resource has a number of advantages. First, there is no need to write C glue code as `Thread` and `ResourceBuilder` -expose aesop functions. This makes it possible to write the interface using -aesop features such as concurrent branches. Second, resources are exposed to -low level interface details of the aesop runtime system and are consequently -more likely to require updating when moving to a new version of aesop. In +expose {aesop} functions. This makes it possible to write the interface using +{aesop} features such as concurrent branches. Second, resources are exposed to +low level interface details of the {aesop} runtime system and are consequently +more likely to require updating when moving to a new version of {aesop}. In addition, writing an interface using `Thread` or `ResourceBuilder` typically requires less code, these modules already take care of dealing with low level details such as generating operation id's and cancellation. diff --git a/doc/aug_introduction.txt b/doc/aug_introduction.txt index 3ea60d9..b6ffb0f 100644 --- a/doc/aug_introduction.txt +++ b/doc/aug_introduction.txt @@ -3,10 +3,10 @@ Introduction ============ -Installing Aesop +Installing {aesop} ---------------- -This section describes how to obtain, build and install the aesop +This section describes how to obtain, build and install the {aesop} source-to-source translator. @@ -15,15 +15,15 @@ Prerequisites [NOTE] ===== -These are the requirements of the aesop source-to-source translator. -Executables compiled from aesop source code do not require any additional +These are the requirements of the {aesop} source-to-source translator. +Executables compiled from {aesop} source code do not require any additional packages, except for those required used by the program itself. For example, there is no need to have haskell installed when running an executable -created using the aesop source-to-source translator. +created using the {aesop} source-to-source translator. ==== -Aesop currently requires the following: +{aesop} currently requires the following: * The Glasgow Haskell compiler, version 7.0 or later (http://www.haskell.org/ghc/) @@ -51,14 +51,14 @@ A Mac OS haskell package can be downloaded from http://hackage.haskell.org/platf Developer Version ^^^^^^^^^^^^^^^^^^ -When building aesop from the git source code repository, the following extra +When building {aesop} from the git source code repository, the following extra packages are required: * A git client. Git can be downloaded from http://git-scm.com/download. * autoconf (http://www.gnu.org/s/autoconf/) -Installation of the aesop dependencies +Installation of the {aesop} dependencies ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Glasgow Haskell Compiler @@ -74,7 +74,7 @@ the package system-wide, the compiler can be installed using the instructions below. -Aesop requires the Glasgow Haskell Compiler (ghc). If root +{aesop} requires the Glasgow Haskell Compiler (ghc). If root access (required for many package managers) is not available, or system wide installation of ghc is not desired, it is possible to install the ghc binaries in a home @@ -86,7 +86,7 @@ http://www.haskell.org/ghc/download_ghc_7_2_2#binaries Additional Haskell Modules ^^^^^^^^^^^^^^^^^^^^^^^^^^ -Aesop requires some additional haskell modules: +{aesop} requires some additional haskell modules: * transformers, version 0.2.2.0 * mtl, version 2.0.1.0 @@ -97,7 +97,7 @@ Aesop requires some additional haskell modules: * regex-pcre-builtin, version 0.94.2.1.7.7 * syb, version 0.3 -To simplify installing these packages, the aesop distribution contains scripts +To simplify installing these packages, the {aesop} distribution contains scripts to download and install these modules. These scripts expect the +wget+ utility to be in the default search path. The +wget+ utility should be available as a package on your platform. @@ -127,32 +127,32 @@ the library needs to be installed (using the `--prefix` option). [NOTE] ===== -If installing OpenPA in a non-standard location, make sure to use the `--with-openpa` argument when configuring Aesop. +If installing OpenPA in a non-standard location, make sure to use the `--with-openpa` argument when configuring {aesop}. ===== -Obtaining the Aesop distribution +Obtaining the {aesop} distribution ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Right now, the only way to obtain the aesop distribution is directly from +Right now, the only way to obtain the {aesop} distribution is directly from our source code repository. For this, +git+ is required (http://git-scm.com) -In the future, we will release stable aesop source archives through the aesop +In the future, we will release stable {aesop} source archives through the {aesop} website. -Obtaining Aesop from the source code repository +Obtaining {aesop} from the source code repository ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [NOTE] -.The Aesop source code repository +.The {aesop} source code repository ======= -The aesop source code repository contains the latest aesop source code, which +The {aesop} source code repository contains the latest {aesop} source code, which changes on a daily basis. As such, from time to time, the code in the repository might contain bugs or fail to build. If that is the case, please let us know by opening a ticket at http://trac.mcs.anl.gov/projects/aesop. ========= -In order to install Aesop it is necessary to first clone the repository. -The aesop source code repository is public and can be cloned by +In order to install {aesop} it is necessary to first clone the repository. +The {aesop} source code repository is public and can be cloned by anonymous users: ------ @@ -164,7 +164,7 @@ git clone git://git.mcs.anl.gov/aesop ======================== We welcome all contributions and patches. -Frequent contributors can request write access to the aesop repository by +Frequent contributors can request write access to the {aesop} repository by sending a a public key (in OpenSSH format) to Phil Carns (mailto:[email protected][[email protected]]). @@ -176,7 +176,7 @@ git clone [email protected]:aesop.git ------ ======================= -The aesop code is split into multiple submodules. +The {aesop} code is split into multiple submodules. Once the aesop repository is cloned, these submodules must be initialized. ----------- @@ -198,17 +198,17 @@ directory of the aesop directory: ./prepare ---------- -Configuring Aesop +Configuring {aesop} ^^^^^^^^^^^^^^^^^ -Now there should be a script named +configure+ in the aesop root directory. +Now there should be a script named +configure+ in the +aesop+ root directory. -It is possible to compile aesop in the source directory, but we usually +It is possible to compile {aesop} in the source directory, but we usually recommend doing an "out of tree build". To do this, create a build -subdirectory inside the aesop directory and then run configure and make from +subdirectory inside the +aesop+ directory and then run configure and make from there: ----- +----- mkdir build cd build ../configure @@ -224,10 +224,10 @@ When doing an out of tree build, it is important to be in the desired build directory when executing the configure script. ==== -Building Aesop +Building {aesop} ^^^^^^^^^^^^^^ -To build aesop, run `make` within the build-aesop directory: +To build {aesop}, run `make` within the +build+ directory: ----- make -j 4 @@ -235,14 +235,14 @@ make -j 4 [NOTE] ==== -Specifying +-j 4+ is optional, but the aesop build system does support +Specifying +-j 4+ is optional, but the {aesop} build system does support parallel builds, reducing the build time on most systems. ==== -Building and running the Aesop test suite +Building and running the {aesop} test suite ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The aesop distribution includes a large number of test programs, +The {aesop} distribution includes a large number of test programs, designed to exercise the language features and the translator. These test programs can be built using the following command (in the build @@ -265,17 +265,17 @@ This will be fixed soon. ===== -Installing Aesop +Installing {aesop} ^^^^^^^^^^^^^^^^ -To install aesop, use the following command: +To install {aesop}, use the following command: ---- make install ---- Unless specified otherwise (using the +--prefix+ option at configure time), -aesop will be installed into the +/usr/local+ directory. +{aesop} will be installed into the +/usr/local+ directory. The configure process produces two scripts in the maint/ directory. aecc is a translator for .ae files, and aercc is a translator for .aer files. Both @@ -284,7 +284,7 @@ compilation into one step. These wrappers will be during the installation process. -Using the Aesop Source-To-Source Translator +Using the {aesop} Source-To-Source Translator ------------------------------------------- @@ -321,14 +321,14 @@ digraph G [TIP] ===== -To see the intermediate C code generated by aesop (instead -of going directly from .ae files to .o files), configure aesop with the +To see the intermediate C code generated by {aesop} (instead +of going directly from .ae files to .o files), configure {aesop} with the `--enable-aesop-debug` configure option. Doing so will cause -additional ae.i and ae.s files to be created during the compilation of aesop code. -These files contain the C translation of the aesop source code. +additional ae.i and ae.s files to be created during the compilation of {aesop} code. +These files contain the C translation of the {aesop} source code. ===== -Invoking the Aesop translator (aecc) +Invoking the {aesop} translator (aecc) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The following example shows the command line used to translate a .ae file @@ -344,9 +344,9 @@ of gcc. The `--` argument is a delimiter indicating that all following arguments (`-g` in this case) will be passed directly to the C compiler. As of February 2012 there are some known bugs in using the aecc translator -outside of the Aesop repository. More details can be found in trac +outside of the {aesop} repository. More details can be found in trac tickets #21 and #7. Until these are resolved we recommend using the test -programs in the Aesop tree as an example of how to best set the `-I` include +programs in the {aesop} tree as an example of how to best set the `-I` include path arguments and `-L` library path arguments when compiling external code. diff --git a/doc/aug_language.txt b/doc/aug_language.txt index 77d0432..8d2df35 100644 --- a/doc/aug_language.txt +++ b/doc/aug_language.txt @@ -1,5 +1,5 @@ -The Aesop Programming Language +The {aesop} Programming Language ============================== @@ -9,14 +9,14 @@ Language Basics Source files ~~~~~~~~~~~~ -Aesop source and header files are named *.ae and *.hae, respectively. They +{aesop} source and header files are named *.ae and *.hae, respectively. They are used exactly like C source and header files, except that they support additional constructs, such as the `__blocking` qualifier for functions (and function pointers) and the `pwait` and `pbranch` keywords (See <<ref-blocking>>). ///// -In addition, Aesop remote code (ie, RPC functions) can be found in .aer and +In addition, {aesop} remote code (ie, RPC functions) can be found in .aer and .haer functions. These source files support an additional __remote qualifier for functions to be invoked via RPC. //// @@ -24,27 +24,27 @@ qualifier for functions to be invoked via RPC. C compatibility ~~~~~~~~~~~~~ -Aesop is an extension to the ANSI C language. Therefore, valid ANSI C code is -also valid aesop code. +{aesop} is an extension to the ANSI C language. Therefore, valid ANSI C code is +also valid {aesop} code. [NOTE] .Implementation Detail ==== -The current implementation of the aesop translator, while supporting many C99 +The current implementation of the {aesop} translator, while supporting many C99 features, does not yet support all of the C99 functionality, in particular those related to variable declarations in locations other than the beginning of the function. These issues will be fixed in later releases. ==== -Threads and Aesop +Threads and {aesop} ~~~~~~~~~~~~~~~~~ -Aesop is fully thread safe. Provided the function itself is thread safe, +{aesop} is fully thread safe. Provided the function itself is thread safe, it is legal to call that function (whether blocking or not) concurrently from multiple threads. -Aesop programs exposing concurrency through aesop's language features (see +{aesop} programs exposing concurrency through {aesop}'s language features (see <<ref-pbranch>>) have to be thread-safe, as the implementation may choose to use multiple threads to execute code whenever possible. @@ -57,9 +57,9 @@ Blocking Functions //=================================================================== //=================================================================== -Aesop extends the C language with an additional function type: blocking +{aesop} extends the C language with an additional function type: blocking functions. Blocking functions support concurrent -execution, and are used by aesop to introduce concurrency to +execution, and are used by {aesop} to introduce concurrency to the C language. @@ -112,9 +112,9 @@ true: * The function calls another function which is blocking, for example `aesop_timer` (see <<ref-timer>>). -* The function uses aesop specific functionality (i.e. is not plain C). +* The function uses {aesop} specific functionality (i.e. is not plain C). -Since every aesop program tends to call at least one blocking function, this +Since every {aesop} program tends to call at least one blocking function, this means that the starting point of the program (see <<ref-main>>) is necessarily blocking. @@ -124,19 +124,19 @@ reason to do so. [NOTE] .Implementation Detail -In the current aesop implementation, only blocking functions are transformed -by the aesop source to source translator. Regular C functions are emitted +In the current {aesop} implementation, only blocking functions are transformed +by the {aesop} source to source translator. Regular C functions are emitted unmodified. When should functions be blocking? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Except in the cases listed in <<ref-whenblocking>>, aesop does not attempt to +Except in the cases listed in <<ref-whenblocking>>, {aesop} does not attempt to enforce if a function should be blocking or not. It is up to the programmer to decide which functions need to be blocking. In general, functions that are not cpu-bound and depend on external (to the -cpu) events are best made blocking. This is done so that aesop can switch +cpu) events are best made blocking. This is done so that {aesop} can switch execution to code that is ready to execute while waiting for the external event to occur. @@ -182,7 +182,7 @@ __blocking void example (void) ---- The function `aesop_timer` (discussed in <<ref-timer>>) suspends execution for -the given number of microseconds. In a way it is the aesop version of the +the given number of microseconds. In a way it is the {aesop} version of the POSIX `usleep` function. The output from calling `example` will be: @@ -212,7 +212,7 @@ branches it encloses have completed. Therefore, in this example, only after both timer calls completed, execution continues with the 3rd `printf` (line 16). -IMPORTANT: The aesop language does _not guarantee_ that multiple threads will +IMPORTANT: The {aesop} language does _not guarantee_ that multiple threads will be used to execute pbranches concurrently. However, it does guarantee that a blocking call will not prevent execution of other branches, by temporarily switching execution to another `pbranch`. @@ -300,7 +300,7 @@ Cancelling branches ~~~~~~~~~~~~~~~~~~~~ WARNING: This section describes the new cancel model, which significantly -differs from the model in older aesop versions. +differs from the model in older {aesop} versions. It is possible for a pbranch to cancel the other branches in a `pwait` construct, by calling `ae_cancel_branches()`. @@ -357,7 +357,7 @@ __blocking void cancel_example (void) ---- Using pbranches and cancellation, it is reasonably straightforward to -implement a time-out using aesop. In the example above, `do_something` will +implement a time-out using {aesop}. In the example above, `do_something` will be cancelled if it does not complete within 10000 ms. After 10000 ms, `aesop_timer` will return 0 (indicating success), causing the first pbranch to cancel the second branch. However, if `do_something` completes before the @@ -400,15 +400,15 @@ Miscellaneous & Hello World Including aesop.h ~~~~~~~~~~~~~~~~~ -All aesop source files must include `aesop.h`. +All {aesop} source files must include `aesop.h`. Failing to do so will cause a compilation error. [[ref-main]] -The aesop main function +The {aesop} main function ~~~~~~~~~~~~~~~~~~~~~~~ -The `main` function for an aesop program is identified using `aesop_main_set`. +The `main` function for an {aesop} program is identified using `aesop_main_set`. The named function must be a blocking function, and must take the same arguments as the standard C `main` function. @@ -424,11 +424,11 @@ aesop_main_set(aesop_main); [TIP] ==== -Sometimes it is useful to be able to execute some code _before_ aesop +Sometimes it is useful to be able to execute some code _before_ {aesop} initializes. For this, `aesop_main_set_with_init` can be used instead of `aesop_main_set`. The former takes an additional parameter naming a _regular_ -C function which will be called _before_ initializing any aesop component. -After initializing aesop, the blocking aesop main function will be called as +C function which will be called _before_ initializing any {aesop} component. +After initializing {aesop}, the blocking +aesop_main+ function will be called as usual. @@ -443,7 +443,7 @@ aesop_main_set_with_init (pre_init, aesop_main); Hello World ~~~~~~~~~~~ -Below is an example aesop program. +Below is an example {aesop} program. [source,c] ---- @@ -473,7 +473,7 @@ aesop_main_set (test_main); Some observations: -* All aesop programs have to include `aesop.h`. +* All {aesop} programs have to include `aesop.h`. * The starting point of the program is indicated using `aesop_main_set`. * The starting function is `__blocking`. diff --git a/doc/aug_preface.txt b/doc/aug_preface.txt index f0681eb..a72abec 100644 --- a/doc/aug_preface.txt +++ b/doc/aug_preface.txt @@ -3,30 +3,30 @@ Preface ========= -This document is the aesop user guide. It describes how to obtain, build and -install the aesop language. In addition, it describes how to program using -aesop. +This document is the {aesop} user guide. It describes how to obtain, build and +install the {aesop} language. In addition, it describes how to program using +{aesop}. Latest version of this document ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -This document can be found in the aesop distribution, +This document can be found in the {aesop} distribution, which can be downloaded from http://trac.mcs.anl.gov/projects/aesop. Contacting Us ~~~~~~~~~~~~~ -Aesop Online +{aesop} Online ^^^^^^^^^^^^ -The aesop home page is located at http://trac.mcs.anl.gov/projects/aesop. -Please report aesop issues (for this document or the aesop translator) and +The {aesop} home page is located at http://trac.mcs.anl.gov/projects/aesop. +Please report {aesop} issues (for this document or the {aesop} translator) and feature requests at http://trac.mcs.anl.gov/projects/aesop/newticket. By Email ^^^^^^^^ -For other questions and concerns, the aesop developers can be contacted +For other questions and concerns, the {aesop} developers can be contacted at mailto:[email protected][[email protected]]. Conventions and notations @@ -45,10 +45,10 @@ printf ("Example code\n"); Implementation-specific Behavior ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -It is important to differentiate between the _aesop language_ and the way this -language is currently implemented by the _aesop translator_. The aesop language +It is important to differentiate between the _{aesop} language_ and the way this +language is currently implemented by the _{aesop} translator_. The {aesop} language leaves certain aspects open. For these cases, the behavior as implemented by the -current version of the aesop translator might change in future versions. +current version of the {aesop} translator might change in future versions. In this document implementation-specific behavior will be indicated as shown below. diff --git a/doc/aug_standard.txt b/doc/aug_standard.txt index 4232a3b..6d8ad51 100644 --- a/doc/aug_standard.txt +++ b/doc/aug_standard.txt @@ -1,18 +1,18 @@ [[ref-library]] -The Aesop Standard Library +The {aesop} Standard Library ========================== -Aesop System Interfaces and Tools +{aesop} System Interfaces and Tools ---------------------------------- Configuration Interface ~~~~~~~~~~~~~~~~~~~~~~~ -Aesop provides a unified interface to advertise and set configuration +{aesop} provides a unified interface to advertise and set configuration parameters across code modules. -This section describes the Aesop user interface to this functionality; The low +This section describes the {aesop} user interface to this functionality; The low level C interface used for system components is described in <<ref-resource-configuration>>. @@ -30,12 +30,12 @@ int aesop_set_config(const char* key, const char* value); The `key` argument is the name of the configuration parameter to be set, while the `value` argument is the new value for that configuration parameter. All values must be provided as strings. The function returns 0 -on success, `AE_ERR_NOT_FOUND` if the key is not known to Aesop, or +on success, `AE_ERR_NOT_FOUND` if the key is not known to {aesop}, or `AE_ERR_INVAL` if the key is valid but the value is not. There is currently no corresponding function to query a configuration parameter or list available keys (as of February 2012), although this will be -added in future versions of Aesop. +added in future versions of {aesop}. Debugging @@ -45,7 +45,7 @@ Debugging -The code injected by the aesop translator supports writing tracing +The code injected by the {aesop} translator supports writing tracing information to `stderr`. The following components can be traced: @@ -83,11 +83,11 @@ enable or disable tracing. //===================================================================== -Standard Aesop modules +Standard {aesop} modules ----------------------- //===================================================================== -The following modules are bundled with the aesop distribution. +The following modules are bundled with the {aesop} distribution. [[ref-timer]] Timer @@ -151,7 +151,7 @@ __blocking int aesocket_accept( int * err); ---- -In the aesop version of the accept system call, +In the {aesop} version of the accept system call, unlike the system call, the descriptor for the new connection is returned in `*newfd`, while an error, if any, is returned in `*err`. The function returns `AE_SUCCESS` when a new connection is accepted, @@ -232,7 +232,7 @@ __blocking int aefile_fdatasync(int fd); __blocking int aefile_ftruncate(int fd, off_t length); __blocking int aefile_unlink(const char *pathname); ---- -These are aesop versions of the regular `pwrite`, `pread`, `fsync`, +These are {aesop} versions of the regular `pwrite`, `pread`, `fsync`, `fdatasync`, `ftruncate` and `unlink` functions. [NOTE] @@ -279,7 +279,7 @@ int rb_slot_complete (rb_slot_t * slot); Release a captured slot. This call returns `AE_SUCCESS` if it successfully released a `rb_slot_capture` call on the slot. If the slot was not active (for -example because it was already cancelled), an unspecified aesop error code is +example because it was already cancelled), an unspecified {aesop} error code is returned. [source,c] @@ -294,7 +294,7 @@ illegal to call this function on a slot that is currently captured. [TIP] ==== The ResourceBuilder functions provide a low level toolkit used to build higher -level code. For example, the ResourceBuilder is used to implement the aesop +level code. For example, the ResourceBuilder is used to implement the {aesop} socket functions. ResourceBuilder is also a good basis for building synchronization primitives, such as mutexes and semaphores. ==== @@ -303,7 +303,7 @@ synchronization primitives, such as mutexes and semaphores. thread ~~~~~~ -WARNING: The thread module relies on internal details of the current aesop +WARNING: The thread module relies on internal details of the current {aesop} implementation. Its use and interface might change in future versions. Header: `aethread.hae` @@ -335,14 +335,14 @@ The `aethread_hint` function is a blocking function which will complete when a free thread can be found in the specified group. If all threads in the group are in use, this function will wait until one becomes available. When returning from this call, *one of the threads of the specified group will be -used to continue execution*. With the current aesop translator, this means +used to continue execution*. With the current {aesop} translator, this means that the code following the `aethread_hint` call will execute using one of the threads of the group, until the thread becomes idle. [NOTE] .Implementation Detail ==== -In the current aesop implementation, a thread becomes idle when one of the +In the current {aesop} implementation, a thread becomes idle when one of the following happens: * Entering a blocking call which cannot complete immediately. @@ -357,7 +357,7 @@ thread to become available. The function returns `AE_ERR_CANCELLED` when the search was cancelled, or `AE_SUCCESS` in when execution successfully switched to one of the group threads. -The thread module is mainly used to create an aesop blocking function (which +The thread module is mainly used to create an {aesop} blocking function (which supports concurrent execution) from a long lived C function which would otherwise force the calling thread to become idle. See <<ref-thread>> for more details and an example. hooks/post-receive -- aesop Repository

1 0

aesop Repository branch, master, updated. be5202dc34de2ac56e50a5b51959ceeb76ed5ad8
by noreply＠mcs.anl.gov 28 Feb '12

28 Feb '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 "aesop Repository". The branch, master has been updated via be5202dc34de2ac56e50a5b51959ceeb76ed5ad8 (commit) from b0785d6e139a5f5c069d6d19e7693e1c15673e3a (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 be5202dc34de2ac56e50a5b51959ceeb76ed5ad8 Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Tue Feb 28 16:47:35 2012 -0600 Make use of 'aesop' consistent via asciidoc variable. ----------------------------------------------------------------------- Summary of changes: doc/aesop-performance.txt | 152 +++++++++++++++++++++++---------------------- 1 files changed, 77 insertions(+), 75 deletions(-) Diff of changes: diff --git a/doc/aesop-performance.txt b/doc/aesop-performance.txt index a25e782..4388280 100644 --- a/doc/aesop-performance.txt +++ b/doc/aesop-performance.txt @@ -1,32 +1,34 @@ -= Aesop Performance Analysis +:aesop: Aesop + += {aesop} Performance Analysis == Introduction -This document examines the performance of Aesop in terms of runtime +This document examines the performance of {aesop} in terms of runtime performance, memory efficiency, programmer productivity, and compile time performance. -Aesop is a programming language and programming model designed +{aesop} is a programming language and programming model designed to implement distributed system software with high development productivity and run time efficiency. Further details about the language and development environment can be found -in the Aesop User's Guide. +in the {aesop} User's Guide. The remainder of this document is organized as follows. <<sec-case-study>> describe a network service -case study which is then used to evaluate the performance of Aesop +case study which is then used to evaluate the performance of {aesop} relative to more traditional server architectures in terms of performance (<<runtime-perf>>), memory usage (<<sec-memory>>), and productivity (<<sec-productivity>>). <<sec-overhead-analysis>> provides a more detailed -breakdown of specific sources of Aesop overhead, while -<<sec-compile>> concludes by discussing Aesop compile-time code translation +breakdown of specific sources of {aesop} overhead, while +<<sec-compile>> concludes by discussing {aesop} compile-time code translation performance. [[sec-case-study]] == Case study description We will use a simple network service case study for quantitative -evaluation of the Aesop programming language. The case study is a TCP +evaluation of the {aesop} programming language. The case study is a TCP server that can write or read data from local files. It is expected to process requests from multiple clients simultaneously. The description of the test server and client are given in the following subsections. @@ -149,7 +151,7 @@ digraph G We implemented the same request protocol in multiple server daemons in order to contrast 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 using the {aesop} language, while all other servers are implemented in C. The `pthread` library was used in all cases that required explicit threading, while the `libev` library was used in all cases that required an explicit event loop @@ -157,15 +159,15 @@ library was used in all cases that required an explicit event loop ==== Server Implementations -We implemented six server types including Aesop. Each server type examines +We implemented six server types including {aesop}. Each server type examines a different type of concurrency model. -===== Aesop +===== {aesop} -The Aesop server is implemented in the Aesop programming language. The server uses a +The {aesop} server is implemented in the {aesop} programming language. The server uses a 'lonely pbranch' 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 that are provided by the {aesop} standard library. The underlying socket resource uses non-blocking sockets with a thread pool of 12 threads. The file resource uses synchronous IO and a thread pool with 4 threads. @@ -315,11 +317,11 @@ mpirun -np <procs> echo-client --ip <ip> --port 9999 --path <path> --num-request === Expectations -Aesop is intended to improve developer productivity while preserving +{aesop} is intended to improve developer productivity while preserving scalable performance for system software workloads. The goal of the raw -performance comparison therefore is not to show that Aesop offers superior +performance comparison therefore is not to show that {aesop} offers superior performance to traditional approaches in all scenarios. Instead, we want to -determine if Aesop offers sufficient performance for consideration +determine if {aesop} offers sufficient performance for consideration as a viable programming model based on its productivity merits. We will elaborate on the productivity aspect of the comparison later in <<sec-productivity>>. @@ -337,10 +339,10 @@ image::fig/write-hist.png[] <<fig-writehist>> 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 1024. In this graph we see that {aesop} does not perform as well as the other servers for small workloads (taking 3.2 seconds at the smallest scale, verses 1.9 seconds for the thread-per-op -server). However, Aesop is the fastest server at the largest scale +server). However, {aesop} is the fastest server at the largest scale (taking 119.8 seconds verses 130.8 seconds for the nearest competitors in thread-per-client and thread-per-client-nb). @@ -348,17 +350,17 @@ in thread-per-client and thread-per-client-nb). [[fig-readhist]] image::fig/read-hist.png[] -<<fig-readhist>> shows the results of the read experiment. Aesop performs +<<fig-readhist>> 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 in 48.3 seconds verses 46.1 seconds for the fastest +{aesop} completes the test in 48.3 seconds verses 46.1 seconds for the fastest server (thread-pool). The event server performs particularly poorly in all cases, ultimately running the largest scale test in 77.2 seconds. -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 +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} in terms of its relative performance. ==== Network I/O @@ -376,12 +378,12 @@ image::fig/write-null-hist.png[] [[fig-readnull]] image::fig/read-null-hist.png[] -Aesop is competitive with (and in most cases better than) the other +{aesop} is competitive with (and in most cases better than) the other implementations except for the thread-per-client server in both the write-null (<<fig-writenull>>) and read-null (<<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 +thread-per-client server uses blocking socket operations, while the {aesop} socket resource uses non-blocking operations. Based on this observation, we implemented the thread-per-client-nb server to isolate the impact of non-blocking socket operations on performance. The thread-per-client-nb implementation is @@ -389,14 +391,14 @@ 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 thread-per-client server to the point that it is practically equivalent to -the Aesop server at scale. +the {aesop} server at scale. -Another notable observation in these graphs is that the Aesop server is +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 -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 +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. ==== Fairness @@ -419,7 +421,7 @@ image::fig/read-time.png[] In <<fig-writetime>> and <<fig-readtime>> we see that the event server is the only fair server. However, it achieves this fairness by sacrificing -overall throughput. During our initial experimentation, aesop was configured +overall throughput. During our initial experimentation, {aesop} was configured to be a fair system as it favored executing all disk and network operations in FIFO order if possible. We discovered that this behavior was detrimental to throughput in practice; the server performed better if it made progress @@ -461,7 +463,7 @@ metrics are graphed using a box and whiskers plot. The box represents the first and third quartiles and the whiskers are the minimum and maximum values. The following results are for the 1024 client size selected from the same iteration as the maximum runtime graphs. <<fig-writelat>> and -<<fig-readlat>> show aesop offers vary comparative latency performance +<<fig-readlat>> show {aesop} offers vary comparative latency performance as the other configurations and only notably thread-per-op and event are significantly worse. An interesting observation is that the overall fairness across clients shown in the previous section does not appear to correlate in @@ -475,43 +477,43 @@ image::fig/write-null-lat.png[] [[fig-readnulllat]] image::fig/read-null-lat.png[] -In <<fig-writenulllat>> and <<fig-readnulllat>> we see again that aesop has +In <<fig-writenulllat>> and <<fig-readnulllat>> we see again that {aesop} has very good latency metrics compared to the other servers. In this case the thread-per-op and event are noticeably worse than the other server implementations. ==== Summary -The runtime analysis shows that aesop is competitive with the most +The runtime analysis shows that {aesop} is competitive with the most optimal alternate server implementations at the 1024 client size. -In the _read_ test, aesop is 4.5% slower than the fastest implementation, -thread-pool. Aesop was the fastest implementation in the _write_ test. +In the _read_ test, {aesop} is 4.5% slower than the fastest implementation, +thread-pool. {aesop} was the fastest implementation in the _write_ test. The thread-per-client implementation was fastest in the _read null_ and -_write null_ tests. Here aesop is significantly slower at around 25-30%, +_write null_ tests. Here {aesop} is significantly slower at around 25-30%, however, as we showed above, the difference in performance was due to the native performance difference in synchronous and asynchronous sockets. -If we look at the performance comparison to the thread-per-client-nb, aesop +If we look at the performance comparison to the thread-per-client-nb, {aesop} was only 4.7% slower in the _read null_ test and was faster in the _write null_ -test. If aesop were using a native asynchronous transport such as InfiniBand verbs +test. If {aesop} were using a native asynchronous transport such as InfiniBand verbs or SSM, we believe that it would perform as well as a thread-per-client implementation. Another interesting factor was that there was no one fastest server implementation. Each workload presents a different challenge and building -a single tuned server is difficult. A key advantage of aesop is the ability -to change the underlying implementation or turning for the aesop +a single tuned server is difficult. A key advantage of {aesop} is the ability +to change the underlying implementation or turning for the {aesop} runtime without changing the server code. During our investigation we experimented with different underlying thread models for the network and -file resources of aesop. The aesop resources can be configured at runtime +file resources of {aesop}. The {aesop} resources can be configured at runtime to use the different thread models or tuning options. With the knowledge that building a specific server implementation, which is optimal for a generic -workload, is extremely difficult, aesop becomes powerful because these types of changes can be made +workload, is extremely difficult, {aesop} becomes powerful because these types of changes can be made without changing the server source. [[sec-memory]] == Runtime Memory Efficiency Another aspect of the overall performance is the memory efficiency of each -server implementation. In this section we compare aesop to the other server implementations +server implementation. In this section we compare {aesop} to the other server implementations using the same runtime performance experitment. === Experiment @@ -554,9 +556,9 @@ results (in addition to the thread pool server) because it is the only implementation which does not spawn any additional threads to handle increasing numbers of network connections. -Although the Aesop server cannot match the thread-pool server in terms of +Although the {aesop} server cannot match the thread-pool server in terms of memory usage, it does compare favorably to the thread-per-client and -thread-per op servers. In the read test, for example, Aesop consumes +thread-per op servers. In the read test, for example, {aesop} consumes roughly 10 MiB of paged in memory verses almost 18 MiB of paged in memory for the thread-per-client server at scale. @@ -568,7 +570,7 @@ to be a more relevant metric in practice. [[sec-productivity]] == Productivity -The core design element of aesop is to make programming of a concurrent +The core design element of {aesop} is to make programming of a concurrent server easier, so the trade off for memory and runtime performance should be worth it. To evaluate this we examine the code complexity of each of the server implementations. @@ -598,13 +600,13 @@ To simplify the comparison, error handling was excluded for all servers except for assertions on expected return codes. The protocol definition (ie, request and acknowledgment structs) as well as helper functions to loop over send and receive were not counted in any of the implementations, -as these were similar in all four. Also note that the Aesop version -does not include the Aesop standard library, which -provides a binding between Aesop and the standard POSIX socket API as part +as these were similar in all four. Also note that the {aesop} version +does not include the {aesop} standard library, which +provides a binding between {aesop} and the standard POSIX socket API as part of its default functionality. The focus of this comparison is on the core logic defining the server implementation. -The Aesop and thread-per-client servers are very similar in terms of +The {aesop} and thread-per-client servers are very similar in terms of complexity. The slight increase in complexity for the thread-per-client server results from the additional function calls needed to create and join threads. The @@ -615,7 +617,7 @@ calls is implemented in helper functions which are not included in the analysis. The thread-pool and event models are both much more complex than the -thread-per-client or aesop model. In the case of the thread-pool server, +thread-per-client or {aesop} model. In the case of the thread-pool server, this additional complexity arises from not only the queuing and thread management logic, but also the event loop which is necessary to detect incoming requests and dispatch them to the queue. The event server @@ -629,25 +631,25 @@ Although the event model appears less complex than the thread-pool model accordi Mod. CC, qualitatively it is significantly more challenging to develop. [[sec-overhead-analysis]] -== Sources of Aesop overhead +== Sources of {aesop} overhead -As we've seen aesop compares favorably to other concurrency models but loses +As we've seen {aesop} compares favorably to other concurrency models but loses some performance compared to the best case hand tuned version. Here we examine -the overheads associated with aesop. The first item to examine is the -cost associated with an aesop blocking call. +the overheads associated with {aesop}. The first item to examine is the +cost associated with an {aesop} blocking call. === Performance Implications of Blocking Calls -While this isn't immediately visible from looking at the aesop source code, +While this isn't immediately visible from looking at the {aesop} source code, blocking calls, when compared to a plain C function call, have extra overhead -due to the way they are transformed by the aesop compiler. The following +due to the way they are transformed by the {aesop} compiler. The following section highlights the sources of this overhead. ==== State Management Most of the overhead is caused by the need to preserve the state of the blocking call while execution (temporarily) switches to another -function. In order to preserve this state, the aesop compiler relocates all +function. In order to preserve this state, the {aesop} compiler relocates all function-scoped variables from the stack to the heap. When entering a blocking function, heap memory needs to be allocated for these variables. As allocating heap memory is much more time consuming than @@ -656,13 +658,13 @@ than calling a regular function. ==== Synchronization Overhead -A second source of overhead originates from the multi-threaded nature of aesop -code. While aesop does not create any threads, many of the aesop resources -internally use threads. Therefore, the aesop compiler has to ensure that the +A second source of overhead originates from the multi-threaded nature of {aesop} +code. While {aesop} does not create any threads, many of the {aesop} resources +internally use threads. Therefore, the {aesop} compiler has to ensure that the emitted code is multi-thread safe. For example, in the following code, two pbranches might be executing concurrently using different threads. Since these threads could both be modifying the pwait state simultaneously, -aesop +{aesop} uses locks to serialize their access. Locks, and other synchronization primitives account for most of the remaining performance difference between blocking and regular function calls. @@ -681,13 +683,13 @@ pwait { ---- [NOTE] -Currently, the aesop compiler uses a combination of atomic operations and +Currently, the {aesop} compiler uses a combination of atomic operations and mutexes to maintain thread-safety. There is an ongoing effort to convert to atomic operations where possible. ==== Quantifying Blocking Call Overhead -For this test, a regular C function and a aesop blocking function are +For this test, a regular C function and a {aesop} blocking function are called in a loop. By timing the total time required to complete the loop, an estimate of the time needed to execute the function call is obtained. @@ -727,14 +729,14 @@ The results for these are shown in the +tcmalloc+ column. The program used to obtain these results is in the repository: +tests/blocking-overhead.ae+. -From these results we see that an Aesop `__blocking` function is significantly +From these results we see that an {aesop} `__blocking` function is significantly slower than a basic C function. Test case 4 illustrates that almost all of this overhead is a result of the memory management and synchronization -performed by Aesop in order to enable efficient concurrency. +performed by {aesop} in order to enable efficient concurrency. -It is also important to note that Aesop is a superset of the C language, and +It is also important to note that {aesop} is a superset of the C language, and normal C functions (with the associated low overhead) can still be used in -an Aesop program. The `__blocking` functions are most appropriate for +an {aesop} program. The `__blocking` functions are most appropriate for functions that perform blocking device or resource operations, while standard C functions are better suited for computationally intense inner-loop routines. @@ -744,11 +746,11 @@ The main memory overhead incurred by blocking functions originates from the need to protect the logical state of the function while temporarily switching to other functions. Stack variables, function arguments, and return values must all be moved to the heap by the -aesop source translator. In a normal C program, those items consume -stack space. In addition, aesop internally maintains a number of control +{aesop} source translator. In a normal C program, those items consume +stack space. In addition, {aesop} internally maintains a number of control structures. Pointers to these structures are passed as function arguments to the blocking function, and consequently consume stack space. Currently, -aesop adds about 4 pointers and 2 integers to each blocking function call. +{aesop} adds about 4 pointers and 2 integers to each blocking function call. ==== Lonely pbranches @@ -774,11 +776,11 @@ consume memory until the pbranch returns. [[sec-compile]] == Compile Time Performance -Currently aesop imposes some overhead when compiling aesop source. -In a simple micro-benchmark an existing aesop source file was compiled and -then compiled again as straight C. The aesop source file contains 4043 +Currently {aesop} imposes some overhead when compiling {aesop} source. +In a simple micro-benchmark an existing {aesop} source file was compiled and +then compiled again as straight C. The {aesop} source file contains 4043 lines and is about 116 KB in size. The same source file is renamed to a .c -file and four +#define+s are added which redefine the aesop keywords to nothing. +file and four +#define+s are added which redefine the {aesop} keywords to nothing. The test was executed on a dual processor Intel Xeon E5620 running at 2.4 GHz with 24 GB of RAM. hooks/post-receive -- aesop Repository

1 0

aesop Repository branch, master, updated. b0785d6e139a5f5c069d6d19e7693e1c15673e3a
by noreply＠mcs.anl.gov 28 Feb '12

28 Feb '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 "aesop Repository". The branch, master has been updated via b0785d6e139a5f5c069d6d19e7693e1c15673e3a (commit) from 1c8b47c687ba880e03d835d94fba581bd537f5dc (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 b0785d6e139a5f5c069d6d19e7693e1c15673e3a Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Tue Feb 28 16:13:56 2012 -0600 Add [source,c] tag to all code listings in the aesop user guide. ----------------------------------------------------------------------- Summary of changes: doc/aug_external.txt | 11 +++++++++++ doc/aug_language.txt | 45 ++++++++++++++++++++++++++++----------------- doc/aug_preface.txt | 1 + doc/aug_standard.txt | 19 +++++++++++++++++++ 4 files changed, 59 insertions(+), 17 deletions(-) Diff of changes: diff --git a/doc/aug_external.txt b/doc/aug_external.txt index 5a4ec25..d091ce1 100644 --- a/doc/aug_external.txt +++ b/doc/aug_external.txt @@ -55,6 +55,7 @@ This section discusses how to make a blocking aesop write function on top of the POSIX AIO asynchronous I/O functions. +[source,c] ---- static void aesop_write_complete (union sigval) { @@ -127,6 +128,7 @@ Building Blocking Functions using the Thread module Consider the POSIX open function: +[source,c] ---- int open (const char * pathname, int flags); ---- @@ -140,6 +142,7 @@ parent thread to continue executing other code where possible. The thread module can simplify implementing this technique: +[source,c] ---- ___blocking int aesop_open (const char * pathname, int flags) { @@ -211,6 +214,7 @@ A resource can define a new blocking call by using the `ae_define_post` macro. For example: +[source,c] ---- ae_define_post (int, rb_slot_capture, rb_slot_t * slot) { @@ -220,6 +224,7 @@ ae_define_post (int, rb_slot_capture, rb_slot_t * slot) The code above generates the following aesop prototype: +[source,c] ---- __blocking int rb_slot_capture (rb_slot_t * slot); ---- @@ -263,6 +268,7 @@ Generating the Operation ID The following function creates a new operation id: +[source,c] ---- ae_op_id_t ae_id_gen (int resource_id, uintptr_t data); ---- @@ -275,6 +281,7 @@ The `resource_id` value is provided when registering the resource (see The private data can be retrieved using the `ae_id_lookup` function. +[source,c] ---- uintptr_t ae_id_lookup (ae_op_id_t id, int * resource_id); ---- @@ -311,6 +318,7 @@ stack *before* completing the blocking function. For example (from ResourceBuilder): +[source,c] ---- void (*callback) (void *, int) = op.callback; /* op = struct ae_op */ void * user_ptr = op.user_ptr; @@ -344,6 +352,7 @@ internally). The header `resource.h` defines the following structure: +[source,c] ---- struct ae_resource { @@ -382,6 +391,7 @@ The new resource should be registered with aesop using the `ae_resource_register function. The internal ID for the resource (used in creating an operation ID) is returned in `*newid`. +[source,c] ---- int ae_resource_register (struct ae_resource *resource, int *newid); void ae_resource_unregister (int resource_id); @@ -405,6 +415,7 @@ specifying configuration parameters for that resource using the `config_array` field is a `NULL` terminated array of structs of type `struct ae_resource_config`, which is defined as follows: +[source,c] ---- struct ae_resource_config { diff --git a/doc/aug_language.txt b/doc/aug_language.txt index a9c1d0c..77d0432 100644 --- a/doc/aug_language.txt +++ b/doc/aug_language.txt @@ -69,6 +69,7 @@ The `__blocking` qualifier All blocking functions must be marked as such. Below is an example of a blocking function. +[source,c] ---- __blocking int test (void); ---- @@ -76,6 +77,7 @@ __blocking int test (void); It is also possible to declare a pointer to a blocking function, similar to declaring a pointer to a regular function. +[source,c] ---- __blocking int (*test) (void); ---- @@ -83,6 +85,7 @@ __blocking int (*test) (void); The `__blocking` qualifier is part of the type. Therefore, the following two function pointers have distinct types and cannot be assigned to each other. +[source,c] ---- void (*func1) (int); __blocking void (*func2) (int); @@ -157,24 +160,25 @@ Parallel Branches The best way to introduce parallel branches is through an example: +[source,c,numbered] ---- -1 __blocking void example (void) -2 { -3 pwait -4 { -5 pbranch -6 { -7 printf ("In branch 1\n"); -8 aesop_timer (10000); -9 } -10 pbranch -11 { -12 printf ("In branch 2\n"); -13 aesop_timer (10000); -14 } -15 } -16 printf ("After pwait\n"); -17 } +__blocking void example (void) +{ + pwait + { + pbranch + { + printf ("In branch 1\n"); + aesop_timer (10000); + } + pbranch + { + printf ("In branch 2\n"); + aesop_timer (10000); + } + } + printf ("After pwait\n"); +} ---- The function `aesop_timer` (discussed in <<ref-timer>>) suspends execution for @@ -235,6 +239,7 @@ using the `pbreak` keyword. The effect of `pbreak` is similar to that of `break` in a `for` or `while` loop. .Example +[source,c] ----- pbranch @@ -267,6 +272,7 @@ value of the shared variable. The `pprivate` keyword is especially relevant for pbranches created within `for` and `while` loops. The code below shows an example. +[source,c] ---- pwait { @@ -327,6 +333,7 @@ signal set, and 0 otherwise. .Example +[source,c] ---- __blocking void cancel_example (void) { @@ -364,6 +371,7 @@ pbranch executes as normal but it not possible to wait for the branch to complete. +[source,c] ---- __blocking example_lonely (void) { @@ -404,6 +412,7 @@ The `main` function for an aesop program is identified using `aesop_main_set`. The named function must be a blocking function, and must take the same arguments as the standard C `main` function. +[source,c] ---- int aesop_main (int argc, char ** args) { @@ -424,6 +433,7 @@ usual. .Example: +[source,c] ---- aesop_main_set_with_init (pre_init, aesop_main); ---- @@ -435,6 +445,7 @@ Hello World Below is an example aesop program. +[source,c] ---- #include <aesop.h> #include <timer.hae> diff --git a/doc/aug_preface.txt b/doc/aug_preface.txt index 88d1fcb..f0681eb 100644 --- a/doc/aug_preface.txt +++ b/doc/aug_preface.txt @@ -37,6 +37,7 @@ Source code and shell commands Example source code, or example commands are rendered as follows: +[source,c] ---- printf ("Example code\n"); ---- diff --git a/doc/aug_standard.txt b/doc/aug_standard.txt index d43e00b..4232a3b 100644 --- a/doc/aug_standard.txt +++ b/doc/aug_standard.txt @@ -22,6 +22,7 @@ Querying and setting configuration parameters The following function can be used to set arbitrary configuration parameters: +[source,c] ---- int aesop_set_config(const char* key, const char* value); ---- @@ -66,6 +67,7 @@ The following components can be traced: The `aesop_set_debugging` call can be used to enable or disable tracing for a component. +[source,c] ---- int aesop_set_debugging (const char * what, int value); ---- @@ -94,6 +96,7 @@ Timer Header: `timer.hae` +[source,c] ---- int aesop_timer_init(void); void aesop_timer_finalize(void); @@ -105,6 +108,7 @@ as one call to `aesop_timer_finalize` is made for every call to `aesop_timer_init`. +[source,c] ----- __blocking int aesop_timer(int millisecs); ---- @@ -118,6 +122,7 @@ Socket Header: `aesocket.hae` +[source,c] ----- int aesocket_init (void); int aesocket_finalize (void); @@ -126,6 +131,7 @@ int aesocket_finalize (void); Module initialization functions. +[source,c] ---- int aesocket_prepare (int fd); ---- @@ -135,6 +141,7 @@ Before a socket can be used with the aesocket functions, it needs some tuning function takes care of this. This function might change the blocking/non-blocking nature of the given descriptor. +[source,c] ---- __blocking int aesocket_accept( int sockfd, @@ -154,6 +161,7 @@ error occurred (returned in `*err`) occurred. NOTE: It is not necessary to call `aesocket_prepare` on the descriptors returned by this function. +[source,c] ----- __blocking int aesocket_read( int fd, @@ -171,6 +179,7 @@ bytes read into `buf` is returned in `*ret`. +[source,c] ---- __blocking int aesocket_write( int fd, @@ -181,6 +190,7 @@ __blocking int aesocket_write( ---- Similar to `aesocket_read`, but writes data to the socket instead. +[source,c] ---- __blocking int aesocket_ready (int fd, int flags, int * err); ---- @@ -203,6 +213,7 @@ File Header: `aefile.hae` +[source,c] ---- int aefile_init(void); void aefile_finalize(void); @@ -212,6 +223,7 @@ calling any of the functions below. +[source,c] ---- __blocking ssize_t aefile_pwrite(int fd, const void *buf, size_t count, off_t offset); __blocking ssize_t aefile_pread(int fd, void *buf, size_t count, off_t offset); @@ -236,6 +248,7 @@ ResourceBuilder Header: `resourcebuilder.hae` +[source,c] ---- void rb_slot_initialize (rb_slot_t * slot); ---- @@ -244,6 +257,7 @@ void rb_slot_initialize (rb_slot_t * slot); Prepare a slot for use by the `rb_slot_capture` function. +[source,c] ---- __blocking int rb_slot_capture (rb_slot_t * slot); ---- @@ -258,6 +272,7 @@ to a cancellation request. After a call to this function, the slot needs to be destroyed (using `rb_slot_destroy` and reinitialized before it can be used again. +[source,c] ---- int rb_slot_complete (rb_slot_t * slot); ---- @@ -267,6 +282,7 @@ released a `rb_slot_capture` call on the slot. If the slot was not active (for example because it was already cancelled), an unspecified aesop error code is returned. +[source,c] ---- void rb_slot_destroy (rb_slot_t * slot); ---- @@ -294,6 +310,7 @@ Header: `aethread.hae` The following functions are used to intialize and shut down the thread module. +[source,c] ---- int aethread_init(void); void aethread_finalize(void); @@ -302,12 +319,14 @@ void aethread_finalize(void); The thread module provides the concept of a thread group. Groups are created with a certain size, and cannot grow beyond this size. +[source,c] ---- struct aethread_group * aethread_create_group_pool(int size); void aethread_destroy_group(struct aethread_group * group); ---- +[source,c] ---- __blocking int aethread_hint(struct aethread_group * group); ---- hooks/post-receive -- aesop Repository

1 0

aesop Repository branch, master, updated. 1c8b47c687ba880e03d835d94fba581bd537f5dc
by noreply＠mcs.anl.gov 28 Feb '12

28 Feb '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 "aesop Repository". The branch, master has been updated via 1c8b47c687ba880e03d835d94fba581bd537f5dc (commit) from 6d34f4254d99b1e78fc26ba08e667c9851b3cdde (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 1c8b47c687ba880e03d835d94fba581bd537f5dc Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Tue Feb 28 15:46:46 2012 -0600 Minor edits to aug_external.txt ----------------------------------------------------------------------- Summary of changes: doc/aug_external.txt | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) Diff of changes: diff --git a/doc/aug_external.txt b/doc/aug_external.txt index b51fad5..5a4ec25 100644 --- a/doc/aug_external.txt +++ b/doc/aug_external.txt @@ -107,7 +107,7 @@ the `aio_write_complete` callback and complete the slot. Since the `rb_slot_capture` function is blocking, aesop can switch execution elsewhere until the slot is either completed (by the completion of the write operation) or until the call is cancelled (by a call to `ae_cancel_branches`), -in which case the capture function will return with an error. +in which case the `rb_slot_capture` function will return with an error. @@ -302,7 +302,7 @@ completed. The first parameter (`void *`) needs to be set to the `user_ptr` when calling the function. Completing a blocking function can then be done by calling the callback -provided by the stored in the `ae_op` structure (and filled in by the +provided by the `ae_op` structure (and filled in by the `ae_op_fill` macro). WARNING: The `ae_op` structure can be modified by the callback in certain hooks/post-receive -- aesop Repository

1 0

aesop Repository branch, master, updated. 6d34f4254d99b1e78fc26ba08e667c9851b3cdde
by noreply＠mcs.anl.gov 28 Feb '12

28 Feb '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 "aesop Repository". The branch, master has been updated via 6d34f4254d99b1e78fc26ba08e667c9851b3cdde (commit) from f6ce31fb24d5ea9db0ebb21095c41061009337f2 (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 6d34f4254d99b1e78fc26ba08e667c9851b3cdde Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Tue Feb 28 15:28:49 2012 -0600 Minor edits to aug_standard.txt ----------------------------------------------------------------------- Summary of changes: doc/aug_standard.txt | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) Diff of changes: diff --git a/doc/aug_standard.txt b/doc/aug_standard.txt index 3b0c841..d43e00b 100644 --- a/doc/aug_standard.txt +++ b/doc/aug_standard.txt @@ -91,7 +91,7 @@ The following modules are bundled with the aesop distribution. Timer ~~~~~~ -Header: `triton.timer.hae` +Header: `timer.hae` ---- @@ -110,7 +110,7 @@ __blocking int aesop_timer(int millisecs); ---- The `aesop_timer` function will sleep for the given number of milliseconds. -The functions returns 0 on success, `-ECANCELED` if canceled before the sleep +The functions returns 0 on success, `-ECANCELED` if cancelled before the sleep time is over. Socket @@ -144,11 +144,11 @@ __blocking int aesocket_accept( int * err); ---- -The aesop version of the accept system call. -Unlike the system call, the descriptor for the new connection is returned in +In the aesop version of the accept system call, +unlike the system call, the descriptor for the new connection is returned in `*newfd`, while an error, if any, is returned in `*err`. The function returns `AE_SUCCESS` when a new connection is accepted, -`AE_ERR_CANCELED` if the call was canceled and `AE_ERR_OTHER` if a system call +`AE_ERR_CANCELED` if the call was cancelled and `AE_ERR_OTHER` if a system call error occurred (returned in `*err`) occurred. NOTE: It is not necessary to call `aesocket_prepare` on the descriptors @@ -163,9 +163,9 @@ __blocking int aesocket_read( int * err); ---- Read `count` bytes from the given socket. This call will not return -until an error occurred or at `count` bytes were read from the socket. +until an error occurred or `count` bytes were read from the socket. The function returns `AE_SUCCESS` if the requested number of bytes was read, -`AE_ERR_CANCELED` if the call was canceled and `AE_ERR_OTHER` if another error +`AE_ERR_CANCELED` if the call was cancelled and `AE_ERR_OTHER` if another error occured, in which case `*err` is set to the POSIX error code. The number of bytes read into `buf` is returned in `*ret`. @@ -179,7 +179,7 @@ __blocking int aesocket_write( int *ret, int * err); ---- -As `aesocket_read`, but writes data to the socket instead. +Similar to `aesocket_read`, but writes data to the socket instead. ---- __blocking int aesocket_ready (int fd, int flags, int * err); @@ -188,7 +188,7 @@ __blocking int aesocket_ready (int fd, int flags, int * err); The `aesocket_ready` call waits until the passed in descriptor is ready to perform the action specified in `flags`. `Flags` can be a combination of `AESOCKET_READ` or `AESOCKET_WRITE`. -The function returns `AE_ERR_CANCELED` when canceled, `AE_ERR_OTHER` when an +The function returns `AE_ERR_CANCELED` when cancelled, `AE_ERR_OTHER` when an error was returned by the underlying system call, and `AE_SUCCESS` otherwise. In case of `AE_ERR_OTHER`, the error code is stored in `*err`. @@ -241,7 +241,7 @@ void rb_slot_initialize (rb_slot_t * slot); ---- `rb_slot_t` is an opaque datatype. -Prepare a slot for using with the `rb_slot_capture` function. +Prepare a slot for use by the `rb_slot_capture` function. ---- hooks/post-receive -- aesop Repository

1 0

[aesop] #25: add configure-time checks for compatible underlying compilers
by aesop 28 Feb '12

28 Feb '12

#25: add configure-time checks for compatible underlying compilers ---------------------------+------------------------------------------------ Reporter: carns | Owner: Type: enhancement | Status: new Priority: minor | Component: build system Version: git repository | Keywords: ---------------------------+------------------------------------------------ gcc and clang are the only two compilers that can be made to work with the current source translator. Other compilers will likely produce a variety of confusing errors at build time. -- Ticket URL: <http://trac.mcs.anl.gov/projects/aesop/ticket/25> aesop <https://trac.mcs.anl.gov/projects/aesop> The Aesop Language

1 0

Re: [ASG] [aesop] #7: integrate library linking and paths with aecc
by aesop 28 Feb '12

28 Feb '12

#7: integrate library linking and paths with aecc ---------------------------+------------------------------------------------ Reporter: carns | Owner: somebody Type: defect | Status: new Priority: major | Component: code generator Version: git repository | Keywords: ---------------------------+------------------------------------------------ Comment(by carns): It should also use an underlying compiler specified at aesop configure time by default. We can still allow it to be overridden with a -c or -cc argument, but that should not be required. -- Ticket URL: <http://trac.mcs.anl.gov/projects/aesop/ticket/7#comment:3> aesop <https://trac.mcs.anl.gov/projects/aesop> The Aesop Language

1 0

aesop Repository branch, master, updated. f6ce31fb24d5ea9db0ebb21095c41061009337f2
by noreply＠mcs.anl.gov 28 Feb '12

28 Feb '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 "aesop Repository". The branch, master has been updated via f6ce31fb24d5ea9db0ebb21095c41061009337f2 (commit) from a3ac9a69b1bb6965f2727af7deef3175877c7548 (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 f6ce31fb24d5ea9db0ebb21095c41061009337f2 Author: Kevin Harms <harms(a)alcf.anl.gov> Date: Tue Feb 28 14:43:18 2012 -0600 Minor edits to aug_language.txt ----------------------------------------------------------------------- Summary of changes: doc/aug_language.txt | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) Diff of changes: diff --git a/doc/aug_language.txt b/doc/aug_language.txt index 5c7a230..a9c1d0c 100644 --- a/doc/aug_language.txt +++ b/doc/aug_language.txt @@ -63,7 +63,7 @@ execution, and are used by aesop to introduce concurrency to the C language. -The `__blocking` qualifyier +The `__blocking` qualifier ~~~~~~~~~~~~~~~~~~~~~~~~~~~ All blocking functions must be marked as such. Below is an example of a @@ -138,7 +138,7 @@ execution to code that is ready to execute while waiting for the external event to occur. For example, a function reading data from the network or a disk will typically -be blocking, since the function I/O bound. If the function is blocking, as +be blocking, since the function is I/O bound. If the function is blocking, as soon as the processor core would become idle, execution can continue elsewhere. If the function is not blocking, the processor core would become idle until the read completes. @@ -285,7 +285,7 @@ In the example above, each pbranch will get a private copy of the loop variable `i`. Since the next iteration of the loop does not depend on the completion of the pbranch, `pprivate` is required here to prevent changes to the value of `i` in a pbranch while the branch is still executing. -In this case, `pprivate` required, as manually assigning `i` to a private copy +In this case, `pprivate` is required, as manually assigning `i` to a private copy would be prone to a race condition. @@ -360,7 +360,7 @@ Lonely pbranches ~~~~~~~~~~~~~~~~~ It is possible to use a `pbranch` outside of `pwait`. In this case, the -pbranch executes as normal but it not possible to wait for the branch +pbranch executes as normal but it not possible to wait for the branch to complete. hooks/post-receive -- aesop Repository

1 0