nemo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From won...@apache.org
Subject [incubator-nemo-website] 14/18: coral -> nemo
Date Sun, 04 Mar 2018 06:06:51 GMT
This is an automated email from the ASF dual-hosted git repository.

wonook pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/incubator-nemo-website.git

commit bde9dca9625aa52c8e0fe2b48326d904e1f94f77
Author: Joo Yeon Kim <jykim88@gmail.com>
AuthorDate: Tue Feb 20 14:46:15 2018 +0900

    coral -> nemo
---
 _docs/designs/compiler_design.md          |  14 +++++++-------
 _docs/designs/runtime_design.md           |  14 +++++++-------
 _docs/getting_started.md                  |  26 +++++++++++++-------------
 _docs/index.md                            |   8 ++++----
 _docs/optimization/extending_nemo.md      |   6 ++++++
 _docs/optimization/extending_onyx.md      |   6 ------
 _docs/optimization/ir.md                  |   6 +++---
 _docs/optimization/passes_and_policies.md |  12 ++++++------
 _includes/topnav.html                     |   2 +-
 css/main.scss                             |   4 ++--
 favicon.ico                               | Bin 1150 -> 1150 bytes
 img/bg.jpg                                | Bin 1173908 -> 411341 bytes
 img/nemo.png                              | Bin 0 -> 4979 bytes
 index.html                                |  22 +++++++++++-----------
 14 files changed, 60 insertions(+), 60 deletions(-)

diff --git a/_docs/designs/compiler_design.md b/_docs/designs/compiler_design.md
index dc35c24..6c92e02 100644
--- a/_docs/designs/compiler_design.md
+++ b/_docs/designs/compiler_design.md
@@ -7,25 +7,25 @@ permalink: /docs/compiler_design/
 
 Compiler takes an arbitrary dataflow program as input, and outputs an optimized physical
execution plan to be understood by the execution runtime. The steps are as followings:
 
-1. **Compiler frontend** first translates the logical layer of given dataflow program written
in high-level languages, like Apache Beam, into an expressive, general-purpose [Coral Intermediate
Representation (IR)](../ir).
+1. **Compiler frontend** first translates the logical layer of given dataflow program written
in high-level languages, like Apache Beam, into an expressive, general-purpose [Nemo Intermediate
Representation (IR)](../ir).
 2. Then using the [optimization pass](../passes_and_policies) interface provided by the **Compiler
optimizer**, the IR can be flexibly reshaped and annotated with a variety of execution properties
that configures the underlying runtime behaviors.
-3. After being processed by _optimization passes_, the **Compiler backend** finally lays
out the IR into a physical execution plan, composed of tasks and stages, to be carried out
by the [Coral Execution Runtime](../runtime_design).
+3. After being processed by _optimization passes_, the **Compiler backend** finally lays
out the IR into a physical execution plan, composed of tasks and stages, to be carried out
by the [Nemo Execution Runtime](../runtime_design).
 
 ### Frontend
 
-The frontend of *Coral Compiler* translates arbitrary high-level dataflow languages, like
Apache Beam, into our expression of [Coral IR](../ir) with an elementary annotation of default
*execution properties*.
+The frontend of *Nemo Compiler* translates arbitrary high-level dataflow languages, like
Apache Beam, into our expression of [Nemo IR](../ir) with an elementary annotation of default
*execution properties*.
 **Frontend** for different languages are designed as visitors that traverse given applications
written in high-level dataflow languages in a topological order.
-While traversing the logic, it translates each dataflow operators and edges on the way, and
appends the translated IR components to the *Coral IR builder*.
+While traversing the logic, it translates each dataflow operators and edges on the way, and
appends the translated IR components to the *Nemo IR builder*.
 After completing the traversal, the IR builder builds the logical part of the IR after checking
its integrity.
 Integrity check ensures a few factors, such as ensuring vertices without any incoming edges
to read source data.
 
 ### Optimizer
 
-After the IR is created with its logical structures set up, we need an [Coral policy](../passes_and_policies)
to optimize the application for a specific goal.
-To build Coral policies safely and correctly, we provide a *policy builder* interface, which
checks for the integrity while registering series of passes in a specific order.
+After the IR is created with its logical structures set up, we need an [Nemo policy](../passes_and_policies)
to optimize the application for a specific goal.
+To build Nemo policies safely and correctly, we provide a *policy builder* interface, which
checks for the integrity while registering series of passes in a specific order.
 
 For example, if an annotating pass requires information of specific *execution properties*
to perform its work, we specify them as *prerequisite execution properties*, and check the
order and the content of registered passes to ensure that the conditions have been met.
-We avoid the cases where circular dependencies occur, through the default execution properties
that we provide at the initiation of the Coral IR.
+We avoid the cases where circular dependencies occur, through the default execution properties
that we provide at the initiation of the Nemo IR.
 
 Using the policy, the optimizer applies each *optimization passes* one-by-one in the provided
order, and checks for the IR integrity after each optimization has been done, to ensure that
the [IR](../ir) is not broken.
 
diff --git a/_docs/designs/runtime_design.md b/_docs/designs/runtime_design.md
index 4d8d3a3..59c3cd8 100644
--- a/_docs/designs/runtime_design.md
+++ b/_docs/designs/runtime_design.md
@@ -3,24 +3,24 @@ title: Runtime Design
 permalink: /docs/runtime_design/
 ---
 
-### Receiving a Job from the Coral Compiler
+### Receiving a Job from the Nemo Compiler
 
-After the compiler goes through a set of passes for optimization, the optimized Coral IR
is translated into into a 
+After the compiler goes through a set of passes for optimization, the optimized Nemo IR is
translated into into a 
 physical form for the execution runtime to execute. This involves translations like expanding
an operator annotated 
-with parallelism in Coral IR to the desired number of tasks and connecting the tasks according
to the data communication 
+with parallelism in Nemo IR to the desired number of tasks and connecting the tasks according
to the data communication 
 patterns annotated on the IR edges. Physical execution plan is also in the form of a DAG,
with the same values annotated 
-for execution properties as the given IR DAG if necessary. Coral IR DAG and physical execution
plan can be translated 
+for execution properties as the given IR DAG if necessary. Nemo IR DAG and physical execution
plan can be translated 
 from one another by sharing the identifiers.
 
 ### Runtime Architecture
-The Coral runtime consists of a _RuntimeMaster_ and multiple _Executors_.
+The Nemo runtime consists of a _RuntimeMaster_ and multiple _Executors_.
 _RuntimeMaster_ takes the submitted physical execution plan and schedules each _TaskGroup_
to _Executor_ for execution.
 
-The figure below shows the Coral runtime's overall architecture.
+The figure below shows the Nemo runtime's overall architecture.
 Our runtime's components can be broken down into two parts, the processing backbone and the
extensible modules.
 
 The processing backbone illustrated by the blue double stroked boxes in the figure below,
-implements the inherent and basic code that must be executed for all Coral jobs
+implements the inherent and basic code that must be executed for all Nemo jobs
 (and potentially all data processing jobs). 
 The code includes references to the flexible and extensible data structures 
 representing our execution properties. 
diff --git a/_docs/getting_started.md b/_docs/getting_started.md
index a00c2c5..40e81e8 100644
--- a/_docs/getting_started.md
+++ b/_docs/getting_started.md
@@ -26,7 +26,7 @@ permalink: /docs/getting_started/
         * `sudo make install`
     3. To check for a successful installation of version 2.5.0, run `protoc --version`
 
-### Installing Coral 
+### Installing Nemo 
 * Run all tests and install: `mvn clean install -T 2C`
 * Run only unit tests and install: `mvn clean install -DskipITs -T 2C`
 
@@ -37,18 +37,18 @@ permalink: /docs/getting_started/
 
 ```bash
 ./bin/run_external_app.sh \
-`pwd`/coral_app/target/bd17f-1.0-SNAPSHOT.jar \
+`pwd`/nemo_app/target/bd17f-1.0-SNAPSHOT.jar \
 -job_id mapreduce \
--executor_json `pwd`/coral_runtime/config/default.json \
+-executor_json `pwd`/nemo_runtime/config/default.json \
 -user_main MapReduce \
--user_args "`pwd`/mr_input_data `pwd`/coral_output/output_data"
+-user_args "`pwd`/mr_input_data `pwd`/nemo_output/output_data"
 ```
 
 ### Configurable options
 * `-job_id`: ID of the Beam job
 * `-user_main`: Canonical name of the Beam application
 * `-user_args`: Arguments that the Beam application accepts
-* `-optimization_policy`: Canonical name of the optimization policy to apply to a job DAG
in Coral Compiler
+* `-optimization_policy`: Canonical name of the optimization policy to apply to a job DAG
in Nemo Compiler
 * `-deploy_mode`: `yarn` is supported(default value is `local`)
 
 ### Examples
@@ -56,16 +56,16 @@ permalink: /docs/getting_started/
 ## MapReduce example
 ./bin/run.sh \
   -job_id mr_default \
-  -user_main edu.snu.coral.examples.beam.MapReduce \
-  -optimization_policy edu.snu.coral.compiler.optimizer.policy.DefaultPolicy \
+  -user_main edu.snu.nemo.examples.beam.MapReduce \
+  -optimization_policy edu.snu.nemo.compiler.optimizer.policy.DefaultPolicy \
   -user_args "`pwd`/src/main/resources/sample_input_mr `pwd`/src/main/resources/sample_output"
 
 ## YARN cluster example
 ./bin/run.sh \
   -deploy_mode yarn \
   -job_id mr_pado \
-  -user_main edu.snu.coral.examples.beam.MapReduce \
-  -optimization_policy edu.snu.coral.compiler.optimizer.policy.PadoPolicy \
+  -user_main edu.snu.nemo.examples.beam.MapReduce \
+  -optimization_policy edu.snu.nemo.compiler.optimizer.policy.PadoPolicy \
   -user_args "hdfs://v-m:9000/sample_input_mr hdfs://v-m:9000/sample_output_mr"
 ```
 
@@ -103,16 +103,16 @@ This example configuration specifies
 * 1 reserved container with 2 cores and 1024MB memory
 
 ## Monitoring your job using web UI
-Coral Compiler and Runtime can store JSON representation of intermediate DAGs.
+Nemo Compiler and Runtime can store JSON representation of intermediate DAGs.
 * `-dag_dir` command line option is used to specify the directory where the JSON files are
stored. The default directory is `./dag`.
-Using our [online visualizer](https://service.jangho.io/Coral-dag/), you can easily visualize
a DAG. Just drop the JSON file of the DAG as an input to it.
+Using our [online visualizer](https://service.jangho.io/Nemo-dag/), you can easily visualize
a DAG. Just drop the JSON file of the DAG as an input to it.
 
 ### Examples
 ```bash
 ./bin/run.sh \
   -job_id als \
-  -user_main edu.snu.coral.examples.beam.AlternatingLeastSquare \
-  -optimization_policy edu.snu.coral.compiler.optimizer.policy.PadoPolicy \
+  -user_main edu.snu.nemo.examples.beam.AlternatingLeastSquare \
+  -optimization_policy edu.snu.nemo.compiler.optimizer.policy.PadoPolicy \
   -dag_dir "./dag/als" \
   -user_args "`pwd`/src/main/resources/sample_input_als 10 3"
 ```
diff --git a/_docs/index.md b/_docs/index.md
index 6bc44d2..1fd581a 100644
--- a/_docs/index.md
+++ b/_docs/index.md
@@ -4,16 +4,16 @@ permalink: /docs/home/
 redirect_from: /docs/index.html
 ---
 
-Coral aims to optimize data processing for better performance and datacenter efficiency,
not only in general and common conditions, but also with various *deployment characteristics*.
+Nemo aims to optimize data processing for better performance and datacenter efficiency, not
only in general and common conditions, but also with various *deployment characteristics*.
 Such characteristics include processing data on *specific resource environments*, like transient
resources, and running *jobs with specific attributes*, like skewed data.
 
 There exists many data processing systems with different designs to solve each of such problems
it targets, but it fails to cover or adapt to unconsidered cases without substantial effort
for modification.
 The primary reason is because system runtime behaviors are hidden and planted inside the
system core to hide the complexity of distributed computing.
 This makes it very hard for a single system to support different *deployment characteristics*
with different *runtime behaviors* without substantial effort.
 
-To solve this problem and easily modify *runtime behaviors* for different *deployment characteristics*,
Coral expresses workloads using the [Coral Intermediate Representation (IR)](../ir), which
represents the logical notion of data processing applications and its runtime behaviors on
separate layers.
-These layers can be easily modified through a set of high-level [graph pass](../passes_and_policies)
interfaces, exposed by the [Coral Compiler](../compiler_design), enabling users to flexibly
modify *runtime behaviors* at both compile-time and runtime.
-Works represented this way can be executed by the [Coral Execution Runtime](../runtime_design)
through its [modular and extensible](../extending_Coral) design.
+To solve this problem and easily modify *runtime behaviors* for different *deployment characteristics*,
Nemo expresses workloads using the [Nemo Intermediate Representation (IR)](../ir), which represents
the logical notion of data processing applications and its runtime behaviors on separate layers.
+These layers can be easily modified through a set of high-level [graph pass](../passes_and_policies)
interfaces, exposed by the [Nemo Compiler](../compiler_design), enabling users to flexibly
modify *runtime behaviors* at both compile-time and runtime.
+Works represented this way can be executed by the [Nemo Execution Runtime](../runtime_design)
through its [modular and extensible](../extending_Nemo) design.
 
 <br>
 <div class="text-center">
diff --git a/_docs/optimization/extending_nemo.md b/_docs/optimization/extending_nemo.md
new file mode 100644
index 0000000..299b171
--- /dev/null
+++ b/_docs/optimization/extending_nemo.md
@@ -0,0 +1,6 @@
+---
+title: Extending Nemo
+permalink: /docs/extending_nemo/
+---
+
+### Overview
diff --git a/_docs/optimization/extending_onyx.md b/_docs/optimization/extending_onyx.md
deleted file mode 100644
index 1a280d6..0000000
--- a/_docs/optimization/extending_onyx.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: Extending Coral
-permalink: /docs/extending_coral/
----
-
-### Overview
diff --git a/_docs/optimization/ir.md b/_docs/optimization/ir.md
index f6362d7..0dca25f 100644
--- a/_docs/optimization/ir.md
+++ b/_docs/optimization/ir.md
@@ -1,5 +1,5 @@
 ---
-title: Coral Intermediate Representation (IR)
+title: Nemo Intermediate Representation (IR)
 permalink: /docs/ir/
 ---
 
@@ -12,8 +12,8 @@ On that layer, we can annotate specific execution properties related to
the IR c
 
 ### IR structure
 
-Coral IR is composed of vertices, which each represent a data-parallel operator that transforms
data, and edges between them, which each represents the dependency of data flow between the
vertices.
-Coral IR supports four different types of IR vertices:
+Nemo IR is composed of vertices, which each represent a data-parallel operator that transforms
data, and edges between them, which each represents the dependency of data flow between the
vertices.
+Nemo IR supports four different types of IR vertices:
 
 - **UDF Vertex**: Most commonly used vertex. Each UDF vertex contains a transform which determines
the actions to take for the given input data. A transform can express any kind of data processing
operation that high-level languages articulate.
 - **Source Vertex**: This produces data by reading from an arbitrary source like disks and
distributed filesystems.
diff --git a/_docs/optimization/passes_and_policies.md b/_docs/optimization/passes_and_policies.md
index a99a578..19d2175 100644
--- a/_docs/optimization/passes_and_policies.md
+++ b/_docs/optimization/passes_and_policies.md
@@ -5,22 +5,22 @@ permalink: /docs/passes_and_policies/
 
 ### Optimization Passes
 
-The [Coral IR](../ir) can be flexibly modified, both in its logical structure and annotations,
through an interface called *Coral optimization pass*.
-An *optimization pass* is basically a function that takes an *Coral IR* and outputs an optimized
*Coral IR*.
+The [Nemo IR](../ir) can be flexibly modified, both in its logical structure and annotations,
through an interface called *Nemo optimization pass*.
+An *optimization pass* is basically a function that takes an *Nemo IR* and outputs an optimized
*Nemo IR*.
 
 ##### Compile-time passes
 
 The modification during compile-time can be categorized in different ways:
 
-1. **Reshaping passes** modify the shape of the IR itself by inserting, regrouping, or deleting
IR vertices and edges on an Coral IR, such as collecting repetitive vertices inside a single
loop or inserting metric vertices. This modifies the logical notion of data processing applications.
+1. **Reshaping passes** modify the shape of the IR itself by inserting, regrouping, or deleting
IR vertices and edges on an Nemo IR, such as collecting repetitive vertices inside a single
loop or inserting metric vertices. This modifies the logical notion of data processing applications.
 2. **Annotating passes** annotate IR vertices and edges with *execution properties* with
the provided logic to adjust and run the workload in the fashion that the user wants.
 3. **Composite passes** are collections of passes that are grouped together for convenience.
 
 ##### Run-time passes
 
-After the compilation and compile-time optimizations, the *Coral IR* gets laid out as a *physical
execution plan* to be submitted to and executed by the *Coral Execution Runtime*.
+After the compilation and compile-time optimizations, the *Nemo IR* gets laid out as a *physical
execution plan* to be submitted to and executed by the *Nemo Execution Runtime*.
 While execution, an *run-time optimization pass* can be performed to perform dynamic optimizations,
like solving data skew, using runtime statistics.
-It takes the old *Coral IR* and metric data of runtime statistics, and sends the newly optimized
Coral IR to execution runtime for the physical plan to be updated accordingly.
+It takes the old *Nemo IR* and metric data of runtime statistics, and sends the newly optimized
Nemo IR to execution runtime for the physical plan to be updated accordingly.
 
 ### Examples
 
@@ -52,4 +52,4 @@ and data flow model pass, that determines the fashion in which each computation
 
 Using different optimization policies for specific goals enables users to flexibly customize
and perform data processing for different deployment characteristics.
 This greatly simplifies the work by replacing the work of exploring and rewriting system
internals for modifying runtime behaviors with a simple process of using pluggable policies.
-It also makes it possible for the system to promptly meet new requirements through [easy
extension of system capabilities](../extending_Coral).
+It also makes it possible for the system to promptly meet new requirements through [easy
extension of system capabilities](../extending_Nemo).
diff --git a/_includes/topnav.html b/_includes/topnav.html
index 88875ea..98cd329 100644
--- a/_includes/topnav.html
+++ b/_includes/topnav.html
@@ -8,7 +8,7 @@
         <span class="icon-bar"></span>
       </button>
             <a class="navbar-brand" href="{{ site.baseurl }}/">
-                <span><img src="{{site.baseurl}}/img/coral.png"></span>
+                <span><img src="{{site.baseurl}}/img/nemo.png"></span>
             </a>
         </div>
         <div id="navbar" class="collapse navbar-collapse">
diff --git a/css/main.scss b/css/main.scss
index abcfa27..7c6d80d 100755
--- a/css/main.scss
+++ b/css/main.scss
@@ -43,10 +43,10 @@ body {
 .header-container {
   background-color: black;
   background: url('../img/bg.jpg') no-repeat 50% 0;
-  color: #fff;
+  color: #4B4B4B;
 
   h1 {
-    color: #fff;
+    color: #4B4B4B;
   }
   // background-attachment: fixed;
   background-size: cover;
diff --git a/favicon.ico b/favicon.ico
index c8f0c8e..e591e26 100644
Binary files a/favicon.ico and b/favicon.ico differ
diff --git a/img/bg.jpg b/img/bg.jpg
index 06b4f77..63ac207 100644
Binary files a/img/bg.jpg and b/img/bg.jpg differ
diff --git a/img/nemo.png b/img/nemo.png
new file mode 100644
index 0000000..0692951
Binary files /dev/null and b/img/nemo.png differ
diff --git a/index.html b/index.html
index 24699e9..3c51aea 100644
--- a/index.html
+++ b/index.html
@@ -4,7 +4,7 @@ layout: default
 
 <div class="header-container jumbotron">
     <div class="container">
-    <h1>Coral</h1>
+    <h1>Nemo</h1>
         <p>A Data Processing System for Flexible Employment With Different Deployment
Characteristics.</p>
         <p><a class="btn btn-primary btn-lg" href="{{ "/docs/home/" | prepend: site.baseurl
}}" role="button">Learn more</a></p>
     </div>
@@ -15,13 +15,13 @@ layout: default
 
     <div class="row">
         <div class="col-md-6">
-            <h2 class="header-light regular-pad">What is Coral?</h2>
+            <h2 class="header-light regular-pad">What is Nemo? <small>[ˈnemoʊ]</small></h2>
             <blockquote>
                 <p>
-                    Coral is a data processing system for flexible employment with different
execution scenarios for various deployment characteristics on clusters.
+                    Nemo is a data processing system for flexible employment with different
execution scenarios for various deployment characteristics on clusters.
                     They include processing data on specific resource environments, like
on transient resources, and running jobs with specific attributes, like skewed data.
-                    Coral decouples the logical notion of data processing applications from
runtime behaviors and express them on separate layers using Coral Intermediate Representation
(IR).
-                    Specifically, through a set of high-level graph pass interfaces, Coral
exposes runtime behaviors to be flexibly configured and modified at both compile-time and
runtime, and the Coral Runtime executes the Coral IR with its modular and extensible design.
+                    Nemo decouples the logical notion of data processing applications from
runtime behaviors and express them on separate layers using Nemo Intermediate Representation
(IR).
+                    Specifically, through a set of high-level graph pass interfaces, Nemo
exposes runtime behaviors to be flexibly configured and modified at both compile-time and
runtime, and the Nemo Runtime executes the Nemo IR with its modular and extensible design.
                 </p>
               <!--<p>Jekyll is a simple, blog-aware, static site generator. It takes
a template-->
               <!--directory containing raw text files in various formats, runs it through-->
@@ -35,8 +35,8 @@ layout: default
             </blockquote>
         </div>
         <div class="col-md-6 text-center">
-            <img src="img/coral.png" alt="" class="img-responsive">
-            <!--<img width="512" alt="Coral reef 98" src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/Coral_reef_98.jpg/512px-Coral_reef_98.jpg"/>-->
+            <img src="img/nemo.png" alt="" class="img-responsive">
+            <!--<img width="512" alt="Nemo reef 98" src="https://upload.wikimedia.org/wikipedia/commons/thumb/6/60/Nemo_reef_98.jpg/512px-Nemo_reef_98.jpg"/>-->
         </div>
     </div>
 
@@ -47,7 +47,7 @@ layout: default
             <h1 class="text-center"><i class="fa fa-pencil" aria-hidden="true"></i></h1>
             <h3 class="text-center">Flexible</h3>
             <p>
-                Coral offers flexible adaptation to your desired execution environment.
+                Nemo offers flexible adaptation to your desired execution environment.
                 Examples of such execution environments include using transient resources,
disaggregation of different computing resources, and handling skewed data.
             </p>
         </div>
@@ -55,7 +55,7 @@ layout: default
             <h1 class="text-center"><i class="fa fa-cogs" aria-hidden="true"></i></h1>
             <h3 class="text-center">Modular and Extensible</h3>
             <p>
-                Coral is designed to be modular and extensible for even more variety of execution
scenarios and deployment characteristics.
+                Nemo is designed to be modular and extensible for even more variety of execution
scenarios and deployment characteristics.
                 Users with specific needs can plug in and out the required components and
execute their jobs accordingly.
             </p>
         </div>
@@ -63,8 +63,8 @@ layout: default
             <h1 class="text-center"><i class="fa fa-arrows-alt" aria-hidden="true"></i></h1>
             <h3 class="text-center">Runs Everywhere</h3>
             <p>
-                Coral is able to run Apache Beam™ programs using our runtime, and Apache
Spark™ programs in the near future.
-                Moreover, by using Apache REEF™, Coral enables data processing possible
on different resource managers including Apache Hadoop™ YARN or Apache Mesos™.
+                Nemo is able to run Apache Beam™ programs using our runtime, and Apache
Spark™ programs in the near future.
+                Moreover, by using Apache REEF™, Nemo enables data processing possible
on different resource managers including Apache Hadoop™ YARN or Apache Mesos™.
             </p>
         </div>
     </div>

-- 
To stop receiving notification emails like this one, please contact
wonook@apache.org.

Mime
View raw message