Could this work my needs? Some questions on SIMD, AOT...

[warvstar]

Hi! Currently I'm working on a data orientated game engine that is programmed via Javascript and the kernels are SPIRV(glsl), much like how Taichi uses python and itself(Taichi).

Now the reason I'm here is because I've just found out that this project is already doing most of the things I would need for my backend. However before switching over to Taichi I'd like to ask some questions I haven't found answered yet.

I need something to run on Windows, Mac, Linux, Android, iOS and the web. I'm pretty sure the first three can be accomplished now, I imagine Android is probably pretty easy too. I should have no problem making this run in the browser as I have tons of experience with that.

My main concern is iOS. Currently with my own system I JIT everything during development and then for release I compile AOT and that solves iOS for my needs currently. I haven't looked at the codebase here much yet, but does Taichi have a way to AOT compile kernels or modules? How much work do you think would be involved?

Also, another reason I'd like to see AOT compilation is to keep the binary size of the release program down.

My other question is about SIMD/Vectorization on the CPU. With my current system I compile SPIR-V to ISPC at release, and that gets me vectorization. Anyway, I noticed Taichi had vectorization at one time but then lost it? Has it been added back in? Can it compete with ISPC generated code?

Would this project not benefit from having a SPIR-V backend?

Also, as much as I like python, would anyone be interested in an optional JavaScript front end? I ask because if porting to the web, python is another dependency that could be removed if using JavaScript instead.

By the way, this is an awesome project! Thanks for all the work put into Taichi!

[xumingkuan]

Thank you so much for proposing this!

Some quick answers:

Does Taichi have a way to AOT compile kernels or modules?

Not yet, because Taichi is embedded in Python now.

I noticed Taichi had vectorization at one time but then lost it? Has it been added back in?

Yes, Taichi had vectorization at one time and it ran pretty fast. Because we added bunches of features and did aggressive refactoring, Taichi lost vectorization. Vectorization is a great feature and can make Taichi run much faster on CPUs, so it would be of great help if it's added back. However, as #677 addressed, it's unlikely to achieve in v0.7 because of the workload.

[yuanming-hu]

Thanks for the questions.

I haven't looked at the codebase here much yet, but does Taichi have a way to AOT compile kernels or modules? How much work do you think would be involved?

Our existing workflow is simply dumping the generated Metal kernels, and write an iOS app to launch these kernels. However we plan to switch to a runtime system so that you can ship with a libtaichi_core.dylib with some IR for JITing. I don't that will be done very soon.

My other question is about SIMD/Vectorization on the CPU. With my current system I compile SPIR-V to ISPC at release, and that gets me vectorization. Anyway, I noticed Taichi had vectorization at one time but then lost it? Has it been added back in? Can it compete with ISPC generated code?

Yeah we used to have vectorization for the old C++ backend, but after we switch to LLVM vectorization hasn't been implemented for the new backend.

Would this project not benefit from having a SPIR-V backend?

Yes, SPIR-V would be really helpful, but the development hasn't started.

Also, as much as I like python, would anyone be interested in an optional JavaScript front end? I ask because if porting to the web, python is another dependency that could be removed if using JavaScript instead.

We plan to add JS/WASM backends, but we haven't started the development: #394

[cloudhan]

This seems to be interesting.

Regards with ISPC, it is extremely performant based on my experience. It can produce object file and then link with other obj to make libraries or executables, this makes it suitable for gradually accelerate existing code. IMO, to be as flexible as ISPC is, taichi need to be able generate kernel code (compiled or not) without the runtime at all, and let the programmer to manage memory and kernel launch.

[archibate]

Also, as much as I like python, would anyone be interested in an optional JavaScript front end? I ask because if porting to the web, python is another dependency that could be removed if using JavaScript instead.

We plan to add JS/WASM backends, but we haven't started the development: #394

FYI now the C backend is almost complete #1332, and we are able to export the result C code now. We will have a JS backend once we translate the generated C code into JS via Emscripten. But note that this is simply running pure JS running on CPU, no WebGL acceleration, so no much performance will be expected yet.

Yes, currently the Taichi compiler is highly tied with runtime, therefore cross-compile could be hard. For example, the OpenGL backend assumes all extensions on compiler-side to be available on runtime-side.

[bobcao3]

Metal AOT module is up and running rn, closing the issue