Thoughts on the Taichi programming language - sparse computing and differentiable programming

I recently came across the Taichi programming language and I was curious what people here think about it and how it compares to Julia and Swift. It seems to have a special focus on “spatially sparse computing” and differentiable programming. Their documentation also says that they are in the process of moving towards LLVM. So I would appreciate any insights.


Is it Python or is it not? That’s my thought.

1 Like

They call it a “programming language […] embedded in Python”.

As far as I understand it, “yes” it’s Python (but not only; the add-on feels more like a library than a new language, and the add-on “extra language” is in some sense not Python, while I’ve not looked carefully), the compiler is not for Python code in general, only for the decorated kernels, and there’s not a preprocessor (in the sense of in “C with Classes”, later named C++). The compiler is a Python class, that works on the Python AST of those decorated kernels only.

There’s a clever sparse data structure involved, something Julia could replicate it seems, or just reuse.


1 Like

Yeah, it seems more like a library than a language. However, they make extensive use of decorators to create a domain-specific language, and it looks like they’re also doing some hacking on type hints, like with this:

def copy(x: ti.template(), y: ti.template()):
    for i in x:
        y[i] = x[i]

a = ti.field(ti.f32, 4)
b = ti.field(ti.f32, 4)
c = ti.field(ti.f32, 12)
d = ti.field(ti.f32, 12)
copy(a, b)
copy(c, d)
1 Like

Right, I believe this is all legal python ‘‘syntax’’. I tested the def (without “ti.”). The semantics of type hints in Python, are well, do nothing with them, always still I believe, some tools however e.g. mypy give them meaning, and here something different done. Semantic-wise, the Taichi CPU and GPU compiler does something for @ti.kernel, and semantic-wise then you could say it’s a superset of Python (or an allowed superset), while syntax-wise it’s just Python (unless there’s something I missed), and with a macro we could allow this exact syntax (and behavior) as was done with PythonSyntax.jl, while something like that may be overkill and you would just use PyCall?

Yeah, decorators in Python are just higher-order functions. They take in the function below them and return a new function.