Re: Meeting / C-API

[Bairen YI]

Copy to folks in SIG Build and Networking. 

What is the recommended approach to distribute add-ons building on top of C API? Do users need to install a TF C library, or they just need the regular Python package?

Best,

Bairen

On May 21, 2019, at 5:46 PM, Bairen YI <b...@connect.ust.hk> wrote:

tf.load_library or tf.load_op_library is what most add-ons do today. They tend to create ABI incompatibility problems though. The central point of making everything depending on C API only is to avoid this kind of issue.

See https://github.com/tensorflow/tensorflow/issues/27067 for details.

Bairen

On May 21, 2019, at 5:42 PM, Jeroen Bédorf <jer...@minds.ai> wrote:

Good point! I was wondering the same thing but forgot to add it to my questions list :|

I was guessing there would be some Python command we had to use to load the plugin, but I did not see it mentioned anywhere.

Cheers,

Jeroen

On Tue, May 21, 2019 at 11:34 AM Bairen YI <b...@connect.ust.hk> wrote:

Thanks!

One thing that might worth discussing is how our users are supposed to use these plugins. The C API is not available in TF Python packages right now. Do we will get to use tf.load_library as all the add-ons do today? We could create Python package wrapper for the plugins if so.

I doubt it as the Python code in TF does not use the C API directly, unlike other language bindings. But I need to give it a shot first.

Best,
Bairen

> On May 21, 2019, at 4:54 PM, Jeroen Bédorf <jer...@minds.ai> wrote:
>
> Hi Bairen,
>
> During the meeting later today I will driving so it might be hard for me to speak up on certain moments, but I'll be able to listen in for sure. I did some tests with the C API and it looks quite promising and pretty complete, at least with respect to the verbs implementation on which it is based.
>
> Below some notes, that might be useful during the meeting if the topic comes up.
>
> I did some basic tests for the API:
> - Build and ran the tests in the experimental folder, all worked
> - Included the header file into the verbs plugin, adjusted the BUILD file and compiled the whole stack. Worked
> - Questions:
>   * Which parts of the C++ API can we still assume to be accessible. As right now a lot of functionality and data-structs are inherited and used inside the existing plugins. For porting it makes it easier to remove/disable all header files that will no longer be accessible such that it becomes clear what can and what can't be used and has to be recreated inside the plugins themselves.
>
> Cheers,
> Jeroen 
>   
>   
>

[Bairen YI]

+SIG Build

--
You received this message because you are subscribed to the Google Groups "SIG Networking" group.
To unsubscribe from this group and stop receiving emails from it, send an email to networking+...@tensorflow.org.
Visit this group at https://groups.google.com/a/tensorflow.org/group/networking/.

[Bairen YI]

Copy to folks in SIG Build and Networking. 

What is the recommended approach to distribute add-ons building on top of C API? Do users need to install a TF C library, or they just need the regular TF Python package?

[Bairen YI]

[Anna Revinskaya]

Sorry for missing the meeting today! I missed my alarm.

I assume when you are talking about C API, you are primarily referring the the first networking C API check in I added here:

https://github.com/tensorflow/tensorflow/tree/master/tensorflow/c/experimental

Thank you for looking at it, and I am happy if it will be useful. I was busy with other work lately, so it is not 100% complete.

Here are some answers to your questions:

- The plan is to have tf.LoadLibrary call to load a plugin and use it with TensorFlow. Having TensorFlow pip package will be enough eventually. Right now, I excluded the networking files, but I will look at enabling this workflow.

- Final goal would be to depend *only* on C API. I am going over all the references right now in Verbs plugin to see what additional C API endpoints we want to provide (for e.g. DataTypeCanUseMemcpy, DMAHelper). I haven't looked into other libraries in depth, but C API for collectives is one big thing that's missing now.

You received this message because you are subscribed to the Google Groups "SIG Build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to build+un...@tensorflow.org.
Visit this group at https://groups.google.com/a/tensorflow.org/group/build/.

[Bairen YI]

Thanks for the reply, Anna! 

No worries. I noticed that you checked in the networking C API and that’s exactly what we discussed in the meeting. It’s very useful now that we could start building the plugins without worrying too much on ABI issues.

One choice for dealing with the collective ops is to allow registering alternative collective ops and/or kernels for them, so there will only be a separate Op library, same as what NCCL does. I’m fine to simply wait for awhile though. We are yet to see many adoption cases for dist-strat, at least in the place I work. The delayed release of TF 1.14 and 2.0 certainly plays a role here.

Best,

Bairen

[Jason Zaman]

Do you need to link to libtensorflow.so? or is linking only to libtensorflow_framework.so enough? because the pip package ships _framework and does not ship libtensorflow.so.

[Anna Revinskaya]

Bairen, that's a good idea to allow registering alternative collective ops and / or kernels. Do you think it would be enough or do implementations need a way to customize CollectiveExecutorMgr?

Jason, good point. The plan is to have necessary C APIs available in pip package, but let me confirm.