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

Facebook Incubator

Last update: Dec 30, 2022

Related tags

Performance optimization cinder

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:

Install and setup Docker.
Clone the Cinder repo:

git clone https://github.com/facebookincubator/cinder
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.
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

Fixes https://github.com/facebookincubator/cinder/issues/5
CLA Signed Merged

opened by alexdoesh 13
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

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

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
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
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`

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

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

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

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
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

Fix formatting error in restore/README.md by @me-and in actions/cache#1044

save/README.md: Fix typo in example by @mmuetzel in actions/cache#1040

README.md: remove outdated Windows cache tip link by @me-and in actions/cache#1042

Revert compression changes related to windows but keep version logging by @Phantsure in actions/cache#1049

New Contributors

@me-and made their first contribution in actions/cache#1044

@mmuetzel made their first contribution in actions/cache#1040

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

v3.2.1

What's Changed

Release compression related changes for windows by @Phantsure in actions/cache#1039

Upgrade codeql to v2 by @Phantsure in actions/cache#1023

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

v3.2.0

What's Changed

fix wrong timeout env var key in README.md by @walterddr in actions/cache#959

Updated release doc with correct env variable by @kotewar in actions/cache#960

Create pull_request_template.md by @pdotl in actions/cache#963

Update README with clearer info about cache-hit and its value by @kotewar in actions/cache#961

Change datadog/squid to Ubuntu/squid in CI check by @bishal-pdMSFT in actions/cache#976

Add more details to version section in readme by @bishal-pdMSFT in actions/cache#971

Update hashFiles documentation reference by @asaf400 in actions/cache#979

Updated link for cache segment download info by @kotewar in actions/cache#986

Readme update for deleting caches by @t-dedah in actions/cache#981

Add oncall logic to assign issues and PRs by @vsvipul in actions/cache#997

Bump minimatch from 3.0.4 to 3.1.2 by @dependabot in actions/cache#998

Revert "Bump minimatch from 3.0.4 to 3.1.2" by @vsvipul in actions/cache#1005

Fix npm vulnerability by @Phantsure in actions/cache#1007

refactor: Use early return pattern to avoid nested conditions by @jongwooo in actions/cache#1013

Use cache in check-dist.yml by @jongwooo in actions/cache#1004

chore: Use built-in cache action to cache dependencies by @jongwooo in actions/cache#1014

Updated node example by @t-dedah in actions/cache#1008

Fix: Node npm doc example by @apascualm in actions/cache#1026

docs: fix an invalid link in workarounds.md by @teatimeguest in actions/cache#929

General Availability release for granular cache by @kotewar in actions/cache#1035 More details here on beta release.

New Contributors

@walterddr made their first contribution in actions/cache#959

@asaf400 made their first contribution in actions/cache#979

@jongwooo made their first contribution in actions/cache#1013

@apascualm made their first contribution in actions/cache#1026

@teatimeguest made their first contribution in actions/cache#929

... (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 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
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

Allow daysBeforeStale options to be float by @irega in actions/stale#841

Use cache in check-dist.yml by @jongwooo in actions/stale#876

fix print outputs step in existing workflows by @irega in actions/stale#859

Update issue and PR templates, add/delete workflow files by @IvanZosimov in actions/stale#880

Update how stale handles exempt items by @johnsudol in actions/stale#874

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

@irega made their first contribution in actions/stale#841

@jongwooo made their first contribution in actions/stale#876

@IvanZosimov made their first contribution in actions/stale#880

@johnsudol made their first contribution in actions/stale#874

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:

Allow daysBeforeStale options to be float by @irega in actions/stale#841

Use cache in check-dist.yml by @jongwooo in actions/stale#876

fix print outputs step in existing workflows by @irega in actions/stale#859

Update issue and PR templates, add/delete workflow files by @IvanZosimov in actions/stale#880

Update how stale handles exempt items by @johnsudol in actions/stale#874

[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

Ability to exempt draft PRs

4.0.0 (2021-07-14)

Features

options: simplify config by removing skip stale message options (#457) (6ec637d), closes #405 #455

output: print output parameters (#458) (3e6d35b)

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 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

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

$ 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 "-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
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.

GitHub

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).

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

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

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.

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

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.

17 Sep 25, 2022

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

Related tags

Overview

Welcome to Cinder!

Is this supported?

How do I build it?

What's here?

Shadowcode

Eager coroutine evaluation

The Cinder JIT

Strict Modules

Static Python

Comments

What version of Static Python are you using?

What program did you run?

What happened?

What should have happened?

Summary

What program did you run?

What happened?

What should have happened?

v3.2.2

What's Changed

New Contributors

v3.2.1

What's Changed

v3.2.0

What's Changed

New Contributors

3.0.2

3.0.3

3.0.4

3.0.5

3.0.6

3.0.7

3.0.8

3.0.9

3.0.10

3.0.11

3.1.0-beta.1

3.1.0-beta.2

3.1.0-beta.3

3.2.0-beta.1

3.2.0

3.2.1

v7.0.0

What's Changed

Breaking Changes

New Contributors

v6.0.1

v6.0.0

V5.2.0

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

v5.1.0

[5.1.0]

Changelog

[7.0.0]

[6.0.1]

[6.0.0]

[5.1.0]

4.1.0 (2021-07-14)

Features

4.0.0 (2021-07-14)

Features

Bug Fixes

Breaking Changes

Owner

Facebook Incubator

guapow is an on-demand and auto performance optimizer for Linux applications.

Python compiler that massively increases Python's code performance without code changes.

CPython Extension Module Support for Flit

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.

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.

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.

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

The earliest beta version of pytgcalls on Linux x86_64 and ARM64! Use in production at your own risk!

codes for Image Inpainting with External-internal Learning and Monochromic Bottleneck

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

A Python tool to generate a static HTML file that represents the internal structure of a PDF file