8 ms·

What surprised me most is the elegance of C++ API. Compared to its equivalence in Python, the C++ version is almost the same if we discard the "auto" keyword [0

by htfy96 8y ago

What surprised me most is the elegance of C++ API. Compared to its equivalence in Python, the C++ version is almost the same if we discard the "auto" keyword [0]. As mentioned in the doc, they put user-friendliness over micro-optimizations, which also proves the expressiveness of modern C++ (at least when they want to prioritize user-friendliness!) [0]: https://pytorch.org/cppdocs/frontend.html#end-to-end-example https://pytorch.org/cppdocs/frontend.html#end-to-end-example

perturbation 8y ago
I'm hoping that this results in a nice, high-level API for https://github.com/fragcolor-xyz/nimtorch https://github.com/fragcolor-xyz/nimtorch as well, which AFAIK has been wrapping the low-level Aten API. I've been keeping my eye on that project, and been really excited about it.
- nerdponx 8y ago
  Likewise, I hope this leads to a nice wrapper API for Julia.
  - byt143 8y ago
    Sure, but Julia doesn't need it: https://julialang.org/blog/2018/12/ml-language-compiler https://julialang.org/blog/2018/12/ml-language-compiler
usgroup 8y ago
i picked up c++ for some gpu stuff with the arrayfire api... felt the same. firstly, modern c++ takes no time to learn if you come from java / c/ c# / etc. secondly, things like operator overloading and type inference make for pretty seamless apis. E.g. want to add matrices? auto C = A + B. 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.
- umvi 8y ago
  I'm not sure how I feel about operator overloading. It starts out simple enough, but can lead to extremely confusing code. 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); At first glace my brain cannot comprehend the second statement. Why is there an input stream going into a function? Is that even valid C++? Why not just pass `in` as a function parameter and return time_point as the return value?? When you actually dig into the source, it's a namespace overloaded operator and it's extremely heavily templated to be generic. So now if I think of `>>` as simply a second function call using the result of `date::parse` it makes sense, but... I still don't understand all of the technical reasons behind that decision. I assume they're valid reasons though since Howard Hinnant is the c++ datetime expert. [1] https://stackoverflow.com/a/33438989/2516916 https://stackoverflow.com/a/33438989/2516916 [2] https://github.com/HowardHinnant/date https://github.com/HowardHinnant/date
  - nwallin 8y ago
    > Why is there an input stream going into a function? 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.
modeless 8y ago
Wow, this is cool. How complete is the API? Could you use it for research? Last I checked, the TensorFlow C++ API was missing all sorts of important stuff for building models and was basically only useful for loading models saved from Python.
- jgehring 8y ago
  Yes! The API feels very much like using PyTorch from Python, and implementing models and working with tensors purely in C++ is very convenient. We're using it for our research platform for StarCraft: Brood War (https://torchcraft.github.io/TorchCraftAI https://torchcraft.github.io/TorchCraftAI). [disclosure: I work at FAIR]
- goldsborough 8y ago
  It's very complete. We have many kinds of builtin Modules (rnns, conv{1,2,3}d, batchnorm etc.), optimizers, a data loader, a serialization format for checkpointing and similar things you need for training. My hope is that any model you can train in Python you can now also train in C++.
snippyhollow 8y ago
Quite usable, all of TorchCraftAI uses it https://torchcraft.github.io/TorchCraftAI/ https://torchcraft.github.io/TorchCraftAI/ :)
thosakwe 8y ago
Wow, that’s actually really awesome. I really missed a good languages-other-than-Python story in Tensorflow. Now I feel a little inspired to try out ML again...
- stochastic_monk 8y ago
  I’m really excited to use it in C++. When it’s in Python, it becomes much harder to embed into other programs and is susceptible to Python version issues when sharing code. This reduces barriers to use in addition to improving performance and portability.
  - stochastic_monk 8y ago
    I’m also excited that Caffe got merged in because it has nearly perfect GPU-scaling via MPI, whereas tf suffers (or did, when [0] came out) with more GPUs. [0] https://arxiv.org/pdf/1711.05979 https://arxiv.org/pdf/1711.05979
MarvelousWololo 8y ago
So cool to see people saying good things about C++ and I've never had the chance to take a uni course on computer science but I've always wanted to the GUI stuff with C and C++. Maybe I should try again. Thanks OP. :)

by htfy96 8y ago

perturbation 8y ago

I'm hoping that this results in a nice, high-level API for https://github.com/fragcolor-xyz/nimtorch https://github.com/fragcolor-xyz/nimtorch as well, which AFAIK has been wrapping the low-level Aten API. I've been keeping my eye on that project, and been really excited about it.

nerdponx 8y ago
Likewise, I hope this leads to a nice wrapper API for Julia.
- byt143 8y ago
  Sure, but Julia doesn't need it: https://julialang.org/blog/2018/12/ml-language-compiler https://julialang.org/blog/2018/12/ml-language-compiler

usgroup 8y ago

i picked up c++ for some gpu stuff with the arrayfire api... felt the same. firstly, modern c++ takes no time to learn if you come from java / c/ c# / etc. secondly, things like operator overloading and type inference make for pretty seamless apis. E.g. want to add matrices? auto C = A + B. 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.

umvi 8y ago
I'm not sure how I feel about operator overloading. It starts out simple enough, but can lead to extremely confusing code. 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); At first glace my brain cannot comprehend the second statement. Why is there an input stream going into a function? Is that even valid C++? Why not just pass `in` as a function parameter and return time_point as the return value?? When you actually dig into the source, it's a namespace overloaded operator and it's extremely heavily templated to be generic. So now if I think of `>>` as simply a second function call using the result of `date::parse` it makes sense, but... I still don't understand all of the technical reasons behind that decision. I assume they're valid reasons though since Howard Hinnant is the c++ datetime expert. [1] https://stackoverflow.com/a/33438989/2516916 https://stackoverflow.com/a/33438989/2516916 [2] https://github.com/HowardHinnant/date https://github.com/HowardHinnant/date
- nwallin 8y ago
  > Why is there an input stream going into a function? 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.

modeless 8y ago

Wow, this is cool. How complete is the API? Could you use it for research? Last I checked, the TensorFlow C++ API was missing all sorts of important stuff for building models and was basically only useful for loading models saved from Python.

jgehring 8y ago
Yes! The API feels very much like using PyTorch from Python, and implementing models and working with tensors purely in C++ is very convenient. We're using it for our research platform for StarCraft: Brood War (https://torchcraft.github.io/TorchCraftAI https://torchcraft.github.io/TorchCraftAI). [disclosure: I work at FAIR]
goldsborough 8y ago
It's very complete. We have many kinds of builtin Modules (rnns, conv{1,2,3}d, batchnorm etc.), optimizers, a data loader, a serialization format for checkpointing and similar things you need for training. My hope is that any model you can train in Python you can now also train in C++.

snippyhollow 8y ago

Quite usable, all of TorchCraftAI uses it https://torchcraft.github.io/TorchCraftAI/ https://torchcraft.github.io/TorchCraftAI/ :)

thosakwe 8y ago

Wow, that’s actually really awesome. I really missed a good languages-other-than-Python story in Tensorflow. Now I feel a little inspired to try out ML again...

stochastic_monk 8y ago
I’m really excited to use it in C++. When it’s in Python, it becomes much harder to embed into other programs and is susceptible to Python version issues when sharing code. This reduces barriers to use in addition to improving performance and portability.
- stochastic_monk 8y ago
  I’m also excited that Caffe got merged in because it has nearly perfect GPU-scaling via MPI, whereas tf suffers (or did, when [0] came out) with more GPUs. [0] https://arxiv.org/pdf/1711.05979 https://arxiv.org/pdf/1711.05979

MarvelousWololo 8y ago

So cool to see people saying good things about C++ and I've never had the chance to take a uni course on computer science but I've always wanted to the GUI stuff with C and C++. Maybe I should try again. Thanks OP. :)