C# api
janerivi opened this issue · comments
C# is very popular and expressive language with a large community of pro developers.
Providing APIs for every 'very popular' lang would probably bloat the main project quite quickly.
I'd really like to see a C#/.net wrapper. Shouldn't be too hard to p/invoke into the C++ API.
Perhaps CppSharp could be of use? As opposed to SWIG?
👍
This is something the core TensorFlow team is unlikely to tackle in the near future, so if you want to contribute it, please go ahead! I would recommend circulating a proposed implementation on the discuss mailing list early on, so that a consensus about where such API might live (in repo / off repo / in 'contrib' directory) can be reached ahead of time.
FYI, @zaphar has just contributed initial C# rules to Bazel. These rules are currently in an early state and currently only support Mono, but the plan is to add Microsoft .NET support once Bazel supports Windows. If anyone is interested in helping with improving Bazel's C# rules, contributions are definitely welcome. :)
Just a general +1 from me!
@davidzchen - I am not familiar with Bazel but assuming the that the idea behind you mentioning it being extended to run on Windows, along with the new C# rules, would be to allow us to build this repo on Windows, including the code for the potential .NET (mono) interop library?
Could an alternative approach be to just build and distribute the native tensorflow libs (dll's) on NuGet - and then in a completely seperate repo, create this.NET interop. This seperate repo can be built using MSBUILD or something so would eliminate Bazel as a blocker?
@dazinator Correct. I am not sure what the TensorFlow team has decided about where support for additional language should live (as @vincentvanhoucke mentioned, in the tensorflow repo, in separate repos, or in a contrib directory). In the meantime, I'm sure it would be fine for somebody to pick this up, circulate a proposal, and implement C# support built using msbuild. We can add BUILD files later for users who would want to use Bazel instead of msbuild.
I just wanted to put that out there in case somebody is interested in helping out with Bazel's C# rules. :)
The problem is not to invoke C++ code, but to translate the Python part of TensorFlow to either C# or C++. It has about 60K lines of code. That's where TensorFlow "magic" resides on...
I'm currently working on porting TensorFlow to Node.js, and we got stuck on this. Maintaining a synced version of some thousand lines of code will get out of control as soon as something changes in the Master. The way I see it working, is to translate the Python part of TensorFlow to C++.
If you guys are willing to help, please join us at slack: https://github.com/node-tensorflow/node-tensorflow
@ivanseidel - I think one solution for the python code from a .NET perspective, would be to use IronPython - which allows you to:
- call your Python .py from within .NET
- run it
- get a result back into your .NET app from the Python code.
So i'd assume that for a C# implementation, we'd try and keep all the original python code as is (as much as possible) to save translating 60k lines (and keeping them in sync)
Saying that, this is a completely pie in the sky idea and I really haven't looked at any specifics yet! :)
@dazinator That is a way out, but then, you cannot "writte" code from within C# context, you will be limited to writting TensorFlow code in .py and calling it from other languages...
The Idea is to have all the tools available native in the language. Of course this is a working "work-around", but if you need a dynamic TF code, you will get somewhere limited by it =/
But, translating all those lines of codes from Python to C++, wouldn't need to be "in sync" anymore. Just the callers, but not the implementation code... It takes an effort, but a single effort, once, to make things the right way =)
@ivanseidel - I understand.
.NET also has good native interop, so porting this python code to C++ version could be good for both .NET and NodeJS
My comment around the "sync" was really about - if google decide to continue to evolve their python code, we'd have to continue to keep the c++ code base in line with that.. It would essentially be having to maintain there implementation as a fork - but I do understand the benefits :)
Yep, you are right...
As I see, keeping a fork for it is required, be it a Node.js fork for the Python code, or C#, or even Java. But if there is a fork for C++, all can use it in favor.. C++ is universal in this case, while no other language can support all others as much as C++...
In any case, if you feel engaged to it and would like to help, join us at slack (link: https://tensor-flow-talk-invite.herokuapp.com/). And good luck with it :)
As I think we have mentioned elsewhere, there is a lot of code in python that we do hope to move into the core C implementation (shape inference, gradients, etc), so that the language bindings only have to be thin, idiomatic wrappers around the core functionality. But as you know, it is quite a bit of work to do this, and we already have some 100+ open issues to prioritize against too, so please be patient with us.
@vrv , I'm not asking for you guys to priorityze this, but willing to help on this matter. It will save people time when It's ready, and make TF awesome in all other languages... I'm planning on using my vacations on this, but It's not a one-person job. Should I open an issue calling for help on that? I guess Java/C#/Node guys would be willing to help
Great to hear that you are willing to help! We're not at a state where the work can easily be parallelized across multiple developers, but once we are, we'll definitely try to conscript the community to help.
@dazinator @ivanseidel - I don't understand why IronPython isn't a good idea. Even if all we can do is in / out the data from the c# / .net app - that is a huge step forward. What am i missing?
I don't think you are missing anything, my understanding is that on the one
hand we'd between writing our own surface layer / api with iron python that
sits on top of the tensor flow api's. Only yhat surface that we create will
be calllable from c#.
With the convert to c++ approach, we'd end up being able to use the
existing tensor flow api's in c# directly (via native interop)
On Fri, 4 Dec 2015 2:31 am Joe Booth notifications@github.com wrote:
@dazinator https://github.com/dazinator @ivanseidel
https://github.com/ivanseidel - I don't understand why IronPython isn't
a good idea. Even if all we can do is in / out the data from the c# / .net
app - that is a huge step forward. What am i missing?—
Reply to this email directly or view it on GitHub
#18 (comment)
.
Has anyone actually tried to interpret the TensorFlow python using IronPython?I appreciate there's now a way to use numpy and scipy with IronPython - though I don't know how long ago this was last updated - but IronPython doesn't play nicely with CPython C extensions.
Anyone tried IronPython approach?
No. IronPython will struggle with any C extensions. Though I think there's a work around for numpy and scipy. Does IronPython work on Mono or CoreCLR? My understanding was that TensorFlow won't run on Windows.
On Fri, Jan 8, 2016 at 5:03 AM -0800, "Eugene" notifications@github.com wrote:
Anyone tried IronPython approach?
—
Reply to this email directly or view it on GitHub.
what about efficiency in a distributed platform if you use Ironpython ?
somewhere in the doc it is mentioned that :
To do efficient numerical computing in Python, we typically use libraries like
NumPy that do expensive operations such as matrix multiplication outside Python,
using highly efficient code implemented in another language.
Unfortunately, there can still be a lot of overhead from switching back to
Python every operation. This overhead is especially bad if you want to run
computations on GPUs or in a distributed manner, where there can be a high cost
to transferring data.
Here is a port of the c api to csharp I just made, using SWIG, to keep the maintenance to a minimum.
https://github.com/unrealwill/tensorflow-csharp-c-api
Still a work in progress to make it more easy to install and use.
But example graph runs fine.
FYI: We recently added some documentation in the form of a how-to around how TensorFlow intends to support other language bindings.
Some general porting advice / FYIs regarding C# -- (I've seen some clumsily ported libraries in the past, and they were super awkward to work with, I would hate to see something like that happen to a cool library like TensorFlow!)
C# and .NET have built-in support for a lot of the simple stuff (high speed math, SIMD instructions using the built-in vectors and matrices structs, etc.), so there's not as much of a need to shell out to another process to do regular math.
Also, it has built-in operator overloading (so no need for a "mul(x, y)"-like function, etc. because you can just overload the multiplication operator). [It also has actual properties, and you can overload the indexer operator, so no need to ever write "get" or "set" functions directly; and strong typed enums, so no need for random strings or constants to ever be passed around.]
Additionally there's already some patterns in C# for building a "graph" of operations and deferring their execution to be done later, or even on other hardware (i.e. LINQ can work this way with IEnumerable, but especially with IQueryable where an expression tree can be built and translated or passed on to another machine for execution, etc. -- also the CSOM pattern -- even though it's meant to solve a different problem -- might translate well here -- because the pattern let's you build up multiple queries and then execute them all at once).
If session has any resources that need to be cleaned up when it's done or if it needs to be "stopped" or something, consider making it IDisposable (then we can just wrap it in a using block, etc.) -- IDisposable can also be used to introduce dynamically definable scope (i.e. because it works well with using blocks).
Also worth mentioning (as I'm looking through the porting document right now, and this isn't a super well known feature): code generation is built into the .NET platform using T4 templates (.tt files). You can run any kind of C# code there (access a database, read a file, do P/Invoke, etc.) to output a .cs file at compile time.
It would be super cool to be able to build a TensorFlow statement in C# using LINQ and have it execute on the GPU.
[Nothing here is meant to be patronizing, (hopefully none of it was!), this is just meant as some tips from a C# power-user that I hope will be of use to someone.]
Another thing I just stumbled on to -- if IronPython won't work, you could try Python for .NET (pythonnet):
- https://github.com/pythonnet/pythonnet/.
- http://pythonnet.github.io/readme.html
- http://stackoverflow.com/a/7368156/398630
Note that this package does not implement Python as a first-class CLR language - it does not produce managed code (IL) from Python code. Rather, it is an integration of the CPython engine with the .NET or Mono runtime. This approach allows you to use use CLR services and continue to use existing Python code and C-API extensions while maintaining native execution speeds for Python code.
And
Python for .NET uses the PYTHONPATH (sys.path) to look for assemblies to load, in addition to the usual application base and the GAC. To ensure that you can implicitly import an assembly, put the directory containing the assembly in sys.path.
It looks like you still have to have Python installed for it to work, but maybe it could be a help where IronPython couldn't?
@asimshankar could you please update this HowTo [C] with the [C++ API]
Looking through the Java language binding using javacpp [1][All APIs implemented in java], I think cppSharp would also be an good alternative than the SWIG approach.
@JimSEOW : What sort of update are you suggesting? Our intention is to have the Java API implemented on top of the C API as mentioned in the doc using JNI.
I haven't looked into the details of javacpp/cppsharp, perhaps @jhseu has and might have some thoughts on the pros and cons of the two approaches.
Yeah, we suggest that you implement it on top of the C API because we'll have versioning stability there after the 1.0 release. It's also what the other language bindings will be using, including Java, which won't be built using javacpp.
@asimshankar @jhseu I understand that you plan to provide Java API using JNI. Do you have a path for .NET API? e.g. SWIG path using C API as stated by @unrealwill
Why abandon C++ API? Users of Javacpp has already using the C++ API. It is a matter of time for cppSharp to catch up.
There are reasons why cppSharp is prefered over SWIG when come to .NET for cross platorms, as successful company like XAMARIN uses it.
It will help the .NET user if we know there is a commitment, instead of leaving to the .NET users to come out with an ad hoc heterogeneous solutions. We need some clear leadership comments.
- There is no intention to abandon the C++ API. The C++ API is fully supported and in fact is what TensorFlow Serving is built on. As a general rule, if it is documented on the TensorFlow website, it is supported :).
- That said, the C API was designed with the intent of it being used to build other language bindings (see howto) and that is what other language bindings such as Go, Rust, Ruby and others are built on (most of which are built and maintained by the community, not the TensorFlow team). Specifically, the C API should be appropriate for use with FFI support that languages typically provide (e.g, JNI, cgo, LuaJITs FFI etc.).
I am perhaps not fully grasping your concern here. Are you looking for a recommendation as to whether (1) using something like P/Invoke to wrap over the C API, or (2) cppsharp over the C API, or (3) cppsharp over the C++ API or (4) SWIG over the C API is preferable?
I don't believe we have enough expertise in the .NET framework within the TensorFlow maintainers to make an informed recommendation, and we sincerely welcome any community contributions towards this. My gut instinct would say that it would be preferable to wrap over the small API surface of the C API using whatever FFI support is canonical in .NET and use that as a basis to provide an idiomatic C# library. As opposed to depending on other frameworks or "transliterating" everything in C++ API which may result in non-idiomatic APIs in the language. Though again, I say this without enough expertise in .NET or C# specifically.
(oops, didn't mean to close the issue)
Feedback: please take a look http://bytedeco.org/ (tensorflow is listed)
Why cppSharp? Many who have tried e.g. .NET wrapper for OpenCV for years (P/Invoke) are now trying to explore how to use cppSharp to generate .NET wrapper for OpenCV.
I believe both cppSharp and JavaCpp are similar in the ways of creating wrapper codes automatically. They compile C++ codes and generate the c# or java binding codes respectively.
There is no more need to MANUALLY (in the case of SWIG and P/Invoke) to do regular catch-up with the fast development of the master c++ codes.
This is my view, I may be wrong, I am open to feedback and to learn from others.
Hey guys, dev from CppSharp here, just been made aware of this discussion. Just some clarifications.
If you want to bind a library with a generator like CppSharp, it's usually best to start with a C++ API from the start since that will lead to a more idiomatic generated API.
We can also generate bindings for the C API, but you will usually need to develop an higher-level C# API on top of the generated bindings to have a more idiomatic C# object-oriented API.
The only exception to this is when the original C++ public interface is complex / not very "clean" (boost, lots of templates) and then the auto-generated API might not be very clean and starting from the C API might be preferable.
If you do end up going with CppSharp we'll do our best to support the project and fix any CppSharp bugs found along the way.
fyi - I built this script to spit out c# files (en masse) from tensor flow proto buffers for use with grpc https://gist.github.com/johndpope/5d176f4eebeb7ec983fa77d945c18fb1
If you want to co-ordinate efforts further -> jump on #grpc channel
https://tensor-flow-talk-invite.herokuapp.com/invite
Having the C# wrapper use the C API through DllImport is the right approach. I have written many such things (having had to interface with Matlab-exported C a number of times). You can see something of my similar work here: https://github.com/BrannonKing/NLoptNet . I'm willing to work on it. Now I just need a Windows DLL.
JUST DO IT
You can now use tensorflow with pythonnet to call from .NET languages:
@denfromufa have you tried it (running tensorflow from .net via phytonnet)?
if you did - can you give some pointer on how to do it?
Is first class support for c# even planned?
Development with wrappers and such is almost always a sub-par experience; and using tf in serious projects when there's no actual support from the devs is not something I'd do.
But I think its worth it. So many things are written using .NET nowadays...
The TensorFlow maintainers do not currently have plans for creating a C# API. We do however maintain the C API intended for building language bindings and are open to changes to that to assist the community in building C# APIs.
@denfromufa have you tried it (running tensorflow from .net via phytonnet)?
if you did - can you give some pointer on how to do it?
@tiagosomda you can ask from @snarb about his experience with tensorflow and pythonnet. I just tried importing it successfully, but have not played with it yet.
@denfromufa it is ok. works, but I have used it mainly for sort of unit-testing of my C# implementation :)
We are interested in doing this work.
I believe someone in my team had started work on this, if not, we will be happy to contribute it.
@migueldeicaza That'd be great! Please look at https://www.tensorflow.org/versions/r0.11/how_tos/language_bindings/ as a starter guide.
Also, if you'd like code review from the TensorFlow team, then please loop in me and @asimshankar after it's committed somewhere. Thanks!
Pythonnet in .net works, but is not particularly practical. SWIG (using Linux/Mono) generated wrapper/manually exposing the C API in a wrapper is working well for me
@luketg8 with SWIG, someone(s) [most likely from the C API guys who also must know .NET - unfortunately not in this case here] to "manually exposing" to keep/catch up with the latest code change.
With CppSharp, as discussed by @tritao, you need an experienced specialist committed to setup the workflow to create the .NET bindings, after that, users like us could just simply use the created workflow to catch up with the latest code change
With CppSharp, not only there "should not be" issue making the .NET wrapper available for e.g. Linux/Mono, but if we lucky, we also get cross platform support.
Imagine having .NET bindings for tensorflow [through CppSharp] while coding for Mac, iOS, Android and UWP. If anyone need concrete example, follow what @migueldeicaza's team does with creating .NET binding for c++ Urho3D to cross platform UrhoSharp
In my experience, there still need much work to make embedding python in .NET through Pythonnet reliable and hence practical.
@JimSEOW I agree that it is a lot of effort to maintain the wrapper for the C API when there are new updates, but it is just what is working for me at the minute with the limited amount of C# I need to do. For now, I have just had to write a lot of my code in C++ and prototype in Python.
However, I do agree (having experimented briefly) with the use of CppSharp for this, but I think I'd need to look into it more to write a proper conclusion.
@jhseu Thanks for the pointer, it has proved to be very useful.
I am making good progress on the API, I am doing a line-by-line port of the C API test to make sure that I got the proper API coverage, and also using this as an opportunity to make sure that the API is idiomatic C#.
It is not ready to be reviewed, but for reference, the code is here:
https://github.com/migueldeicaza/TensorFlowSharp
I'll post on this thread when it is ready to be reviewed.
Nice! Feel free to ping me by e-mail if you run into any issues or have any questions.
Just emailed you on your profile email address :-)
@jhseu [Not sure if you are the right person to ask]
Is there a plan to build native library [libtensorflow.dll] on Windows?
So we could persuade @migueldeicaza to get tensorflow/tensorsharp working on Windows?
We don't have any immediate plans, but making it would likely be trivial once Bazel works on Windows. I believe that's coming soon, but I'm not sure.
FYI: Here is some recent effort to use Bazel Windows to build the native library [libtensorflow.dll]
Along with these solutions, Emgu CV have also added a tensorflow importer to their DNN module https://github.com/emgucv/emgucv
TensorFlowSharp now works on Window using libtensorflow.dll extracted from tensorflow-1.1.0rc1-cp35-cp35m-win_amd64.whl
migueldeicaza/TensorFlowSharp#49
Image Recognition using Tensorflow now works through TensorflowSharp in Windows (c#)
@JimSEOW great news, thank you everybody for your efforts!
great news to me as well, thanks to tensorflow team! Genius!
JimSEOW, thanks for sharing, you are great!
NO! @migueldeicaza makes this possible!!
@DomLi and @luketg8 Could both you share your feedbacks, issues at TensorflowSharp
If you look through these open issues, there are still open technical challenges need to be addressed to make TensorflowSharp or .NET same FIRST class citizen as python for Tensorflow.
will keep trying, but too busy with some other projects at moment, luke and me in the same office:):)
Starting Release 1.2, Windows DLL will be made available and tensorSharp binding works!
Which is the status of .Net binding as of today? Are C# and F# really usable languages to work with Tensor Flow or the situation is still as described in this previous comment? Thanks for the quick recap
@giuliohome : The TensorFlow maintainers do not maintain or support the C#/F# bindings and have no plans of doing so. However, we happily point you to TensorFlowSharp, which is built on top of the supported C API. Any questions/comments/concerns you have there are better raised in the TensorFlowSharp repository.
@giuliohome please visit Tensorflowsharp. We are using the latest window dll contributed by this group C API. We need more people to port python tensorflow examples/tutorials codes to .NET. We have tested Xamarin Workbook (Jupiter notebook alternative) to support the porting and sharing of .NET example tensorflow codes
can anyone plz tell me how to write a fresh tensor flow C# project in Visual Studio MacOS? What project should I choose?
Also I have installed TensorFlowSharp using Nuget from inside of Visual Studio MacOS but when I built the existing example project from within of Visual Studio nothing happens
It says built successful but nothing happens. What's the output for Example Common generates? Anything that it generates(outfile, image, graph etc)?
In case of Tensor Flow & Python....it's shows output in Jupyter(automatically fires in browser) but don't know here :(
Someone plz help me out :(
@migueldeicaza tried to help me on Twitter & on this migueldeicaza/TensorFlowSharp#149 (comment)
issue but no luck so far
Your best bet is the instruction right here:
migueldeicaza/TensorFlowSharp#149 (comment)
There is still no official C# support in TF itself, so we wont be able to help much.
@gunan but how has he created this projects?
ExampleCommon is a library project, not an executable project. That is why it does not have a [>] icon, but a [|>] icon. Open an actual example.
@migueldeicaza amazing effort! Thanks a ton!
so is this thread for C# TensorFlow. I mean will you be able to train models in C# after that? Just like we do in Python?
Yes, you can train models in C#. It seems like people like to use it to reuse existing code that imports their existing data into TensorFlow.
Today it is better to use Python and Keras to define your models/graphs and then load the result from C# and run that.
Probably this solution will be helpful for C# developers: TensorFlowServingCSharpClient
There are TF MNIST Deep model learning and save model for TF Serving.
.NET console application and SPA .NET Core 2.0 ReactJS examples. It use TensorFlow Serving API with gRPC service calls.
@migueldeicaza Thanks again for TensorFlowSharp! As the feature has been already implemented, I am closing this issue
My company is developing a full C# binding to Python API: https://losttech.software/gradient.html
Another solution is TensorFlow.NET.
Latest tensorflow.dll for c# api