Tile language vs EDSL about plaidml HOT 10 OPEN

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!

from plaidml.

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?

from plaidml.

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.

from plaidml.

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?

from plaidml.

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.

from plaidml.

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

from plaidml.

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.

from plaidml.

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).

from plaidml.

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?

from plaidml.

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.

from plaidml.