11 ms·

Taichi lang: High-performance parallel programming in Python

179 points by whereistimbo 4y ago

inconceivable 4y ago
wow. i ran their prime number python accelerator example on 10 000 000 upper bound: (taichi) [X@X taichi]$ python primes.py [Taichi] version 1.4.1, llvm 15.0.4, commit e67c674e, linux, python 3.9.14 [Taichi] Starting on arch=x64 Number of primes: 664579 time elapsed: 93.54279175889678/s Number of primes: 664579 time elapsed: 0.5988388371188194/s
- ipnon 4y ago
  It seems like Taichi fast language, but it can also never be overstated how slow Python is on contemporary architectures.
  - nerdponx 4y ago
    Right, I'd like to see a comparison to Nim or Julia, or another compiled high-level language that isn't particularly performance-oriented like Haskell or Clojure, or Common Lisp, or even Ruby with its new JIT(s). Or for that matter, Python with Numba or one of the other JIT implementations (PyPy, Pyston, Cinder).
  - ActorNightly 4y ago
    It doesn't support 3.11 yet. 3.10 is slow compared to 3.11.
    - nxpnsv 4y ago
      yeah, but not on the level as the top level comment...
- gus_massa 4y ago
  Is that improvement caused because the program is automatically parallelized or because the code is compiled/JITed? A x150 improvement is too much, so I suspect both reasons collaborate to get it.
  - inconceivable 4y ago
    they say the example i used is JIT compiled into machine code. i haven't looked into the codebase yet but i presume that means it just un-pythons it back into C? not sure. fwiw, i tried the gpu target (cuda) and it was faster than vanilla, but slower than accelerated cpu target by about 4x.
    - gus_massa 4y ago
      How does it compare with numba? (I don't know enough about the python ecosystem, but I have to tweak code from one of my coworkers and he uses numba.)
- adgjlsfhk1 4y ago
  And if you run it on a number bigger than 2^64, does it error because taichi automatically assumes python's BigInts are Int64s?
deleted 4y ago
[deleted]
calebm 4y ago
This looks amazing! (particularly for some of my interests - https://gods.art https://gods.art)
xiaodai 4y ago
Please don't retrofit more stuff to make python work. move over to julia already. u can call python from Julia
- deleted 4y ago
  [deleted]
- packetlost 4y ago
  I wouldn't consider Julia a replacement for Python
  - Iwan-Zotow 4y ago
    and its an ugly thing they didn't get range composition right
    - xiaodai 4y ago
      care to elaborate
      - Iwan-Zotow 4y ago
        In C and Python (which inherited it from C, I believe) for(int k = 0; k != N; ++k) { dowork(k); }, similar in Python ranges are [0...N). If I want just a sum, and would like to split work among multiple CPUs, I could write s = sum(0...N) or s = sum(0...N/2) + sum(N/2...N) or s = sum(0...N/3) + sum(N/3...5N/7) + sum(5N/7...N) and it will work beautifully. Ranges are decomposable and composable with any number(s) splitting original range. [0...N/2) + [N/2...N) = [0...N) When I first looked at Julia, I was ... unhappy. They didn't get simple ranges composability right. You could do it, sure, but it looks so ... unnnatural.
    - packetlost 4y ago
      1 indexed arrays has me confused as hell
      - 4y ago
farcaster 4y ago
I was playing earlier today with Triton[0], from OpenAI. Like Taichi it makes it super easy to write native GPU code from Python, but it really does feel like something very experimental for now. (I know the use case is very different) [0] https://openai.com/research/triton https://openai.com/research/triton
- coldtea 4y ago
  >but it really does feel like something very experimental for now Meaning? - their approach is still bizarre and exploratory and they still don't know how to structure their APIs and are making it up as they go? or: - there are still some rough edges, bugs, and no full documentation yet? as those are quite different cases...
- Archit3ch 4y ago
  >CPUs and AMD GPUs are not supported at the moment CUDA-only, no mention of Metal.
  - deleted 4y ago
    [deleted]
- robertlagrant 4y ago
  Triton is clearly a popular name for GPU access and inference[0]. [0] https://developer.nvidia.com/nvidia-triton-inference-server https://developer.nvidia.com/nvidia-triton-inference-server
sh1mmer 4y ago
> No barrier to entry for Python users: Taichi shares almost the same syntax as Python. Apply a single Taichi decorator, and your functions are automatically turned into optimized machine code. It looks super interesting except “almost the same syntax as Python” part here seems like such a foot gun for everything from IDE integration to subtle bugs and more. I was super into the idea of a strict Python subset that gets JIT compiled inline based on just a decorator.
- zmgsabst 4y ago
  That exists: Library: https://numba.readthedocs.io/en/stable/ https://numba.readthedocs.io/en/stable/ CUDA: https://numba.readthedocs.io/en/stable/cuda/index.html https://numba.readthedocs.io/en/stable/cuda/index.html Example: https://numba.readthedocs.io/en/stable/cuda/examples.html https://numba.readthedocs.io/en/stable/cuda/examples.html
icefo 4y ago
I helped someone that had to use taichi code written by a PhD student and it was a bit weird. It looks a lot like python but you have to code like you would in cuda (e.g control flow), there is no magic. For this we had to calculate forces to animate some kind of polygon with a lot of joints and we could not just call sycipy from the taichi code. I had to implement a very dirty polynomial equation solver in taichi for the demo
dgacmu 4y ago
Out of curiosity, I rewrote their prime counter example to use a sieve instead of being a silly maximally-computation-dense example. To make it work with taichi, I had to change the declaration of the sieve from sieve = [0] * N to sieve = ti.field(ti.i8, shape=N) but the rest of the code remained the same. Ordinary Python: time elapsed: 0.444s Taichi ignoring compile time, I believe: time elapsed: 0.119s A slightly more realistic example than the 10x+ improvement they show on the really toy example with results that aren't too bad. I'd take a 3x improvement for tiny changes. Pretty neat! (I tried some other trivial things like using np.int8 and it was slower. One can obviously make this a ton faster but I was interested in seeing how the toy was if we just made it slightly more memory-bound). A negative was that throwing list comprehensions in made the python version faster - about 0.3 seconds - (and shorter and arguably more "pythonic") and simultaneously broke the port to taichi.
- bombolo 4y ago
  But how fast does it go with pypy and no changes to the code?
  - v3ss0n 4y ago
    Interested as well
    - anst 4y ago
      On my old Mac: Python=133.5 s, Numba=2.61 s (parallel prange in count_primes), Taichi=1.8 s. (on ti.cpu, but fails with metal).
- garyrob 4y ago
  Might be worthwhile to run the same code with an appropriate numba decorator. My guess is that you'd get at least as much speed up but without having to change the sieve declaration, but I'm not sure.
- deleted 4y ago
  [deleted]
- 4y ago
skyde 4y ago
If I need to use Python why should I use this instead of Jax

179 points by whereistimbo 4y ago

wow. i ran their prime number python accelerator example on 10 000 000 upper bound: (taichi) [X@X taichi]$ python primes.py [Taichi] version 1.4.1, llvm 15.0.4, commit e67c674e, linux, python 3.9.14 [Taichi] Starting on arch=x64 Number of primes: 664579 time elapsed: 93.54279175889678/s Number of primes: 664579 time elapsed: 0.5988388371188194/s

ipnon 4y ago
It seems like Taichi fast language, but it can also never be overstated how slow Python is on contemporary architectures.
- nerdponx 4y ago
  Right, I'd like to see a comparison to Nim or Julia, or another compiled high-level language that isn't particularly performance-oriented like Haskell or Clojure, or Common Lisp, or even Ruby with its new JIT(s). Or for that matter, Python with Numba or one of the other JIT implementations (PyPy, Pyston, Cinder).
- ActorNightly 4y ago
  It doesn't support 3.11 yet. 3.10 is slow compared to 3.11.
  - nxpnsv 4y ago
    yeah, but not on the level as the top level comment...
gus_massa 4y ago
Is that improvement caused because the program is automatically parallelized or because the code is compiled/JITed? A x150 improvement is too much, so I suspect both reasons collaborate to get it.
- inconceivable 4y ago
  they say the example i used is JIT compiled into machine code. i haven't looked into the codebase yet but i presume that means it just un-pythons it back into C? not sure. fwiw, i tried the gpu target (cuda) and it was faster than vanilla, but slower than accelerated cpu target by about 4x.
  - gus_massa 4y ago
    How does it compare with numba? (I don't know enough about the python ecosystem, but I have to tweak code from one of my coworkers and he uses numba.)
adgjlsfhk1 4y ago
And if you run it on a number bigger than 2^64, does it error because taichi automatically assumes python's BigInts are Int64s?

deleted 4y ago

[deleted]

calebm 4y ago

This looks amazing! (particularly for some of my interests - https://gods.art https://gods.art)

xiaodai 4y ago

Please don't retrofit more stuff to make python work. move over to julia already. u can call python from Julia

deleted 4y ago
[deleted]
packetlost 4y ago
I wouldn't consider Julia a replacement for Python
- Iwan-Zotow 4y ago
  and its an ugly thing they didn't get range composition right
  - xiaodai 4y ago
    care to elaborate
    - Iwan-Zotow 4y ago
      In C and Python (which inherited it from C, I believe) for(int k = 0; k != N; ++k) { dowork(k); }, similar in Python ranges are [0...N). If I want just a sum, and would like to split work among multiple CPUs, I could write s = sum(0...N) or s = sum(0...N/2) + sum(N/2...N) or s = sum(0...N/3) + sum(N/3...5N/7) + sum(5N/7...N) and it will work beautifully. Ranges are decomposable and composable with any number(s) splitting original range. [0...N/2) + [N/2...N) = [0...N) When I first looked at Julia, I was ... unhappy. They didn't get simple ranges composability right. You could do it, sure, but it looks so ... unnnatural.
  - packetlost 4y ago
    1 indexed arrays has me confused as hell
    - 4y ago

farcaster 4y ago

I was playing earlier today with Triton[0], from OpenAI. Like Taichi it makes it super easy to write native GPU code from Python, but it really does feel like something very experimental for now. (I know the use case is very different) [0] https://openai.com/research/triton https://openai.com/research/triton

coldtea 4y ago
>but it really does feel like something very experimental for now Meaning? - their approach is still bizarre and exploratory and they still don't know how to structure their APIs and are making it up as they go? or: - there are still some rough edges, bugs, and no full documentation yet? as those are quite different cases...
Archit3ch 4y ago
>CPUs and AMD GPUs are not supported at the moment CUDA-only, no mention of Metal.
- deleted 4y ago
  [deleted]
robertlagrant 4y ago
Triton is clearly a popular name for GPU access and inference[0]. [0] https://developer.nvidia.com/nvidia-triton-inference-server https://developer.nvidia.com/nvidia-triton-inference-server

sh1mmer 4y ago

> No barrier to entry for Python users: Taichi shares almost the same syntax as Python. Apply a single Taichi decorator, and your functions are automatically turned into optimized machine code. It looks super interesting except “almost the same syntax as Python” part here seems like such a foot gun for everything from IDE integration to subtle bugs and more. I was super into the idea of a strict Python subset that gets JIT compiled inline based on just a decorator.

zmgsabst 4y ago
That exists: Library: https://numba.readthedocs.io/en/stable/ https://numba.readthedocs.io/en/stable/ CUDA: https://numba.readthedocs.io/en/stable/cuda/index.html https://numba.readthedocs.io/en/stable/cuda/index.html Example: https://numba.readthedocs.io/en/stable/cuda/examples.html https://numba.readthedocs.io/en/stable/cuda/examples.html

icefo 4y ago

I helped someone that had to use taichi code written by a PhD student and it was a bit weird. It looks a lot like python but you have to code like you would in cuda (e.g control flow), there is no magic. For this we had to calculate forces to animate some kind of polygon with a lot of joints and we could not just call sycipy from the taichi code. I had to implement a very dirty polynomial equation solver in taichi for the demo

dgacmu 4y ago

Out of curiosity, I rewrote their prime counter example to use a sieve instead of being a silly maximally-computation-dense example. To make it work with taichi, I had to change the declaration of the sieve from sieve = [0] * N to sieve = ti.field(ti.i8, shape=N) but the rest of the code remained the same. Ordinary Python: time elapsed: 0.444s Taichi ignoring compile time, I believe: time elapsed: 0.119s A slightly more realistic example than the 10x+ improvement they show on the really toy example with results that aren't too bad. I'd take a 3x improvement for tiny changes. Pretty neat! (I tried some other trivial things like using np.int8 and it was slower. One can obviously make this a ton faster but I was interested in seeing how the toy was if we just made it slightly more memory-bound). A negative was that throwing list comprehensions in made the python version faster - about 0.3 seconds - (and shorter and arguably more "pythonic") and simultaneously broke the port to taichi.

bombolo 4y ago
But how fast does it go with pypy and no changes to the code?
- v3ss0n 4y ago
  Interested as well
  - anst 4y ago
    On my old Mac: Python=133.5 s, Numba=2.61 s (parallel prange in count_primes), Taichi=1.8 s. (on ti.cpu, but fails with metal).
garyrob 4y ago
Might be worthwhile to run the same code with an appropriate numba decorator. My guess is that you'd get at least as much speed up but without having to change the sieve declaration, but I'm not sure.
deleted 4y ago
[deleted]
4y ago

skyde 4y ago

If I need to use Python why should I use this instead of Jax