| 18 |
We are particularly interested in a class of algorithms that are programmed |
We are particularly interested in a class of algorithms that are programmed |
| 19 |
in terms of <em>continuous</em> scalar, vector, and tensor fields that |
in terms of <em>continuous</em> scalar, vector, and tensor fields that |
| 20 |
are reconstructed from the image data. |
are reconstructed from the image data. |
| 21 |
|
Our goals are to provide a high-level mathematical programming model for |
| 22 |
|
these algorithms, while also providing high-performance implementations |
| 23 |
|
on a variety of parallel hardware platforms. |
| 24 |
|
</p> |
| 25 |
|
|
| 26 |
|
<h3>Language overview</h3> |
| 27 |
|
<p> |
| 28 |
|
The following is an overview of our current preliminary design for Diderot. |
| 29 |
|
We are building a compiler for this design and expect that the design will |
| 30 |
|
evolve as we get experience with the implementation. |
| 31 |
|
Also, the design is conservative, in that it does not provide all of the features that |
| 32 |
|
we plan to provide (<i>e.g.</i>, actor-actor interactions). |
| 33 |
|
</p> |
| 34 |
|
|
| 35 |
|
<h4>Types</h4> |
| 36 |
|
<p> |
| 37 |
|
The main type of computational value in Diderot is a <em>tensor</em>, which includes |
| 38 |
|
reals (0-order tensors), vectors, and matrices. |
| 39 |
|
In addition, Diderot provides booleans, integers, and strings. |
| 40 |
|
Diderot also has three <em>abstract</em> types: |
| 41 |
|
</p> |
| 42 |
|
<dl> |
| 43 |
|
<dt>images</dt> |
| 44 |
|
<dd>are used to represent the data being analyzed, as well as other array data, such as transfer |
| 45 |
|
functions. |
| 46 |
|
</dd> |
| 47 |
|
<dt>kernels</dt> |
| 48 |
|
<dd>are separable convolution kernels</dd> |
| 49 |
|
<dt>fields</dt> |
| 50 |
|
<dd>are an abstraction of functions from 1D, 2D, or 3D space to some tensor type. |
| 51 |
|
A field is defined by convolving an image with a kernel. |
| 52 |
|
</dd> |
| 53 |
|
</dl> |
| 54 |
|
|
| 55 |
|
<h4>Program structure</h4> |
| 56 |
|
<p>A Diderot program is organized into three logical sections:</p> |
| 57 |
|
<ol> |
| 58 |
|
<li>Global declarations define global values, such as fields, as well as the inputs to the program.</li> |
| 59 |
|
<li>Actor definitions define the computational agents that implement the program</li> |
| 60 |
|
<li>Initialization defines the initial set of actors and their structure</li> |
| 61 |
|
</ol> |
| 62 |
|
|
| 63 |
|
<h4>Actors</h4> |
| 64 |
|
<p> |
| 65 |
|
An <em>actor</em> represents a mostly autonomous computation with local state, which includes |
| 66 |
|
their <em>position</em> in world space. |
| 67 |
|
An actor definition consists of declared state variables and methods. |
| 68 |
|
All actors must have an <em>update</em> method and may optionally have a <em>stabilize</em> |
| 69 |
|
method. |
| 70 |
|
</p> |
| 71 |
|
|
| 72 |
|
<h4>Execution model</h4> |
| 73 |
|
<p>The Diderot execution model is <em>bulk synchronous</em>. |
| 74 |
|
At each iteration, the update methods of all active actors are invoked, resulting in a new |
| 75 |
|
configuration. |
| 76 |
</p> |
</p> |
| 77 |
|
|
| 78 |
<h3>People</h3> |
<h3>People</h3> |
| 90 |
</p> |
</p> |
| 91 |
|
|
| 92 |
<hr /> |
<hr /> |
| 93 |
Last modified: September 30, 2010. |
Last modified: October 4, 2010. |
| 94 |
<hr /> |
<hr /> |
| 95 |
|
|
| 96 |
</body> |
</body> |
Parent Directory
| 
Revision Log
| 
Patch
