New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

init test branch #3244

Draft

pianpwk wants to merge 2 commits into main from pianpwk/test_datadep_pr

+182 −0

Contributor

pianpwk commented Jan 22, 2025 •

edited by pytorch-bot bot

Loading

Fixes #ISSUE_NUMBER

Description

Checklist

The issue that is being fixed is referred in the description (see above "Fixes #ISSUE_NUMBER")
Only one issue is addressed in this pull request
Labels from the issue that this PR is fixing are added to this pull request
No unnecessary issues are included into this pull request.

cc @williamwen42 @msaroufim @anijain2305


          init test branch

9ff6d89

pytorch-bot bot commented Jan 22, 2025 •

edited

Loading

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/tutorials/3244

📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure

As of commit d6a992b with merge base df9e226 ():

NEW FAILURE - The following job has failed:

Check spelling / pyspelling (gh)
Process completed with exit code 1.

This comment was automatically generated by Dr. CI and updates every 15 minutes.

facebook-github-bot added the cla signed label


          Merge branch 'main' of https://github.com/pytorch/tutorials into pian…

d6a992b

…pwk/test_datadep_pr

svekars reviewed

View reviewed changes

Contributor

svekars left a comment

a couple of editorial nits.

intermediate_source/torch_export_tutorial.py

    
              # While trying to export models, you have may have encountered errors like ``Could not guard on data-dependent expression`` or ``Could not extract specialized integer from data-dependent expression``.

              # Obscure as they may seem, the reasoning behind their existence, and their resolution, is actually quite straightforward.

              #

              # These errors exist because ``torch.export()`` compiles programs using ``FakeTensors``, which symbolically represent their real tensor counterparts (e.g. they may have the same or equivalent symbolic properties

Contributor

svekars Jan 22, 2025

Suggested change

      
            # These errors exist because ``torch.export()`` compiles programs using ``FakeTensors``, which symbolically represent their real tensor counterparts (e.g. they may have the same or equivalent symbolic properties
          
            # These errors exist because ``torch.export()`` compiles programs using ``FakeTensors``, which symbolically represent their real tensor counterparts (for example, they may have the same or equivalent symbolic properties

intermediate_source/torch_export_tutorial.py

    
              # Obscure as they may seem, the reasoning behind their existence, and their resolution, is actually quite straightforward.

              #

              # These errors exist because ``torch.export()`` compiles programs using ``FakeTensors``, which symbolically represent their real tensor counterparts (e.g. they may have the same or equivalent symbolic properties

              # - sizes, strides, dtypes, etc.), but diverge in one major respect: they do not contain any data values. While this avoids unnecessary memory usage and expensive computation, it does mean that the compiler may

Contributor

svekars Jan 22, 2025

Suggested change

      
            # - sizes, strides, dtypes, etc.), but diverge in one major respect: they do not contain any data values. While this avoids unnecessary memory usage and expensive computation, it does mean that the compiler may
          
            # - sizes, strides, dtypes, and so on), but diverge in one major respect: they do not contain any data values. While this avoids unnecessary memory usage and expensive computation, it does mean that the compiler may

intermediate_source/torch_export_tutorial.py

    
              # we allocate symbols for every data-dependent value that appears in the program. The important distinction is that these are "unbacked" symbols or "unbacked SymInts", in contrast to the "backed" symbols/SymInts

              # allocated for input dimensions. The "backed/unbacked" nomenclature refers to the presence, or absence, of a "hint" for the symbol: a concrete value backing the symbol, that can inform the compiler how to proceed.

              #

              # For dynamic input shapes (backed SymInts), these hints are taken from the shapes of the sample inputs provided, which explains why sample input shapes direct the compiler in control-flow branching.

Contributor

svekars Jan 22, 2025

Suggested change

      
            # For dynamic input shapes (backed SymInts), these hints are taken from the shapes of the sample inputs provided, which explains why sample input shapes direct the compiler in control-flow branching.
          
            # For dynamic input shapes (backed ``SymInts``), these hints are taken from the shapes of the sample inputs provided, which explains why sample input shapes direct the compiler in control-flow branching.

intermediate_source/torch_export_tutorial.py

    
              #

              # Let's talk about where data-dependent values appear in programs. Common sources are calls like ``item()``, ``tolist()``, or ``torch.unbind()`` that extract scalar values from tensors.

              # How are these values represented in the exported program? In the ``Constraints/Dynamic Shapes`` section, we talked about allocating symbols to represent dynamic input dimensions, and the same happens here -

              # we allocate symbols for every data-dependent value that appears in the program. The important distinction is that these are "unbacked" symbols or "unbacked SymInts", in contrast to the "backed" symbols/SymInts

Contributor

svekars Jan 22, 2025

Suggested change

      
            # we allocate symbols for every data-dependent value that appears in the program. The important distinction is that these are "unbacked" symbols or "unbacked SymInts", in contrast to the "backed" symbols/SymInts
          
            # we allocate symbols for every data-dependent value that appears in the program. The important distinction is that these are "unbacked" symbols or "unbacked" ``SymInts``, in contrast to the "backed" symbols/``SymInts``

intermediate_source/torch_export_tutorial.py

    
              # allocated for input dimensions. The "backed/unbacked" nomenclature refers to the presence, or absence, of a "hint" for the symbol: a concrete value backing the symbol, that can inform the compiler how to proceed.

              #

              # For dynamic input shapes (backed SymInts), these hints are taken from the shapes of the sample inputs provided, which explains why sample input shapes direct the compiler in control-flow branching.

              # On the other hand, data-dependent values are derived from FakeTensors during tracing, and by default lack hints to inform the compiler, hence the name "unbacked symbols/SymInts".

Contributor

svekars Jan 22, 2025

Suggested change

      
            # On the other hand, data-dependent values are derived from FakeTensors during tracing, and by default lack hints to inform the compiler, hence the name "unbacked symbols/SymInts".
          
            # On the other hand, data-dependent values are derived from ``FakeTensors`` during tracing, and by default lack hints to inform the compiler, hence the name "unbacked symbols" or ``SymInts``.

svekars added the torch.compile label

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

cla signed torch.compile