ozinenko

6 ms·

1.
by ozinenko 2y ago
I'd be interested to learn about such closed-source important bits and invite them to MLIR workshop / open developer meeting. Having worked on the project essentially since its inception, I am quite positive that the bits the orig
2.
by ozinenko 2y ago
MLIR maintainer here, or however close one can be given that we don't have a clear ownership structure. This has been discussed repeatedly in the community, and it is likely that many things will get eventually ported/reimplemente
3.
by ozinenko 3y ago
There are very few reasons for a landlord to prematurely terminate the lease in France, and deciding to lent it for more money is specifically not one of them. In winter, you can't evict anyone at all (making money from ski town rent
4.
by ozinenko 3y ago
@chrislattner out of curiosity, can you share on which CPU the numbers in https://docs.modular.com/mojo/notebooks/Matmul.html are obtained and/or the fraction of peak performance on that machine? Speedups ove
5.
by ozinenko 4y ago
Engage with some open-source compiler community or, better, find a way to contribute and then the job will find you. Note, however, that even if you wanted to pursue a purely academic compiler research career, it is highly unlikely that you
6.
by ozinenko 7y ago
Cool, I've seen the PLDI talk a couple of years ago! Would you mind describing your potential use case on https://llvm.discourse.group/c/llvm-project/mlir , there may be more people who are able to help or hav
7.
by ozinenko 7y ago
(Early disclaimer: I am an author of the paper and of MLIR, but this is a personal opinion) I am somehow surprised by the reaction but at the same time I expected as much. We chose to make MLIR open-source early in the design and developmen
8.
by ozinenko 7y ago
It will be as good as the sum of work put into it by the people in the ecosystem. That is the reason why MLIR was open-sourced very early in the development process, instead of thrown over the fence after being driven to completion by Googl
9.
Tensor Comprehensions in PyTorch(pytorch.org)
14 points by ozinenko 9y ago|0 comments
10.
by ozinenko 9y ago
Tensor Comprehensions is mostly targeted at arithmetics operations that appear in DL workloads, and the notation strives to be usable for DL experts. Polyhedral optimizer is oriented towards imperative languages, so we won't end up do
11.
by ozinenko 9y ago
Tensor Comprehensions does not try to own memory allocation and CPU/GPU transfers. ATen is one simple way of getting that, which we used for tests. Anything convertible to DLPack tensors should work as long as nothing fancy happens w
12.
by ozinenko 9y ago
Sure, it is one of the works we cite. It seems to be mostly targeted at sparse computations and does not have GPU support. Tensor Comprehensions does not try to manage memory and thus can be integrated into DL frameworks easily.
13.
by ozinenko 9y ago
Section 7 of the paper ( https://arxiv.org/abs/1802.04730 ) has a couple of examples. In short, yes CuDNN is fast for the cases it was tuned for . It is probably faster on power-of-two sizes, but when you operate on a
14.
by ozinenko 9y ago
The paper has a couple of useful references. Otherwise, we have a site with general information on polyhedral compilation http://polyhedral.info/ and Halide has its own site http://halide-lang.org/
15.
by ozinenko 9y ago
The crucial part is the polyhedral optimizer which does indeed include several GPU-specific heuristics (multilevel parallelization, coalescing, etc) and specialization to tensor sizes. Evolutionary autotuner is used to tweak the parameters