DOCSEARCHbyAlgolia
Submit Docs

Timeloop Documentation

repository·master·Indexed 19 days ago

https://github.com/nvlabs/timeloop

A modeling and mapping infrastructure for analyzing the performance and energy efficiency of dense and sparse tensor algebra workloads on accelerator architectures. It features an Analytical Model for architecture emulation and a Mapper for finding optimal problem mappings. The project includes Orojenesis for computing data movement bounds and Tenssella for functional validation. Key versions include 2.0 (Sparseloop) for compressed-sparse tensor algebra and 3.0 (Ruby) for imperfectly-factorized and flattened mappings.

Tokens
22.2K
Snippets
63
Records
90
Agent score
60%

What's inside Timeloop

  1. Overview of Orojenesis

    master

    Orojenesis is a tool designed to compute compute data movement bounds for tensor algorithms. It analyzes how much data movement is required for a given tensor operation by understanding reuse patterns and the capacity of on-chip buffers.

    Key capabilities include:

    • Providing bounds on data movement that no dataflow or mapping can exceed under specific on-chip buffer capacity constraints.
    • Accounting for mappings that fuse sequences of tensor operations to exploit producer-consumer reuse.
    • Generating plots that illustrate the relationship between buffer size and the lower limit of data movement to/from the next level in a memory hierarchy.

  2. What is Timeloop

    master

    Timeloop is an infrastructure for modeling, mapping, and code-generation for dense and sparse tensor algebra workloads across various accelerator architectures. It consists of two primary modular components:

    1. Analytical Model: A fast model used to emulate architecture designs and provide performance and energy projections.
    2. Mapper: A component that searches for the optimal mapping of a tensor-algebra problem onto a specific architecture.

    Versions:

    • Version 2.0 (Sparseloop): Adds stochastic modeling for compressed-sparse tensor algebra.
    • Version 3.0 (Ruby): Adds support for imperfectly-factorized mappings, spatial skews, and flattened mappings.

  5. Conduct unit tests for compound-config

    master

    To run unit tests specifically for compound-config.cpp, you must manually prepare a test environment by organizing specific YAML configuration files from an external repository to match the expected directory structure used by the test suite.

    Setup Steps

    1. Download Test Data: Copy the files from the directories starting with 00, 01, and 02 from the timeloop-accelergy-exercises repository.
    2. Organize YAML Files: Move every YAML file one folder up. The final directory structure must match the paths defined in the FILES variable within test-compound-config.cpp.
    3. Compile Timeloop: Compile the Timeloop project using your standard build process to ensure the unit test library is available.
    4. Execute Tests: Run the unit test binary from the repository root.

    If the YAML files are placed in the correct locations relative to the test execution point, the compound-config.cpp unit tests will execute.

    $ ./bin/timeloop-unit-tests

  6. Build and run Tenssella

    master

    Tenssella is built using scons. Note that architecture, problem, and mapping specifications are currently hardcoded as C++ files included in main.cpp and cannot be passed via command-line arguments.

    To build:

    scons

    To run the compiled binary:

    ./tenssella
    scons
./tenssella

  7. Run the output code on a host emulator

    master

    After running Tenssella, you can build and run the generated emulator to validate functionality:

    1. Navigate to the out/ directory.
    2. Build the out.cpp file using scons.
    3. Execute the resulting ./emulator binary.
    cd out/
scons
./emulator

  10. Understand the Timeloop source organization

    master

    Timeloop is organized into several functional modules that work together to model and optimize hardware mappings for workloads. Understanding these modules is key to knowing where to find specific logic:

    • workload/: Defines data structures for workload shapes (e.g., CNN layers) and parsers to convert specific shapes into these structures.
    • mapspaces/: Manages the space of legal mappings for a given architecture and workload. Includes specialized classes for specific architectures and a generic Uber mapspace class.
    • mapping/: Defines specific tiling and scheduling patterns (mappings) and their nest structures.
    • loop-analysis/: Extracts numerical properties from mappings, such as operand volume sizes and data transfer requirements (reads/writes) between nesting levels.
    • model/: A generic analytical performance model that evaluates a mapping on a modeled architecture to produce statistics like cycle counts and access counts. It relies on loop-analysis.
    • pat/ (external): Provides technology parameters and interpolation for Energy and Area modeling.
    • search/: Contains routines for finding optimal mappings within a mapspace.
    • applications/: Contains specific implementations using the infrastructure. The core timeloop application is located in applications/mapper.hpp.
    • compound-config/: A wrapper class providing transparent support for both yaml and libconfig input formats.

  11. Handle termination signals in Mapper

    master

    The Mapper application implements a multi-stage signal handling mechanism for SIGINT (e.g., Ctrl+C) to ensure graceful or immediate shutdown:

    1. First Signal: The application catches the signal and sets gTerminate = true. Mapper threads will finish their current evaluations before terminating.
    2. Second Signal: The application sets gTerminateEval = true. Threads will abandon ongoing evaluations and terminate immediately.
    3. Third Signal: The application exits immediately (disgracefully).

  12. Tune search termination conditions

    master

    Use these knobs to determine when a search thread stops searching:

    • timeout: Number of consecutive invalid mappings before a thread self-terminates. Set to 0 to ignore invalid mappings for termination. Default is 1000.
    • victory_condition: Number of consecutive valid but suboptimal mappings (higher cost than the current best) before a thread declares victory and terminates. Set to 0 to ignore suboptimal mappings for termination. Default is 500.
    • search_size: Total number of valid mappings encountered before self-termination. Set to 0 to disable this criterion. Default is 0.
    • sync_interval: Number of mappings examined between thread synchronizations. Threads share their best mapping and cost with others at this interval. Default is 0 (threads operate independently until all terminate).