Cinder is Instagram's internal performance-oriented production version of CPython

Overview

Welcome to Cinder!

Cinder is Instagram's internal performance-oriented production version of CPython 3.8. It contains a number of performance optimizations, including bytecode inline caching, eager evaluation of coroutines, a method-at-a-time JIT, and an experimental bytecode compiler that uses type annotations to emit type-specialized bytecode that performs better in the JIT.

For more information on CPython, see README.cpython.rst.

Is this supported?

Short answer: no.

We've made Cinder publicly available in order to facilitate conversation about potentially upstreaming some of this work to CPython and to reduce duplication of effort among people working on CPython performance.

Cinder is not polished or documented for anyone else's use. We don't have the capacity to support Cinder as an independent open-source project, nor any desire for it to become an alternative to CPython. Our goal in making this code available is a unified faster CPython. So while we do run Cinder in production, if you choose to do so you are on your own. We can't commit to fixing external bug reports or reviewing pull requests. We make sure Cinder is sufficiently stable and fast for our production workload, but we make no assurances about its stability or correctness or performance for any other workload or use.

That said, if you have experience in dynamic language runtimes and have ideas to make Cinder faster; or if you work on CPython and want to use Cinder as inspiration for improvements in CPython (or help upstream parts of Cinder to CPython), please reach out; we'd love to chat!

How do I build it?

Cinder should build just like CPython; configure and make -j. However as most development and usage of Cinder occurs in the highly specific context of Instagram we do not exercise it much in other environments. As such, the most reliable way to build and run Cinder is to re-use the Docker-based setup from our GitHub CI workflow. A rough guide is as follows:

  1. Install and setup Docker.
  2. Clone the Cinder repo:
    git clone https://github.com/facebookincubator/cinder
  3. Run a shell in the Docker environment used by the CI:
    docker run -v "$PWD/cinder:/vol" -w /vol -ti ghcr.io/facebookincubator/cinder/python-build-env:latest bash
    The above command does the following:
    • Downloads (if not already cached) a pre-built Docker image used by the CI from https://ghcr.io/facebookincubator/cinder/python-build-env.
    • Makes the Cinder checkout above ($PWD/cinder) available to the Docker environment at the mount point /vol.
    • Interactively (-ti) runs bash in the /vol directory.
  4. Build Cinder from the shell started the Docker environment:
    ./configure && make

Please be aware that Cinder is only built or tested on Linux x64; anything else (including macOS) probably won't work. The Docker image above is Fedora Linux-based and built from a Docker spec file in the Cinder repo: .github/workflows/python-build-env/Dockerfile.

There are some new test targets that might be interesting. make testcinder is pretty much the same as make test except that it skips a few tests that are problematic in our dev environment. make testcinder_jit runs the test suite with the JIT fully enabled, so all functions are JIT'ed. make testruntime runs a suite of C++ gtest unit tests for the JIT. And make test_strict_module runs a test suite for strict modules (see below).

What's here?

Shadowcode

"Shadowcode" or "shadow bytecode" is our inline caching implementation. It observes particular optimizable cases in the execution of generic Python opcodes and (for hot functions) dynamically replaces those opcodes with specialized versions. The core of shadowcode lives in Python/shadowcode.c, though the implementations for the specialized bytecodes are in Python/ceval.c with the rest of the eval loop. Shadowcode-specific tests are in Lib/test/test_shadowcode.py.

Eager coroutine evaluation

If a call to an async function is immediately awaited, we immediately execute the called function up to its first await. If the called function reaches a return without needing to await, we will be able to return that value directly without ever even creating a coroutine object or deferring to the event loop. This is a significant (~5%) CPU optimization in our async-heavy workload.

This is mostly implemented in Python/ceval.c, via a new vectorcall flag _Py_AWAITED_CALL_MARKER, indicating the caller is immediately awaiting this call. Look for uses of the IS_AWAITED() macro and this vectorcall flag, as well as the _PyEval_EvalEagerCoro function.

The Cinder JIT

The Cinder JIT is a method-at-a-time custom JIT implemented in C++. It is enabled via the -X jit flag or the PYTHONJIT=1 environment variable. It supports almost all Python opcodes, and can achieve 1.5-4x speed improvements on many Python performance benchmarks.

By default when enabled it will JIT-compile every function that is ever called, which may well make your program slower, not faster, due to overhead of JIT-compiling rarely-called functions. The option -X jit-list-file=/path/to/jitlist.txt or PYTHONJITLISTFILE=/path/to/jitlist.txt can point it to a text file containing fully qualified function names (in the form path.to.module:funcname or path.to.module:ClassName.method_name), one per line, which should be JIT-compiled. We use this option to compile only a set of hot functions derived from production profiling data. (A more typical approach for a JIT would be to dynamically compile functions as they are observed to be called frequently. It hasn't yet been worth it for us to implement this, since our production architecture is a pre-fork webserver, and for memory sharing reasons we wish to do all of our JIT compiling up front in the initial process before workers are forked, which means we can't observe the workload in-process before deciding which functions to JIT-compile.)

The JIT lives in the Jit/ directory, and its C++ tests live in RuntimeTests/ (run these with make testruntime). There are also some Python tests for it in Lib/test/test_cinderjit.py; these aren't meant to be exhaustive, since we run the entire CPython test suite under the JIT via make testcinder_jit; they cover JIT edge cases not otherwise found in the CPython test suite.

See Jit/pyjit.cpp for some other -X options and environment variables that influence the behavior of the JIT. There is also a cinderjit module defined in that file which exposes some JIT utilities to Python code (e.g. forcing a specific function to compile, checking if a function is compiled, disabling the JIT). Note that cinderjit.disable() only disables future compilation; it immediately compiles all known functions and keeps existing JIT-compiled functions.

The JIT first lowers Python bytecode to a high-level intermediate representation (HIR); this is implemented in Jit/hir/. HIR maps reasonably closely to Python bytecode, though it is a register machine instead of a stack machine, it is a bit lower level, it is typed, and some details that are obscured by Python bytecode but important for performance (notably reference counting) are exposed explicitly in HIR. HIR is transformed into SSA form, some optimization passes are performed on it, and then reference counting operations are automatically inserted into it according to metadata about the refcount and memory effects of HIR opcodes.

HIR is then lowered to a low-level intermediate representation (LIR), which is an abstraction over assembly, implemented in Jit/lir/. In LIR we do register allocation, some additional optimization passes, and then finally LIR is lowered to assembly (in Jit/codegen/) using the excellent asmjit library.

The JIT is in its early stages. While it can already eliminate interpreter loop overhead and offers significant performance improvements for many functions, we've only begun to scratch the surface of possible optimizations. Many common compiler optimizations are not yet implemented. Our prioritization of optimizations is largely driven by the characteristics of the Instagram production workload.

Strict Modules

Strict modules is a few things rolled into one:

1. A static analyzer capable of validating that executing a module's top-level code will not have side effects visible outside that module.

2. An immutable StrictModule type usable in place of Python's default module type.

3. A Python module loader capable of recognizing modules opted in to strict mode (via an import __strict__ at the top of the module), analyzing them to validate no import side effects, and populating them in sys.modules as a StrictModule object.

The version of strict modules that we currently use in production is written in Python and is not part of Cinder. The StrictModules/ directory in Cinder is an in-progress C++ rewrite of the import side effects analyzer.

Static Python

Static Python is an experimental bytecode compiler that makes use of type annotations to emit type-specialized and type-checked Python bytecode. Used along with the Cinder JIT, it can deliver performance similar to MyPyC or Cython in many cases, while offering a pure-Python developer experience (normal Python syntax, no extra compilation step). Static Python plus Cinder JIT achieves 7x the performance of stock CPython on a typed version of the Richards benchmark. At Instagram we have successfully used Static Python in production to replace the majority of the Cython modules in our primary webserver codebase, with no performance regression.

The Static Python compiler is built on top of the Python compiler module that was removed from the standard library in Python 3 and has since been maintained and updated externally; this compiler is incorporated into Cinder in Lib/compiler. The Static Python compiler is implemented in Lib/compiler/static.py, and its tests are in Lib/test/test_compiler/test_static.py.

Classes defined in Static Python modules are automatically given typed slots (based on inspection of their typed class attributes and annotated assignments in __init__), and attribute loads and stores against instances of these types use new STORE_FIELD and LOAD_FIELD opcodes, which in the JIT become direct loads/stores from/to a fixed memory offset in the object, with none of the indirection of a LOAD_ATTR or STORE_ATTR. Classes also gain vtables of their methods, for use by the INVOKE_* opcodes mentioned below. The runtime support for these features is located in Include/classloader.h and Python/classloader.c.

A static Python function begins with a new CHECK_ARGS opcode which checks that the supplied arguments' types match the type annotations, and raises TypeError if not. Calls from a static Python function to another static Python function will skip this opcode (since the types are already validated by the compiler). Static to static calls can also avoid much of the overhead of a typical Python function call. We emit an INVOKE_FUNCTION or INVOKE_METHOD opcode which carries with it metadata about the called function or method; this plus optionally immutable modules (via StrictModule) and types (via cinder.freeze_type(), which we currently apply to all types in strict and static modules in our import loader, but in future may become an inherent part of Static Python) and compile-time knowledge of the callee signature allow us to (in the JIT) turn many Python function calls into direct calls to a fixed memory address using the x64 calling convention, with little more overhead than a C function call.

Static Python is still gradually typed, and supports code that is only partially annotated or uses unknown types by falling back to normal Python dynamic behavior. In some cases (e.g. when a value of statically-unknown type is returned from a function with a return annotation), a runtime CAST opcode is inserted which will raise TypeError if the runtime type does not match the expected type.

Static Python also supports new types for machine integers, bools, doubles, and vectors/arrays. In the JIT these are handled as unboxed values, and e.g. primitive integer arithmetic avoids all Python overhead. Some operations on builtin types (e.g. list or dictionary subscript or len()) are also optimized.

Cinder doesn't currently come bundled with a module loader that is able to automatically detect static modules and load them as static with cross-module compilation; we currently do this via our strict/static import loader which is not part of Cinder. Currently the best way to experiment with static python in Cinder is to use ./python -m compiler --static some_module.py, which will compile the module as static Python and execute it. (Add the --dis flag to also disassemble it after compilation.) Since this does not use a StrictModule nor freeze types by default, the resulting code won't JIT as optimally as what we get in prod, particularly for function and method calls.

Comments
  • Fix a catching polymorphic type ‘class std::exception’ by value

    Fix a catching polymorphic type ‘class std::exception’ by value

    Fixes https://github.com/facebookincubator/cinder/issues/5

    CLA Signed Merged 
    opened by alexdoesh 13
  • Cannot declare class with attributes

    Cannot declare class with attributes

    What version of Static Python are you using?

    9965302 2021-07-13

    What program did you run?

    class C:
        x: int = 3
    

    What happened?

    ValueError: 'x' in __slots__ conflicts with class variable
    

    What should have happened?

    We expected the program to terminate without errors.

    The error confuses us because it mentions __slots__. As far as we can tell from the python doc and a stackoverflow, __slots__ is used to optimize access to instance attributes. And this optimization has to be enabled in a manual and low-level manner. From this perspective, class attributes should have little to do with slots, unless a class attribute is shadowed by an instance attribute.

    We found a similar test in cinder/test_static.py

        def test_class_level_final_reinitialized_directly(self):
            codestr = """
            from typing import Final
    
            class C:
                x: Final[int] = 3
    
            C.x = 4
            """
            # Note - this will raise even without the Final, we don't allow assignments to slots
            with self.assertRaisesRegex(
                TypedSyntaxError,
                type_mismatch("Literal[4]", "Exact[types.MemberDescriptorType]"),
            ):
                self.compile(codestr, StaticCodeGenerator, modname="foo")
    

    We wonder

    • How to read the line x: Final[int] = 3? Is this an initialization, an assignment, or both?
    • Does Static Python have class attributes? Or are you only supposed to declare the fields that instances will have?
    staticpython sp-correctness 
    opened by LuKC1024 10
  • Cinder vs. Python 3.11

    Cinder vs. Python 3.11

    I haven't tried it on my application yet, but Python 3.11 is said to give about a 25% speedup on benchmarks.

    With Cinder, maybe we can expect 2x on static modules with full typing, and 5x with cinder-specific typing. But that only applies to the portion of the application that we convert to static.

    The apparent quandary: go to Python 3.11 and take the free 25% across the board, or stay on 3.8 (or 3.10) and work hard migrating to Cinder (includes learning, tooling), which offers a higher upper-bound on performance?

    I see that a 3.10 port is active, but is there any guidance on when Cinder might support 3.11 so that this isn't an either-or decision?

    opened by belm0 9
  • docs: add GH button in support of Ukraine

    docs: add GH button in support of Ukraine

    Summary

    Our mission at Meta Open Source is to empower communities through open source, and we believe that it means building a welcoming and safe environment for all. As a part of this work, we are adding this banner in support for Ukraine during this crisis.

    CLA Signed 
    opened by dmitryvinn 5
  • take infinite loops into account in type narrowing

    take infinite loops into account in type narrowing

    The fix for #62 will probably lead us to reject this program:

    from typing import Optional
    
    def f(x: Optional[str]) -> str:
        while True:
            if x is None:
                continue
            return x
    
    print(f(None))
    

    In order to fix this, we need to understand that the while loop does not terminate (unless there's a break) and narrow the types in the code following the loop accordingly.

    staticpython sp-correctness 
    opened by carljm 5
  • Class values as CheckedDict type-arguments are not handled properly

    Class values as CheckedDict type-arguments are not handled properly

    9186730 2021-12-01

    This issue might be related to https://github.com/facebookincubator/cinder/issues/33

    What program did you run?

    from __static__ import CheckedDict
    def make_C():
        class C: pass
        return C
    C = make_C()
    d = CheckedDict[str, C]({})
    

    What happened?

    The program raises a runtime error.

    TypeError: chkdict[str, object].__new__(chkdict[str, C]): chkdict[str, C] is not a subtype of chkdict[str, object]
    

    What should have happened?

    We expected two possible outcomes:

    • a compile-time error complaining that CheckedDict[str, C] is invalid because C is not a valid type
    • a clearer run-time error
    • the program terminates without any error.
    staticpython sp-correctness 
    opened by LuKC1024 5
  • A test in `test_static` should catch `AssertionError` rather than `TypeError`

    A test in `test_static` should catch `AssertionError` rather than `TypeError`

    2022-01-07

    foo("a") raises an AssertionError, but the test expects a TypeError.

    def test_assert_narrowing_optimized(self):
        # We ensure that the code without the assert would work in the runtime.
        codestr = """
        def foo(x: int | str) -> object:
            assert isinstance(x, int)
            return x
        """
    
        with self.in_module(codestr, optimize=1) as mod:
            foo = mod.foo
            self.assertEqual(foo(1), 1)
            with self.assertRaises(TypeError):
                foo("a")
    

    There is a test that looks like a corrected version of this one.

    def test_assert_narrowing_debug(self):
        codestr = """
        def foo(x: int | str) -> int:
            assert isinstance(x, int)
            return x + 1
        """
        with self.in_module(codestr) as mod:
            foo = mod.foo
            self.assertEqual(foo(1), 2)
            with self.assertRaises(AssertionError):
                foo("a")
    
    opened by LuKC1024 4
  • doc: clarify ctypes = primitives

    doc: clarify ctypes = primitives

    Add a comma to show that "primitive types" and "C types" mean the same thing.

    (The old wording "primitive or C types" could be mis-read as "(primitive or C) types" at first glance.)

    CLA Signed 
    opened by bennn 4
  • "TypeError: an integer is required" when calling function returning double

    seen as of cinder 5bd8c57 (and it occurs prior to that commit)

    from __static__ import double
    
    def test() -> double:
        return double(.5)
    
    test()
    
    $ python -m compiler --static foo.py
    TypeError: an integer is required
    
    The above exception was the direct cause of the following exception:
    
    Traceback (most recent call last):
      File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
        exec(code, run_globals)
      File "/usr/lib/python3.8/compiler/__main__.py", line 111, in <module>
        exec(codeobj)
      File "/.../foo.py", line 6, in __main__
        test()
    SystemError: PyEval_EvalFrameEx returned a result with an error set
    

    (Same error even when test() is not called from module scope.)

    staticpython sp-correctness 
    opened by belm0 4
  • add necessary dependencies in build env dockerfiles

    add necessary dependencies in build env dockerfiles

    Current dockerfile missing some important dependencies, which will caused the build cinder lack of features, like ssl support, leads to you can't install pypi.io packages since it neet https support.

    CLA Signed Merged 
    opened by aisk 4
  • Can't get Docker Image - Unauthorized

    Can't get Docker Image - Unauthorized

    When I try to run

    docker run -v "$PWD/cinder:/vol" -w /vol -ti ghcr.io/facebookincubator/cinder/python-build-env:latest bash
    

    I get

    Unable to find image 'ghcr.io/facebookincubator/cinder/python-build-env:latest' locally
    docker: Error response from daemon: Get https://ghcr.io/v2/facebookincubator/cinder/python-build-env/manifests/latest: unauthorized.
    See 'docker run --help'.
    
    opened by nilansaha 4
  • Bump actions/cache from 3.0.2 to 3.2.2

    Bump actions/cache from 3.0.2 to 3.2.2

    Bumps actions/cache from 3.0.2 to 3.2.2.

    Release notes

    Sourced from actions/cache's releases.

    v3.2.2

    What's Changed

    New Contributors

    Full Changelog: https://github.com/actions/cache/compare/v3.2.1...v3.2.2

    v3.2.1

    What's Changed

    Full Changelog: https://github.com/actions/cache/compare/v3.2.0...v3.2.1

    v3.2.0

    What's Changed

    New Contributors

    ... (truncated)

    Changelog

    Sourced from actions/cache's changelog.

    3.0.2

    • Added support for dynamic cache size cap on GHES.

    3.0.3

    • Fixed avoiding empty cache save when no files are available for caching. (issue)

    3.0.4

    • Fixed tar creation error while trying to create tar with path as ~/ home folder on ubuntu-latest. (issue)

    3.0.5

    • Removed error handling by consuming actions/cache 3.0 toolkit, Now cache server error handling will be done by toolkit. (PR)

    3.0.6

    • Fixed #809 - zstd -d: no such file or directory error
    • Fixed #833 - cache doesn't work with github workspace directory

    3.0.7

    • Fixed #810 - download stuck issue. A new timeout is introduced in the download process to abort the download if it gets stuck and doesn't finish within an hour.

    3.0.8

    • Fix zstd not working for windows on gnu tar in issues #888 and #891.
    • Allowing users to provide a custom timeout as input for aborting download of a cache segment using an environment variable SEGMENT_DOWNLOAD_TIMEOUT_MINS. Default is 60 minutes.

    3.0.9

    • Enhanced the warning message for cache unavailablity in case of GHES.

    3.0.10

    • Fix a bug with sorting inputs.
    • Update definition for restore-keys in README.md

    3.0.11

    • Update toolkit version to 3.0.5 to include @actions/core@^1.10.0
    • Update @actions/cache to use updated saveState and setOutput functions from @actions/core@^1.10.0

    3.1.0-beta.1

    • Update @actions/cache on windows to use gnu tar and zstd by default and fallback to bsdtar and zstd if gnu tar is not available. (issue)

    3.1.0-beta.2

    • Added support for fallback to gzip to restore old caches on windows.

    3.1.0-beta.3

    • Bug fixes for bsdtar fallback if gnutar not available and gzip fallback if cache saved using old cache action on windows.

    3.2.0-beta.1

    • Added two new actions - restore and save for granular control on cache.

    3.2.0

    • Released the two new actions - restore and save for granular control on cache

    3.2.1

    ... (truncated)

    Commits
    • 4723a57 Revert compression changes related to windows but keep version logging (#1049)
    • d1507cc Merge pull request #1042 from me-and/correct-readme-re-windows
    • 3337563 Merge branch 'main' into correct-readme-re-windows
    • 60c7666 save/README.md: Fix typo in example (#1040)
    • b053f2b Fix formatting error in restore/README.md (#1044)
    • 501277c README.md: remove outdated Windows cache tip link
    • c1a5de8 Upgrade codeql to v2 (#1023)
    • 9b0be58 Release compression related changes for windows (#1039)
    • c17f4bf GA for granular cache (#1035)
    • ac25611 docs: fix an invalid link in workarounds.md (#929)
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    CLA Signed 
    opened by dependabot[bot] 1
  • Bump actions/stale from 5 to 7

    Bump actions/stale from 5 to 7

    Bumps actions/stale from 5 to 7.

    Release notes

    Sourced from actions/stale's releases.

    v7.0.0

    ⚠️ This version contains breaking changes ⚠️

    What's Changed

    Breaking Changes

    • In this release we prevent this action from managing the stale label on items included in exempt-issue-labels and exempt-pr-labels
    • We decided that this is outside of the scope of this action, and to be left up to the maintainer

    New Contributors

    Full Changelog: https://github.com/actions/stale/compare/v6...v7.0.0

    v6.0.1

    Update @​actions/core to 1.10.0 #839

    Full Changelog: https://github.com/actions/stale/compare/v6.0.0...v6.0.1

    v6.0.0

    :warning: Breaking change :warning:

    Issues/PRs default close-issue-reason is now not_planned(#789)

    V5.2.0

    Features: New option include-only-assigned enables users to process only issues/PRs that are already assigned. If there is no assignees and this option is set, issue will not be processed per: issue/596

    Fixes: Fix date comparison edge case PR/816

    Dependency Updates: PR/812

    Fix issue when days-before-close is more than days-before-stale

    fixes a bug introduced in #717

    fixed in #775

    v5.1.0

    [5.1.0]

    ... (truncated)

    Changelog

    Sourced from actions/stale's changelog.

    Changelog

    [7.0.0]

    :warning: Breaking change :warning:

    [6.0.1]

    Update @​actions/core to v1.10.0 (#839)

    [6.0.0]

    :warning: Breaking change :warning:

    Issues/PRs default close-issue-reason is now not_planned(#789)

    [5.1.0]

    Don't process stale issues right after they're marked stale [Add close-issue-reason option]#764#772 Various dependabot/dependency updates

    4.1.0 (2021-07-14)

    Features

    4.0.0 (2021-07-14)

    Features

    Bug Fixes

    • dry-run: forbid mutations in dry-run (#500) (f1017f3), closes #499
    • logs: coloured logs (#465) (5fbbfba)
    • operations: fail fast the current batch to respect the operations limit (#474) (5f6f311), closes #466
    • label comparison: make label comparison case insensitive #517, closes #516
    • filtering comments by actor could have strange behavior: "stale" comments are now detected based on if the message is the stale message not who made the comment(#519), fixes #441, #509, #518

    Breaking Changes

    ... (truncated)

    Commits
    • 6f05e42 draft release for v7.0.0 (#888)
    • eed91cb Update how stale handles exempt items (#874)
    • 10dc265 Merge pull request #880 from akv-platform/update-stale-repo
    • 9c1eb3f Update .md files and allign build-test.yml with the current test.yml
    • bc357bd Update .github/workflows/release-new-action-version.yml
    • 690ede5 Update .github/ISSUE_TEMPLATE/bug_report.md
    • afbcabf Merge branch 'main' into update-stale-repo
    • e364411 Update name of codeql.yml file
    • 627cef3 fix print outputs step (#859)
    • 975308f Merge pull request #876 from jongwooo/chore/use-cache-in-check-dist
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    CLA Signed 
    opened by dependabot[bot] 1
  • HPy support

    HPy support

    Hello!

    Supporting HPy - an alternative for the CPython C API could offer some benefits for cinder. Some python libraries have branches which support the HPy API - and while it is slower by default when used as a shim on top of the standard CPython implementation - it removes implementation details from the CPython C API, which buys options to make different choices (JIT, garbage collector, etc) like those made here in cinder. CPython extension modules that target the HPy API would Just Work with any python runtime that supports HPy - which means you don't have to change your C API to match changes from 3.9+.

    opened by koubaa 2
  • No pattern found for opcode Fadd: Xxr

    No pattern found for opcode Fadd: Xxr

    $ docker run -v $PWD:/vol -it --rm ghcr.io/facebookincubator/cinder-runtime:cinder-3.8 -X jit -m compiler --static vol/autogen_bug.py
    JIT: /cinder/src/Jit/codegen/autogen.cpp:143 -- assertion failed: func != nullptr
    No pattern found for opcode Fadd: Xxr
    
    from __static__ import box, double, inline
    
    @inline
    def foo(a: double, b: double) -> double:
        return b - a
    
    def main():
        c: double = 0.
        for _ in range(10):
            c += foo(.4, .97)
        print('done', box(c))
    
    if __name__ == '__main__':
        main()
    

    The problem goes away if @inline is removed.

    See in seen in cinder-3.8.6c2de94

    staticpython sp-correctness 
    opened by belm0 2
  • nonsensical TypeError from

    nonsensical TypeError from "-X jit -m compile --static"

    good (no options):

    $ docker run -v $PWD:/vol -it --rm ghcr.io/facebookincubator/cinder-runtime:cinder-3.8 vol/cinder_typed_prim_bug.py
    done 0.57
    

    bad (-X jit -m compile --static):

    $ docker run -v $PWD:/vol -it --rm ghcr.io/facebookincubator/cinder-runtime:cinder-3.8 -X jit -m compiler --static vol/cinder_typed_prim_bug.py
    Traceback (most recent call last):
      File "/cinder/lib/python3.8/runpy.py", line 194, in _run_module_as_main
        return _run_code(code, main_globals, None,
      File "/cinder/lib/python3.8/runpy.py", line 87, in _run_code
        exec(code, run_globals)
      File "/cinder/lib/python3.8/compiler/__main__.py", line 122, in <module>
        exec(codeobj, d, d)
      File "vol/cinder_typed_prim_bug.py", line 15, in __main__
        main()
      File "vol/cinder_typed_prim_bug.py", line 10, in main
        c += foo(.4, .97)
    TypeError: unsupported operand type(s) for +=: 'float' and 'function'
    

    The compiler is acting as if the written code were c += foo rather than c += foo(.4, .97).

    The problem goes away by removing -X jit, --static, or use of the double primitives.

    cinder_typed_prim_bug.py

    from __static__ import double
    
    def foo(a: double, b: double) -> double:
        return b - a
    
    def main():
        c = 0.
        c += foo(.4, .97)
        print('done', c)
    
    if __name__ == '__main__':
        main()
    

    seen in cinder-3.8.6c2de94

    staticpython sp-correctness 
    opened by belm0 3
  • can't compare double to Literal

    can't compare double to Literal

    Is it intentional that a double can't be compared to an integer literal?

        if plus >= 0:
          ^
    compiler.errors.TypedSyntaxError: can't compare double to Literal[0]
    
    staticpython sp-correctness 
    opened by belm0 1
Owner
Facebook Incubator
We work hard to contribute our work back to the web, mobile, big data, & infrastructure communities. NB: members must have two-factor auth.
Facebook Incubator
guapow is an on-demand and auto performance optimizer for Linux applications.

guapow is an on-demand and auto performance optimizer for Linux applications. This project's name is an abbreviation for Guarana powder (Guaraná is a fruit from the Amazon rainforest with a highly caffeinated seed).

Vinícius Moreira 19 Nov 18, 2022
Python compiler that massively increases Python's code performance without code changes.

Flyable - A python compiler for highly performant code Flyable is a Python compiler that generates efficient native code. It uses different techniques

Flyable 35 Dec 16, 2022
CPython Extension Module Support for Flit

CPython Extension Module Support for Flit This is a PEP 517 build backend piggybacking (and hacking) Flit to support building C extensions. Mostly a p

Tzu-ping Chung 8 May 24, 2022
Model Validation Toolkit is a collection of tools to assist with validating machine learning models prior to deploying them to production and monitoring them after deployment to production.

Model Validation Toolkit is a collection of tools to assist with validating machine learning models prior to deploying them to production and monitoring them after deployment to production.

FINRA 25 Dec 28, 2022
One version package to rule them all, One version package to find them, One version package to bring them all, and in the darkness bind them.

AwesomeVersion One version package to rule them all, One version package to find them, One version package to bring them all, and in the darkness bind

Joakim Sørensen 39 Dec 31, 2022
This Repository is an up-to-date version of Harvard nlp's Legacy code and a Refactoring of the jupyter notebook version as a shell script version.

This Repository is an up-to-date version of Harvard nlp's Legacy code and a Refactoring of the jupyter notebook version as a shell script version.

신재욱 17 Sep 25, 2022
FastAPI framework, high performance, easy to learn, fast to code, ready for production

FastAPI framework, high performance, easy to learn, fast to code, ready for production Documentation: https://fastapi.tiangolo.com Source Code: https:

Sebastián Ramírez 53k Jan 2, 2023
FastAPI framework, high performance, easy to learn, fast to code, ready for production

FastAPI framework, high performance, easy to learn, fast to code, ready for production Documentation: https://fastapi.tiangolo.com Source Code: https:

Sebastián Ramírez 53.1k Jan 6, 2023
The earliest beta version of pytgcalls on Linux x86_64 and ARM64! Use in production at your own risk!

Public beta test. Use in production at your own risk! tgcalls - a python binding for tgcalls (c++ lib by Telegram); pytgcalls - library connecting pyt

Il'ya 21 Jan 13, 2022
codes for Image Inpainting with External-internal Learning and Monochromic Bottleneck

Image Inpainting with External-internal Learning and Monochromic Bottleneck This repository is for the CVPR 2021 paper: 'Image Inpainting with Externa

null 97 Nov 29, 2022
This is a junk file creator tool which creates junk files in Internal Storage

This is a junk file creator tool which creates junk files in Internal Storage

KiLL3R_xRO 3 Jun 20, 2021
A Python tool to generate a static HTML file that represents the internal structure of a PDF file

PDFSyntax A Python tool to generate a static HTML file that represents the internal structure of a PDF file At some point the low-level functions deve

Martin D. 394 Dec 30, 2022
PyTorch implementation of 1712.06087 "Zero-Shot" Super-Resolution using Deep Internal Learning

Unofficial PyTorch implementation of "Zero-Shot" Super-Resolution using Deep Internal Learning Unofficial Implementation of 1712.06087 "Zero-Shot" Sup

Jacob Gildenblat 196 Nov 27, 2022
Implementation for our ICCV2021 paper: Internal Video Inpainting by Implicit Long-range Propagation

Implicit Internal Video Inpainting Implementation for our ICCV2021 paper: Internal Video Inpainting by Implicit Long-range Propagation paper | project

null 202 Dec 30, 2022
A data parser for the internal syncing data format used by Fog of World.

A data parser for the internal syncing data format used by Fog of World. The parser is not designed to be a well-coded library with good performance, it is more like a demo for showing the data structure.

Zed(Zijun) Chen 40 Dec 12, 2022
Python wrappers for external BART computational imaging tools and internal libraries

bartpy Python bindings for BART. Overview This repo contains code to generate an updated Python wrapper for the Berkeley Advance Reconstruction Toolbo

Max Litster 7 May 9, 2022
Dahua Console, access internal debug console and/or other researched functions in Dahua devices.

Dahua Console, access internal debug console and/or other researched functions in Dahua devices.

bashis 156 Dec 28, 2022
Official Pytorch implementation of Meta Internal Learning

Official Pytorch implementation of Meta Internal Learning

null 10 Aug 24, 2022
This repo is for Self-Supervised Monocular Depth Estimation with Internal Feature Fusion(arXiv), BMVC2021

DIFFNet This repo is for Self-Supervised Monocular Depth Estimation with Internal Feature Fusion(arXiv), BMVC2021 A new backbone for self-supervised d

Hang 3 Oct 22, 2021
Tools used by Ada Health's internal IT team to deploy and manage a serverless Munki setup.

Serverless Munki This repository contains cross platform code to deploy a production ready Munki service, complete with AutoPkg, that runs entirely fr

Ada Health 17 Dec 5, 2022