[anonymoushn]

> So, over the years, I absorbed and appreciated that Torch was a user-centric product, which stood for immediate-mode, easy-to-debug, stay-out-of-the-way explicitness. It was targeted at people somewhat familiar with programming matters, and who could reason about things like performance, and if needed, write a C function and bind it in quickly.

This paragraph sort of surprises me. In my experience if you want to do anything other than calling out to numeric libraries, you can do it in Lua and it will work, or you can do it in Python and suddenly your machine learning pipeline will spend 95% of its time running Python while your GPU idles. So the need to be able to drop down to C is much more severe in Python, and the difficulty of calling out to C is much greater.

[smhx]

Whether using Lua or Python, for GPU-based scientific computing, the need to drop into a C call is the same. The overhead of Python vs Lua never really mattered.

While we were based on top of LuaJIT, we couldn't use the JIT for anything because we had to always call into the C library for GPU kernels (and LuaJIT can't JIT through an opaque C call, incase that C call changes the interpreter stack).

Where Python really helps is with its ecosystem. The entire data science and ML ecosystem is in Python.

The difficulty of calling out to C is not much greater in Python, things like PyBind11 make it pretty natural.

[anonymoushn]

People don't usually write the rules of a game or a MCTS to run on the GPU. They write it in Python, Lua, or C. If they write it in Python, then the GPU will idle all the time. If they write it in Lua or C then it will not.

[dklend122]

In Julia it's easy to run the entire thing on CUDA: https://github.com/fabricerosay/AlphaGPU

No C or any other language required because Julia has GPU codegen.

You can also keep MCTS on the CPU and be competitive with cpp despite the code being higher level, easier to read and more generic and composable. See: https://github.com/jonathan-laurent/AlphaZero.jl