Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tensor Comprehensions

research.fb.com

Post reply on HN
Print view View original

61–64 of 64 posts

Re: Tensor Comprehensions

#61

Post by pathsjs »

ozinenko wrote: post #59
pathsjs wrote: post #58

I could not find how to integrate this into a C++ program. Does it need ATen or is there a lower level of integration? Is there even the possibility of getting C bindings?

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 with tensor shapes. C bindings don't seem to be a priority. Feel free to use the contacts provided in the documentation here: https://facebookresearch.github.io/TensorComprehensions/cont..…

It makes sense to let client code handle allocations and whatnot. What I cannot find is how to pass one or more tensors (given, I suppose, by some shape parameters and a pointer to the data buffer) to Tensor Comprehensions.

I would have expected that operations expressed in the tensor language could be compiled once and for all (for a given target) into a DLL, and then it would be just a matter of passing the right buffer and shape parameters to a function. I see no reason why this should not be easily handled in C (which makes it easier to bind it from most languages).

If I understand correctly, DLPack is the format of choice to express a tensor, and ATen is not required, but I cannot find examples using DLPack

Re: Tensor Comprehensions

#62

Post by hueving »

username223 wrote: post #53
hueving wrote: post #42

Earlier quoted context omitted.

A shining example of the Dunning–Kruger effect. Scientific code is some of the worst-engineered code you'll ever deal with because it's written by people that are great at physics but terrible at software engineering. It will be poorly documented, have single letter var names everywhere without comments, have a bunch of hidden dependencies on whatever the postdoc had installed on his/her laptop, leak memory but 'term…

Sure, the code is usually pretty ugly, but it also tends to work. The people who write it view software as just another tool, so they care more about working than looking pretty. > Oh, and there will almost never be even a single regression test. Bullshit. "Codes" tend to be run against analytical and/or experimental results.

It's not about looking pretty. It's about being composable, extendable, testable, and portable to other languages and architectures.

The fact that you think looking pretty has anything to do with sound software engineering further illustrates my point.

>Bullshit. "Codes" tend to be run against analytical and/or experimental results.

A README that says the author ran it against dataset Y and got X is not a regression test. I'm talking about automated tests run on every proposed patch to ensure the thing is never broken. Real automated tests that cover 90%+ of branches are about as rare as unicorns in scientific computing (much to my annoyance).

Don't get me wrong, I completely understand why people running experiments skip testing (fast iteration). But that leads to the very opposite of "higher standards".

Re: Tensor Comprehensions

#63

Post by fredrikbk »

ozinenko wrote: post #49
cgmg wrote: post #41

Related: http://tensor-compiler.org/codegen.html . This converts an expression in tensor index notation into executable code.

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.

That is correct (and we appreciate the citation). The tensor compiler (taco) has focused on compiling expressions that contain one or more sparse tensors so far and, even though it can generate code for dense expressions just fine, does not optimize these like TC, TCE, and XLA does. We are working on a scheduling language for it so that it will perform well across all types of formats and on GPUs.

Re: Tensor Comprehensions

#64

Post by aray »

richardlethin wrote: post #55
phaedrus wrote: post #22

This web page is also the first I've heard of Halide and Polyhedral Compilation. This is exciting to me because I've been working on relational (database) data and logic comprehensions, and in a case of convergent evolution Halide looks a lot like my notation and Polyhedral Compilation looks much like diagrams I've been drawing on my whiteboard. Where can I learn more on this?

The R-Stream Encyclopedia article talks about how to raise to the polyhedral model from SSA; this is no problem especially for the super regular computations in Tensor computations used in deep learning. If you get in touch with me I can also get you a copy of the 2008 paper about R-Stream that described it: https://www.reservoir.com/publication/final-report-r-stream-... By raising from C you don't need to use or lea…

Is this paper published yet? The `Article` link doesn't go anywhere, and Google Scholar doesn't know where to find a copy.
Post reply on HN