Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • N NIFTy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 22
    • Issues 22
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 16
    • Merge requests 16
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

On Monday, June 12, 2023, from 9.00 to 10.00 am there will be a maintenance with a short downtime of the GitLab service.

  • ift
  • NIFTy
  • Merge requests
  • !434

Operator tree optimiser

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Rouven Lemmerz requested to merge operator_tree_optimiser into NIFTy_6 Mar 27, 2020
  • Overview 35
  • Commits 11
  • Pipelines 11
  • Changes 3

In order to prevent operators from calculating the same fields multiple times, one can set variables and input these into the operator tree. The variables are set via a FieldAdapter. This has been used in !417 (merged).

An operator tree takes as an input a Field and outputs a Field. Cutting out equal subtrees and using their output as the new input for the pruned operator tree is one way to achieve more performance. This is done by optimize_subtrees.

There are some more improvements one has to make: _OpChain operators make the tree very complex and they have to be unpacked. In op2(op1) + op1 the first Summand has to be checked for whether it contains parts of the second Summand. optimize_node does this, while optimize_all_nodes traverses the tree and applies it to (usually, see Problem 1) every node.

Some Problems:

  1. Currently only searching for nodes at the end of operator chains, but optimize_all_nodes( (op + op)(op + op) ) can happen

  2. Subtrees are only replaced at node points, but one should also compare the vertices above and replace it

  3. Only comparing by ids is done, one might add a cache to prevent same operators from going unnoticed (similar to the DomainTuple cache

  4. op = optimize_subtrees(optimize_all_nodes(op)) generates better results than op = optimize_all_nodes(optimize_subtrees(op)).

As of now I'm unsure in how far changing the way the operator trees are stored could be improved to make this optimisation easier and/or faster.

@mtr @gedenhof

Edited May 19, 2020 by Martin Reinecke
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: operator_tree_optimiser