PyTorch 1.0 is out
github.com
github.com
A lot of things suck (closures, generator functions, first order functions all suck in c++), but oh my does it all run fast when you get it working; plus wrapping it with Rcpp or Lua is easy as pie.
Take this snippet of an API call[1] that parses ISO strings to chrono::time_point using date[2]:
std::istringstream in(iso_string);
in >> date::parse("%FT%TZ", tp);
The function is constructing a temporary object and reading into that object. The object includes a reference to a named tp object, and the temporary parser object is parsing from the input stream, which writes the data into the tp object.
> but... I still don't understand all of the technical reasons behind that decision.
Because he wants to support input from an istream, and inputting from a istream necessarily means overloading '>>'. That's just how things are done in C++; if you want to support reading from or writing to an istream/ostream, you overload the '>>' and '<<' operators.
It's a trade off; he could have designed it so that the constructor of tp simply accepts the format string and the istream as parameters. But that has the downside of not looking like idiomatic istream code.
I personally think that the way iostreams are implemented in C++ was a mistake. (because I don't like the way idiomatic istream looks, and I think friend functions are generally smelly.) Unfortunately, it's something like 35 years too late to correct it. (I'm aware that C++ is only 33 years old; iostream.h and cout << "blah" << endl; and cin >> foo; preexist C++) But here's the thing: it's badly designed iostreams that make the linked code confusing, not operator overloading.
I never grasped the hate iostreams get, as they are type safe and composable in ways that FILE will never be.
Sure they might be a couple of ms slower than stdio calls, but unless I would be writing a HPC trading application communicating over stdio, I hardly see the relevance.
And for the operators, oh well, as long as they are consistent.
Then again, it might just be my biased background as I got introduced to them.
a.) It was not a const overload. b.) Inside said overload, it modified FOUR member variables. c.) The 'new' keyword was used twice inside said == overload. d.) I learned when gdb fails, to grep the codebase for the 'operator' keyword.
I am not a fan of operator overloading. If the SW enginner in question had instead written a equals(<type> rhs) function, I'd have saved myself a lot of headache.
In the named case, it's obvious the other programmer may be doing something nefarious.
In the operator case, you learn much more, like how to grep, really work gdb, etc.
Same thing. Weird at first every C++ programmer should be familiar with it now.
I pronounce << and >> as 'goes to' and 'comes from' or something similar.
cin >> foo(x); $ cat test.cpp
#include <iostream>
#include <string>
template <typename F>
auto pass_func(F func) {
return func();
}
auto return_func() {
std::string test = "Hello World!";
return [=](){ return test; };
}
int main() {
auto func = return_func();
std::cout << pass_func(func) << std::endl;
}
$ clang test.cpp -lstdc++ -std=c++14 -o test
$ ./test
"Hello World!"
[disclosure: I work at FAIR]
This reduces barriers to use in addition to improving performance and portability.
"PyTorch is a Python package that provides two high-level features:
* Tensor computation (like NumPy) with strong GPU acceleration
* Deep neural networks built on a tape-based autograd system
You can reuse your favorite Python packages such as NumPy, SciPy and Cython to extend PyTorch when needed."
You might also look at CuPy [2], especially if you like NumPy.
[1] https://developer.nvidia.com/cublas [2] https://cupy.chainer.org/
- New JIT feature that lets you run your model without python. It now seems trivial to load a pytorch model in C++
- New distributed computation package. Major redesign.
- C++ frontend
- New torch hub feature to load models from github easily
Anyone want to start working on Golang bindings for C++ PyTorch?
[1]: http://www.swig.org/
PyTorch 1.0 takes the modular, production-oriented capabilities from Caffe2 and ONNX and combines them with PyTorch's existing flexible, research-focused design to provide a fast, seamless path from research prototyping to production deployment for a broad range of AI projects.
[0] https://developers.facebook.com/blog/post/2018/05/02/announc...
Edit: fixed links should be going live in a few mins, via: https://github.com/pytorch/pytorch.github.io/pull/141
Isn't python bytecode simple enough that it can be run anywhere?
[1] see https://github.com/nedbat/byterun for a Python implementation
The point here is to run PyTorch code without having a Python interpreter, and without having to run slow Python code.