Tile language vs EDSL

[gyenesvi]

In the last publicly available version (0.7.0) of PlaidML the Tile language was used to write operators. The latest documentation talks about a C++/Python EDSL being developed as well, however, documentation there is a bit lacking, and only C++ is presented, not any Python version. I was wondering whether that is meant to substitute the Tile language or will both of them be kept in the future? I used to have some test project built using the Tile language from Python, which used to work well for me, and I'd like to improve that, but was wondering if I should port it to the EDSL approach, or is it okay to stay with the Tile language approach.

Also, I was wondering if the v1 branch still supports the Tile language, and will it continue to do so when it is finally released? If I take the path of compiling it from source, and use that instead of the pip installable v0.7, will my project that uses it break or continue working?

Is there any idea of a time-line for the next public release? I have been following this promising project for a while, hoping that a new release will come sooner or later.

[hfp]

Hi Viktor,

there is no active development of PlaidML anymore. Though, there was some recent work to polish the v1 branch and some repository mechanics. For instance, we refreshed the recipe and configuration scripts (requirements, etc.), and "ported" the code base to build with more recent GNU C/C++ Compilers (still no Clang compiler supported to build PlaidML), and we also ported the code base to work on ARM64 CPUs as well (and related Python environment, etc.).

Our research now focuses on some of the critical items you raised in your question (thank you for asking!). Also, the lack of documentation of our (changed) focus is attributed to "focus" rather than "no development", i.e., we desire to have documentation or presentations available at some point. Though, there is significant shift in focus and less about getting external users started with any of the new development at the moment. Our work centered around our Tensor Processing Primitives (TPP) and upstreaming related work.

If the background of question was not from a user perspective ("want to see what PlaidML can do for me"), feel free to follow up further!

[gyenesvi]

Hi Hans,

Thanks for the response. I am a bit confused though, when you say there's no active development, though there is ongoing research with shifted focus. So is it the goal that the potential results of that research will make it to a new version a PlaidML in the future? In particular, the docs in this repo mention that integration to MLIR is on the way. Has that development stalled, or is that still ongoing and will eventually take place if all goes well?

As for the background of the question, what I'd like to understand is whether it is a good idea to build on PlaidML as a compiler for various backends, will it be supported and improved in the future? And if yes, whether relying on the Tile language as a frontend is still valid, or will only the (C++) EDSL approach be supported in the future?

[hfp]

So is it the goal that the potential results of that research will make it to a new version a PlaidML in the future?

Likely, we will release something that demonstrates what we integrated upstream. Going further, it could be a something that other frameworks want to integrate. It is unlikely called PlaidML, and it has no common code-base with PlaidML or can be called a successor. PlaidML development stopped. See the next answer regarding MLIR.

In particular, the docs in this repository mention that integration to MLIR is on the way.

It is our sole focus now to work on MLIR, but this is separate from PlaidML. We continue using PlaidML v1 as a baseline for comparison; not more - not less.

Has that development stalled, or is that still ongoing and will eventually take place if all goes well?

See above answers. Do not hesitate to ask further questions if something remains unclear.

[gyenesvi]

Thanks for the clarifications! One thing about the MLIR work. Is that planned to be materialized in some concrete compiler that uses MLIR? Because as far as I understand, MLIR is a conceptual framework, which is being implemented in many actual compilers. So in which one can your work be expected to be integrated?

[hfp]

Is that planned to be materialized in some concrete compiler that uses MLIR?

I think so, but our work is in pathfinding/early phase (research); it's too early to callout something.

Because as far as I understand, MLIR is a conceptual framework, which is being implemented in many actual compilers.

Yes, frameworks that can benefit or want JIT compilation (domain specific code). The term "compiler" can be confusing if one expects classic offline compilation of a language like C.

[gyenesvi]

Ok, I get it, thanks! So there's no point in building anything on top of PlaidML for now.

[hfp]

Ok, I get it, thanks! So there's no point in building anything on top of PlaidML for now.

Depends on what you want to achieve. For example, we exercise PlaidML's CPU based code-paths for ARM and x86 architecture running full topologies for performance and correctness (v1 branch). So, PlaidML can be useful. If you however think of an own framework on top or plumbing an engine and a framework, it is perhaps less sensible to get into PlaidML's API. A product quality low-level infrastructure and API might be Intel's oneDNN. It's fairly portable too. However, the latter is not Python based in the first place.

[hfp]

If of interest, you can be involved/contributing to our ideas. This is by no means taking "something" and using it in production, but rather contributing, experimenting, etc.. MLIR and Tensor Processing Primitives (TPPs) are the ingredients we look at. We want our TPPs (specification ongoing) to be "mapped to MLIR". We already have a concrete implementation of TPPs (LIBXSMM).

[gyenesvi]

Well indeed PlaidML could be useful for those architectures for our purposes too (we would like to implement a sample runtime for CPU/GPU to execute NNEF models), but the v1 branch is not published, right? If I do pip install plaidml I cannot get it, only v0.7. So we cannot distribute NNEF python tools that build on plaidml python package. Furthermore, there's no active development or even proper documentation, so if we find bugs or request minor features, they are not going to get fixed over time as I understand.

MLIR is something we are also looking at, for mapping NNEF to MLIR's existing dialects. Would TPPs mapped to MLIR technically mean a new MLIR dialect?

[hfp]

Well indeed PlaidML could be useful for those architectures for our purposes too (we would like to implement a sample runtime for CPU/GPU to execute NNEF models), but the v1 branch is not published, right? If I do pip install plaidml I cannot get it, only v0.7. So we cannot distribute NNEF python tools that build on plaidml python package. Furthermore, there's no active development or even proper documentation, so if we find bugs or request minor features, they are not going to get fixed over time as I understand.

Yes, this describes it reasonably. Our ongoing work is quite active/agile but it is fair to not recommend it for production. Though, our priorities are CPU and GPU as well.

MLIR is something we are also looking at, for mapping NNEF to MLIR's existing dialects. Would TPPs mapped to MLIR technically mean a new MLIR dialect?

I think it is a design point of MLIR to have dialects. However, we aim to cover our vision with upstream as a priority, and to avoid orphaned work. TPP is somewhat bottom up since we already have a comprehensive Ninja implementation with an own spec rather than just an initial dialect. There is a TPP dialect ramping. However, there is no duplication intended (e.g., vs Linalg) and focus is on lowering to TPP.