diff --git a/.github/workflows/fpga-ci.yml b/.github/workflows/fpga-ci.yml index d03d044b30..29be0ec1f1 100644 --- a/.github/workflows/fpga-ci.yml +++ b/.github/workflows/fpga-ci.yml @@ -2,11 +2,11 @@ name: FPGA Tests on: push: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] pull_request: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] merge_group: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] jobs: test-fpga: diff --git a/.github/workflows/general-ci.yml b/.github/workflows/general-ci.yml index f7b44e6978..2dcffc6484 100644 --- a/.github/workflows/general-ci.yml +++ b/.github/workflows/general-ci.yml @@ -2,11 +2,11 @@ name: General Tests on: push: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] pull_request: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] merge_group: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] jobs: test: diff --git a/.github/workflows/gpu-ci.yml b/.github/workflows/gpu-ci.yml index ce7f9b628e..2a1ccb43ef 100644 --- a/.github/workflows/gpu-ci.yml +++ b/.github/workflows/gpu-ci.yml @@ -2,11 +2,11 @@ name: GPU Tests on: push: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] pull_request: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] merge_group: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] env: CUDACXX: /usr/local/cuda/bin/nvcc diff --git a/.github/workflows/heterogeneous-ci.yml b/.github/workflows/heterogeneous-ci.yml index 7c65e90718..5f7dbff77e 100644 --- a/.github/workflows/heterogeneous-ci.yml +++ b/.github/workflows/heterogeneous-ci.yml @@ -2,11 +2,11 @@ name: Heterogeneous Tests on: push: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] pull_request: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] merge_group: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] env: CUDA_HOME: /usr/local/cuda diff --git a/.github/workflows/pyFV3-ci.yml b/.github/workflows/pyFV3-ci.yml index 2b98327381..f58fdf85ac 100644 --- a/.github/workflows/pyFV3-ci.yml +++ b/.github/workflows/pyFV3-ci.yml @@ -2,11 +2,11 @@ name: NASA/NOAA pyFV3 repository build test on: push: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] pull_request: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] merge_group: - branches: [ master, ci-fix ] + branches: [ main, ci-fix ] defaults: run: diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6bf69495b1..313b3f0f21 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -47,7 +47,7 @@ For automatic styling, we use the [yapf](https://github.com/google/yapf) file fo We use [pytest](https://www.pytest.org/) for our testing infrastructure. All tests under the `tests/` folder (and any subfolders within) are automatically read and run. The files must be under the right subfolder based on the component being tested (e.g., `tests/sdfg/` for IR-related tests), and must have the right -suffix: either `*_test.py` or `*_cudatest.py`. See [pytest.ini](https://github.com/spcl/dace/blob/master/pytest.ini) +suffix: either `*_test.py` or `*_cudatest.py`. See [pytest.ini](https://github.com/spcl/dace/blob/main/pytest.ini) for more information, and for the markers we use to specify software/hardware requirements. The structure of the test file must follow `pytest` standards (i.e., free functions called `test_*`), and diff --git a/README.md b/README.md index 41b059c953..ef4bdec1db 100644 --- a/README.md +++ b/README.md @@ -3,7 +3,7 @@ [![FPGA Tests](https://github.com/spcl/dace/actions/workflows/fpga-ci.yml/badge.svg)](https://github.com/spcl/dace/actions/workflows/fpga-ci.yml) [![Documentation Status](https://readthedocs.org/projects/spcldace/badge/?version=latest)](https://spcldace.readthedocs.io/en/latest/?badge=latest) [![PyPI version](https://badge.fury.io/py/dace.svg)](https://badge.fury.io/py/dace) -[![codecov](https://codecov.io/gh/spcl/dace/branch/master/graph/badge.svg)](https://codecov.io/gh/spcl/dace) +[![codecov](https://codecov.io/gh/spcl/dace/branch/main/graph/badge.svg)](https://codecov.io/gh/spcl/dace) ![D](dace.svg)aCe - Data-Centric Parallel Programming @@ -11,7 +11,7 @@ _Decoupling domain science from performance optimization._ -DaCe is a [fast](https://nbviewer.org/github/spcl/dace/blob/master/tutorials/benchmarking.ipynb) parallel programming +DaCe is a [fast](https://nbviewer.org/github/spcl/dace/blob/main/tutorials/benchmarking.ipynb) parallel programming framework that takes code in Python/NumPy and other programming languages, and maps it to high-performance **CPU, GPU, and FPGA** programs, which can be optimized to achieve state-of-the-art. Internally, DaCe uses the Stateful DataFlow multiGraph (SDFG) *data-centric intermediate @@ -61,13 +61,13 @@ be used in any C ABI compatible language (C/C++, FORTRAN, etc.). For more information on how to use DaCe, see the [samples](samples) or tutorials below: -* [Getting Started](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/getting_started.ipynb) -* [Benchmarks, Instrumentation, and Performance Comparison with Other Python Compilers](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/benchmarking.ipynb) -* [Explicit Dataflow in Python](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/explicit.ipynb) -* [NumPy API Reference](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/numpy_frontend.ipynb) -* [SDFG API](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/sdfg_api.ipynb) -* [Using and Creating Transformations](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/transformations.ipynb) -* [Extending the Code Generator](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/codegen.ipynb) +* [Getting Started](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/getting_started.ipynb) +* [Benchmarks, Instrumentation, and Performance Comparison with Other Python Compilers](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/benchmarking.ipynb) +* [Explicit Dataflow in Python](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/explicit.ipynb) +* [NumPy API Reference](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/numpy_frontend.ipynb) +* [SDFG API](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/sdfg_api.ipynb) +* [Using and Creating Transformations](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/transformations.ipynb) +* [Extending the Code Generator](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/codegen.ipynb) Publication ----------- diff --git a/dace/frontend/python/README.md b/dace/frontend/python/README.md index bd57e36519..aa176f687c 100644 --- a/dace/frontend/python/README.md +++ b/dace/frontend/python/README.md @@ -4,7 +4,7 @@ The Python-Frontend aims to assist users in creating SDFGs from Python code relatively quickly. You may read a list of supported Python features [here](python_supported_features.md). The frontend supports also operations among DaCe arrays, in a manner similar to NumPy. A short tutorial can be bound -[here](https://nbviewer.jupyter.org/github/spcl/dace/blob/master/tutorials/numpy_frontend.ipynb). +[here](https://nbviewer.jupyter.org/github/spcl/dace/blob/main/tutorials/numpy_frontend.ipynb). Please note that the Python-Frontend is still in an early version. For any issues and feature requests, you can create an issue in the main DaCe project. You can also address any questions you have to alziogas@inf.ethz.ch diff --git a/doc/codegen/codegen.rst b/doc/codegen/codegen.rst index a000022ee6..f3058c1440 100644 --- a/doc/codegen/codegen.rst +++ b/doc/codegen/codegen.rst @@ -32,8 +32,8 @@ There are many features that are enabled by generating code from SDFGs: .. note:: - You can also extend the code generator with new backends externally, see the `Customizing Code Generation tutorial `_ - and the `Tensor Core sample `_ for more information. + You can also extend the code generator with new backends externally, see the `Customizing Code Generation tutorial `_ + and the `Tensor Core sample `_ for more information. After the code is generated, ``compiler.py`` will invoke CMake on the build folder (e.g., ``.dacecache//build``) @@ -145,7 +145,7 @@ necessary headers. The runtime is used for: match Python interfaces. This is especially useful to generate matching code when calling functions such as ``range`` inside Tasklets. -The folder also contains other files and helper functions, refer to its contents `on GitHub `_ +The folder also contains other files and helper functions, refer to its contents `on GitHub `_ for more information. diff --git a/doc/extensions/extensions.rst b/doc/extensions/extensions.rst index 4644bef109..3f73a924bc 100644 --- a/doc/extensions/extensions.rst +++ b/doc/extensions/extensions.rst @@ -17,10 +17,10 @@ The three key mechanisms of extensibility are class inheritance, :ref:`replaceme For more examples of how to extend DaCe, see the following resources: - * Library nodes: `Einsum specialization library node `_ - * Transformations: `Using and Creating Transformations `_ - * Code generators: `Extending the Code Generator `_ - * Frontend extensions (enumerations and replacements): `Tensor Core code sample `_ + * Library nodes: `Einsum specialization library node `_ + * Transformations: `Using and Creating Transformations `_ + * Code generators: `Extending the Code Generator `_ + * Frontend extensions (enumerations and replacements): `Tensor Core code sample `_ .. .. toctree .. :maxdepth: 1 diff --git a/doc/frontend/daceprograms.rst b/doc/frontend/daceprograms.rst index c21ac34722..4229fe422d 100644 --- a/doc/frontend/daceprograms.rst +++ b/doc/frontend/daceprograms.rst @@ -9,7 +9,7 @@ This includes standard Python code (loops, functions, context managers, etc.), b and (most) functions. .. note:: - For more examples, see the `Getting Started `_ + For more examples, see the `Getting Started `_ Jupyter Notebook tutorial. Usage @@ -349,7 +349,7 @@ Explicit Dataflow Mode The DaCe Python frontend allows users to write SDFG tasklets and memlets directly in Python code. -For more example uses, see the `Explicit Dataflow `_ +For more example uses, see the `Explicit Dataflow `_ tutorial. Memlets diff --git a/doc/ide/cli.rst b/doc/ide/cli.rst index d73d32fdfc..1f63397841 100644 --- a/doc/ide/cli.rst +++ b/doc/ide/cli.rst @@ -123,4 +123,4 @@ nothing is given, the tool will time the entire execution of each program using +---------------------------+--------------+-----------------------------------------------------------+ For a more detailed guide on how to profile SDFGs and work with the resulting data, see :ref:`profiling` and -`this tutorial `_. +`this tutorial `_. diff --git a/doc/optimization/gpu.rst b/doc/optimization/gpu.rst index a08877de3b..f94d377b51 100644 --- a/doc/optimization/gpu.rst +++ b/doc/optimization/gpu.rst @@ -170,7 +170,7 @@ Optimizing GPU SDFGs When optimizing GPU SDFGs, there are a few things to keep in mind. Below is a non-exhaustive list of common GPU optimization practices and how DaCe helps achieve them. To see some of these optimizations in action, check out the ``optimize_for_gpu`` -function in the `Matrix Multiplication optimization example `_. +function in the `Matrix Multiplication optimization example `_. * **Minimize host<->GPU transfers**: It is important to keep as much data as possible on the GPU across the application. This is especially true for data that is accessed frequently, such as data that is used in a loop. @@ -234,7 +234,7 @@ function in the `Matrix Multiplication optimization example `_ + in your code. See the `Tensor Core code sample `_ to see how to make use of such units. * **Advanced GPU Map schedules**: DaCe provides two additional built-in map schedules: :class:`~dace.dtypes.ScheduleType.GPU_ThreadBlock_Dynamic` diff --git a/doc/optimization/optimization.rst b/doc/optimization/optimization.rst index f1eb84005b..592ab5e6fc 100644 --- a/doc/optimization/optimization.rst +++ b/doc/optimization/optimization.rst @@ -36,9 +36,9 @@ tunes the data layout of arrays. The following resources are available to help you optimize your SDFG: - * Using transformations: `Using and Creating Transformations `_ - * Creating optimized schedules that can match optimized libraries: `Matrix multiplication CPU and GPU optimization example `_ - * Auto-tuning and instrumentation: `Tuning data layouts sample `_ + * Using transformations: `Using and Creating Transformations `_ + * Creating optimized schedules that can match optimized libraries: `Matrix multiplication CPU and GPU optimization example `_ + * Auto-tuning and instrumentation: `Tuning data layouts sample `_ The following subsections provide more information on the different types of optimization methods: diff --git a/doc/optimization/profiling.rst b/doc/optimization/profiling.rst index 497dc81ae8..617b3a9cb9 100644 --- a/doc/optimization/profiling.rst +++ b/doc/optimization/profiling.rst @@ -5,7 +5,7 @@ Profiling and Instrumentation .. note:: - For more information and examples, see the `Benchmarking and Instrumentation `_ tutorial. + For more information and examples, see the `Benchmarking and Instrumentation `_ tutorial. Simple profiling ---------------- @@ -120,7 +120,7 @@ There are more instrumentation types available, such as fine-grained GPU kernel Instrumentation can also collect performance counters on CPUs and GPUs using `LIKWID `_. The :class:`~dace.dtypes.InstrumentationType.LIKWID_Counters` instrumentation type can be configured to collect a wide variety of performance counters on CPUs and GPUs. An example use can be found in the -`LIKWID instrumentation code sample `_. +`LIKWID instrumentation code sample `_. Instrumentation file format diff --git a/doc/optimization/vscode.rst b/doc/optimization/vscode.rst index 1b72effbcc..07f7797b4e 100644 --- a/doc/optimization/vscode.rst +++ b/doc/optimization/vscode.rst @@ -145,5 +145,5 @@ transformations |add-xform-by-folder-btn|. The latter recursively traverses the for any Python source code files and attempts to load each one as a transformation. For more information on how to use and author data-centric transformations, -see :ref:`transforming` and the `Using and Creating Transformations `_ +see :ref:`transforming` and the `Using and Creating Transformations `_ tutorial. diff --git a/doc/sdfg/ir.rst b/doc/sdfg/ir.rst index 61dc8d4858..1a7a8368cb 100644 --- a/doc/sdfg/ir.rst +++ b/doc/sdfg/ir.rst @@ -627,7 +627,7 @@ override default implementations for a library node type, or for an entire libra Internally, an expansion is a subclass of :class:`~dace.transformation.transformation.ExpandTransformation`. It is responsible for creating a new SDFG that implements the library node, and for connecting the inputs and outputs of the library node to the new SDFG. An example of such an expansion is Einstein summation specialization -(`see full file `_): +(`see full file `_): .. code-block:: python diff --git a/doc/sdfg/transformations.rst b/doc/sdfg/transformations.rst index 0a9791ca66..470d413271 100644 --- a/doc/sdfg/transformations.rst +++ b/doc/sdfg/transformations.rst @@ -23,7 +23,7 @@ All transformations extend the :class:`~dace.transformation.transformation.Trans Transformations can have properties and those can be used when applying them: for example, tile sizes in :class:`~dace.transformation.dataflow.tiling.MapTiling`. -For more information on how to use and author data-centric transformations, see the `Using and Creating Transformations `_ +For more information on how to use and author data-centric transformations, see the `Using and Creating Transformations `_ tutorial. diff --git a/doc/setup/integration.rst b/doc/setup/integration.rst index 3e1fc5fa70..78607feda9 100644 --- a/doc/setup/integration.rst +++ b/doc/setup/integration.rst @@ -79,7 +79,7 @@ you to call the SDFG's entry point function, perform basic type checking, and ar Python callback to function pointer, etc.). Since the compiled SDFG is a low-level interface, it is much faster to call than the Python interface. -`We show this behavior in the Benchmarking tutorial `_. +`We show this behavior in the Benchmarking tutorial `_. However, it requires caution as opposed to calling the ``@dace.program`` or the ``SDFG`` object because: * Each array return value is represented internally as a single array (not reallocated every call) and will be diff --git a/doc/setup/quickstart.rst b/doc/setup/quickstart.rst index 4a54de720c..70f24cbfb1 100644 --- a/doc/setup/quickstart.rst +++ b/doc/setup/quickstart.rst @@ -36,5 +36,5 @@ From here on out, you can optimize (:ref:`interactively `, :ref:`program your code. -For more examples of how to use DaCe, see the `samples `_ and -`tutorials `_ folders on GitHub. +For more examples of how to use DaCe, see the `samples `_ and +`tutorials `_ folders on GitHub. diff --git a/tutorials/benchmarking.ipynb b/tutorials/benchmarking.ipynb index f2330957a3..59302e8090 100644 --- a/tutorials/benchmarking.ipynb +++ b/tutorials/benchmarking.ipynb @@ -1260,7 +1260,7 @@ "source": [ "### Instrumentation API\n", "\n", - "The Instrumentation API allows more fine-grained control over measuring program metrics. It creates a JSON report in `.dacecache//perf`, which can be obtained with the API or viewed with any Chrome Tracing capable viewer. More usage information and how to use the API to tune programs can be found in the [program tuning sample](https://github.com/spcl/dace/blob/master/samples/optimization/tuning.py)." + "The Instrumentation API allows more fine-grained control over measuring program metrics. It creates a JSON report in `.dacecache//perf`, which can be obtained with the API or viewed with any Chrome Tracing capable viewer. More usage information and how to use the API to tune programs can be found in the [program tuning sample](https://github.com/spcl/dace/blob/main/samples/optimization/tuning.py)." ] }, {