4 ms·

Obviously you're entitled to your opinion, but I think it's completely wrong. (Note: I don't work for Google, or know anyone on the MLIR team.) Take a look at

Obviously you're entitled to your opinion, but I think it's completely wrong. (Note: I don't work for Google, or know anyone on the MLIR team.) Take a look at this recent talk by the people behind IREE[0] (who are not part of the MLIR team): https://drive.google.com/file/d/1os9FaPodPI59uj7JJI3aXnTzkuttuVkR/view https://drive.google.com/file/d/1os9FaPodPI59uj7JJI3aXnTzkut... In a nutshell, they have made HUGE gains by taking advantage of the MLIR infrastructure for a use case not anticipated by the MLIR authors (i.e. making the TensorFlow-to-hardware path easier to develop). In my opinion, MLIR is going to be much more successful long-term than LLVM is today, and by long-term, I mean "in the next few years." The number of teams consolidating already around MLIR is astounding, and having a multi-dialect SSA-based IR is a freaking game changer for compiler writers. [0] https://github.com/google/iree https://github.com/google/iree

hu3 7y ago
Thanks for the video. I'd like to highlight minute 46 when they praise IMLR and explain how it enabled them to accomplish feats that were either too hard or impossible before.
wyldfire 7y ago
Does IREE compete with TVM? I think it has a backend used for designing hardware.
- Joky 7y ago
  As far as I understand, it is entirely different: IREE is a runtime system.
m0zg 7y ago
I don't see how it _can_ improve anything by anywhere near the claimed amounts. Most practical work is basically dot product, which has been so heavily hand-optimized (and then some - via Fourier/Winograd for convolutions), there's no blood to squeeze out from that particular stone. Kernels of this quality can not be arrived at by the compiler - a competent human always beats the compiler when she has to. As a result, your optimization efforts will necessarily have to improve things elsewhere, where a competently written deep learning framework spends single digit percentages of its inference time. As a result of that, in turn, the best you can really hope for is single digit percentage gains, barring some exotic architecture which doesn't consist almost entirely of dot products or some degenerate cases where hand-coded convolution and dot product kernels suck, which are, by definition, uncommon. I mean it's great to have this - a rigorous, testable, theoretically grounded approach to execution graph manipulation is a hard thing to achieve for something as general as this, and everyone will benefit from not rolling everything from scratch every time, but let's be realistic here - this is not going to "fix" Moore's law or anything like that.
atq2119 7y ago
The sad thing is that there is so much NIH around MLIR. The infrastructure investments in LLVM are massive, but now lots of people are rushing off to reinvent the world rather than bringing the ideas to LLVM itself.
- auggierose 7y ago
  Whatever it is, can't be NIH given that Chris Lattner invented LLVM ...
  - atq2119 7y ago
    Then call it reinventing the wheel. It still deserves to be weighed properly against the alternatives.
- adwn 7y ago
  Modifying/extending LLVM is very hard to infeasible when the problem is with the fundamental architectural design. For example, according to the MLIR project, parallel compilation of a compile unit is basically not possible with LLVM.
  - atq2119 7y ago
    They refer mostly to how globals and constants maintain use lists as linked lists, which is indeed a nightmare for synchronization. And yes, fixing that would require some difficult surgery. But let's be honest about what is more work: refactoring that, or rewriting all users of LLVM out there. My bet is on the first one being cheaper by at least three orders of magnitude.
    - detaro 7y ago
      Experimentation in something easier to change than LLVM to make sure they know what exactly they want to do to LLVM later?
- wolfgke 7y ago
  > The sad thing is that there is so much NIH around MLIR. The infrastructure investments in LLVM are massive, but now lots of people are rushing off to reinvent the world rather than bringing the ideas to LLVM itself. What if your idea is completely opposite to LLVM's goals? For example, you want a very small (e.g. in the sense of LOC) compiler?

hu3 7y ago

Thanks for the video. I'd like to highlight minute 46 when they praise IMLR and explain how it enabled them to accomplish feats that were either too hard or impossible before.

wyldfire 7y ago

Does IREE compete with TVM? I think it has a backend used for designing hardware.

Joky 7y ago
As far as I understand, it is entirely different: IREE is a runtime system.

m0zg 7y ago

I don't see how it _can_ improve anything by anywhere near the claimed amounts. Most practical work is basically dot product, which has been so heavily hand-optimized (and then some - via Fourier/Winograd for convolutions), there's no blood to squeeze out from that particular stone. Kernels of this quality can not be arrived at by the compiler - a competent human always beats the compiler when she has to. As a result, your optimization efforts will necessarily have to improve things elsewhere, where a competently written deep learning framework spends single digit percentages of its inference time. As a result of that, in turn, the best you can really hope for is single digit percentage gains, barring some exotic architecture which doesn't consist almost entirely of dot products or some degenerate cases where hand-coded convolution and dot product kernels suck, which are, by definition, uncommon. I mean it's great to have this - a rigorous, testable, theoretically grounded approach to execution graph manipulation is a hard thing to achieve for something as general as this, and everyone will benefit from not rolling everything from scratch every time, but let's be realistic here - this is not going to "fix" Moore's law or anything like that.

atq2119 7y ago

The sad thing is that there is so much NIH around MLIR. The infrastructure investments in LLVM are massive, but now lots of people are rushing off to reinvent the world rather than bringing the ideas to LLVM itself.

auggierose 7y ago
Whatever it is, can't be NIH given that Chris Lattner invented LLVM ...
- atq2119 7y ago
  Then call it reinventing the wheel. It still deserves to be weighed properly against the alternatives.
adwn 7y ago
Modifying/extending LLVM is very hard to infeasible when the problem is with the fundamental architectural design. For example, according to the MLIR project, parallel compilation of a compile unit is basically not possible with LLVM.
- atq2119 7y ago
  They refer mostly to how globals and constants maintain use lists as linked lists, which is indeed a nightmare for synchronization. And yes, fixing that would require some difficult surgery. But let's be honest about what is more work: refactoring that, or rewriting all users of LLVM out there. My bet is on the first one being cheaper by at least three orders of magnitude.
  - detaro 7y ago
    Experimentation in something easier to change than LLVM to make sure they know what exactly they want to do to LLVM later?
wolfgke 7y ago
> The sad thing is that there is so much NIH around MLIR. The infrastructure investments in LLVM are massive, but now lots of people are rushing off to reinvent the world rather than bringing the ideas to LLVM itself. What if your idea is completely opposite to LLVM's goals? For example, you want a very small (e.g. in the sense of LOC) compiler?