Taichi Lang: a JIT decorator that turns Python loops into parallel machine code

The kernel decorator, not the script, is what gets compiled

Taichi Lang does not replace Python. It embeds in it, shares almost the same syntax, and is integrated into the Python ecosystem, including NumPy and PyTorch. The compile step happens on decorated functions: `@ti.kernel` marks a function for the just-in-time compiler, which lowers it to native GPU or CPU instructions through a framework such as LLVM. `ti.init(arch=ti.gpu)` picks the target before any kernel runs, and the whole simulation then executes in parallel.

The 2D fractal example starts with the field the kernel writes into and the vector helpers it reads from:

import taichi as ti

ti.init(arch=ti.gpu)

n = 320
pixels = ti.field(dtype=float, shape=(n * 2, n))

@ti.func
def complex_sqr(z):
    return ti.Vector([z[0]**2 - z[1]**2, z[1] * z[0] * 2])

`@ti.func` marks a helper that a kernel can call without it becoming an entry point of its own.

Iteration over a field is the parallel loop

The fractal kernel contains the loop that decides everything about performance:

@ti.kernel
def paint(t: float):
    for i, j in pixels:  # Parallelized over all pixels
        c = ti.Vector([-0.8, ti.cos(t) * 0.2])
        z = ti.Vector([i / n - 1, j / n - 0.5]) * 2
        iterations = 0
        while z.norm() < 20 and iterations < 50:
            z = complex_sqr(z) + c
            iterations += 1

The loop header is not a Python range. It walks the `pixels` field, and the loop is parallelized over all pixels. The loop body stays ordinary Python arithmetic on `ti.Vector` values, with the exit condition bounded twice, once by the norm and once by a 50 iteration cap, so a runaway pixel cannot stall the frame.

The backend list ends with a WebAssembly target marked experimental

The prerequisite block enumerates the compute backends: x64 and ARM CPUs, CUDA, Vulkan, OpenGL at 4.3 or newer, Apple Metal, and WebAssembly, which is the one entry carrying an experimental label. Everything else is presented as a supported target. The portability claim is narrower and worth separating: most mainstream GPU APIs, with CUDA and Vulkan given as examples.

Apple Metal is on the backend list as a target. OpenGL 4.3 is the line that sets a floor rather than naming a device. WebAssembly appears only as a target to compile for, which is a different promise from running a CUDA kernel on a GPU.

The nightly wheel comes from a self-hosted PyPI and may crash

The released package installs with Python's own installer:

pip install --upgrade taichi

There is a second route for the unreleased line, and it does not come from PyPI:

pip install -i https://pypi.taichi.graphics/simple/ taichi-nightly

The index is self-hosted, and the reason given is to allow more frequent releases over a longer stretch of time. The warning attached to it is blunt: nightly packages may crash because they are not fully tested, their validity is not guaranteed, and trying the newest untested features is at your own risk. A third path exists for building from source, which is the route for experimental features or for building in your own environment. There is also a `ti gallery` command that launches the demo gallery once installation has succeeded.

The prerequisites say Python 3.6 to 3.10, the classifiers say 3.9 to 3.11

Two files in the same repository disagree about which Python versions are supported. The prerequisite block states Python 3.6 to 3.10, 64-bit only, and names Windows, Linux and macOS as the operating systems. The packaging classifiers in setup.py list Python 3.9, 3.10 and 3.11. A project on 3.11 is inside the classifiers and outside the prerequisites, and a project on 3.8 is the reverse.

The classifiers also carry the project's own status claim, `Development Status :: 5 - Production/Stable`, alongside topics for compilers, graphics and simulation, and intended audiences for science, research and developers. The license marker is `Apache Software License`, matching the Apache License Version 2.0 the project distributes under. Anyone pinning a Python version needs to decide which file to believe before the install attempt, not after.

A source build pulls scikit-build, CMake and Ninja on every platform but Windows

The build backend is setuptools through `setuptools.build_meta`, and the declared requirements are setuptools, wheel, numpy, pybind11, cmake and scikit-build, with ninja requested only when the platform is not Windows. `setup.py` imports setup from skbuild, sets the package root to the `python/` directory, and finds packages below it. The version comes from `version.txt` unless the RELEASE_VERSION environment variable overrides it, and it is split into major, minor and patch pieces.

Four environment variables steer the C++ extension: TAICHI_CMAKE_ARGS appends arguments to the CMake invocation, while DEBUG, RELWITHDEBINFO and MINSIZEREL select the build type. Data files are collected from a runtime directory with a glob. The tree around this is wide, with c_api/, cpp_examples/, benchmarks/, tests/, ci/, cmake/, conda/, external/, misc/, scripts/ and docs/ sitting beside the Python package, plus CMakeLists.txt, build.py, MANIFEST.in, .clang-format, .clang-tidy and .pylintrc.

Pytest silences four deprecation warnings that the language itself emits

The pytest configuration filters four warnings, and three of them come from Taichi itself, two of them deprecations of operators in Taichi scope:

filterwarnings = [
    "ignore:Calling non-taichi function",
    "ignore:`np.int` is a deprecated alias",
    "ignore:Operator \"is\" in Taichi scope is deprecated",
    "ignore:Operator \"is not\" in Taichi scope is deprecated"
]

Two of them are the identity operators, so code that compares objects with `is` inside a Taichi scope still runs but is marked deprecated and then hidden from the test output. The third points at calls into non-Taichi functions from inside kernel scope. The fourth is NumPy's own `np.int` alias, which is the one warning here that does not come from this project. Formatting is pinned to yapf with a pep8 base style and nested class or function blank lines disabled, and a pre-commit config sits at the top level alongside it.

The newest release is v1.7.4 and the last push was on 2026-07-06

The release history is sparse. v1.7.2 shipped on 2024-08-22, v1.7.3 on 2024-12-23, and v1.7.4 on 2025-07-31. The repository is not archived, its default branch is master, and the last push was on 2026-10-05, which is well after that newest tag. Commits are landing on master without a matching release, so a `pip install taichi` today gives you v1.7.4 rather than the state of the default branch. That gap is the practical argument for the nightly channel or for the developer installation, both of which are documented as the untested and the source-built routes respectively.

The homepage is taichi-lang.org and the documentation, API reference and blog all sit under docs.taichi-lang.org, with a Chinese forum at forum.taichi.graphics and a Discord for discussions. Security issues are asked for by mail rather than by issue, at the address given in the project.

Editorial conclusion

Taichi Lang earns its place when the inner loop is the bottleneck and you want to keep writing Python, and it costs you a language surface of its own, a source build with CMake and Ninja, and a Python range that its own two files disagree about. Before committing, confirm which Python version your environment really runs, which backend your GPU exposes, and whether you can accept an untested nightly wheel if the released wheel lags behind.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. taichi-dev/taichi on GitHub