Skip to content

.NET Support #960

Open
Open
@StevenGann

Description

@StevenGann

Issue #817 was closed with this response:

We fell a little behind. The Python bindings are done in SWIG. I think that can be quickly repurposed into .Net bindings, once done. So it shouldn't be too far out.

That was September 6th. It's now late October and there's been neither an announcement regarding .NET, nor an update to the original issue.

I'm eager to finally work with deep learning on Windows with C# instead of on Linux with Python. I'm sure Python bindings were helpful to some devs, but frankly every other deep learning framework already supports Python and C++. I'm surprised .NET hasn't been a higher priority, since it's something no other system has been able to provide. Now's the chance to become the de facto deep learning library for OOP development!

Activity

wolfma61

wolfma61 commented on Oct 27, 2016

@wolfma61
Contributor

Yes Steven, we hear you and we are sorry for the delay.
This is now one of the highest priority items for us, no definite 'landing day yet', but we should be able to give you at least a date shortly, and you will some work on this topic materializing in branches ...

thx
Wolfgang

StevenGann

StevenGann commented on Oct 27, 2016

@StevenGann
Author

That's fantastic, and thank you for the quick reply. I'm happy to wait, I just wanted some signal that it was still in progress.

andrewfry

andrewfry commented on Oct 27, 2016

@andrewfry

Great news! I'm very excited for this.

On Oct 27, 2016 9:35 AM, "Steven Gann" notifications@github.com wrote:

That's fantastic, and thank you for the quick reply. I'm happy to wait, I
just wanted some signal that it was still in progress.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#960 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AHgBXmpKyUsZKcuUE0HFMcicK-AL3UZQks5q4KicgaJpZM4KiTg-
.

ghost

ghost commented on Oct 27, 2016

@ghost

+1 on C/C++ and C#

gvoysey

gvoysey commented on Oct 27, 2016

@gvoysey

Will support target .NET, .NET Core, or Mono? I am eager to do cross-platform learning in C#.

ghost

ghost commented on Oct 29, 2016

@ghost

python/R is great for research and prototyping - the general "lab settings". this is what alphabet is doing. CNTK extends further as platform and has to support the footprint of why it is being chosen in the first place.

small to medium scale commercial projects would benefit from the complete integrated API. For many, C# replaces VB and likes. this is different ML/AI sector - from phone apps to websites and small corporate projects.

C# leverages over 15 years of the entire DCOM/J++/COM+/DNA2000 etc effort around integrated windows platform development and is used from distributed applications development, transaction processing to desktop and phone applications.

StevenGann

StevenGann commented on Oct 31, 2016

@StevenGann
Author

@zergxyz I'd like to see some numbers showing that more commercial production code uses R than .NET. I'd like to see some data showing more end-user applications and games using Python than .NET.

Can R even be compiled? I know it's basically an open source Matlab but to my knowledge it's still a scripting language. Python can technically be compiled, but compatibility and platform support is poor. Heaven help you if you need something more exotic than the stock Python 2.7 environment.

Academics may favor scripting languages like R and Python, but actual applications tend to be written in actual programming languages. Furthermore, the indie game community is largely dominated by C#, at least more so than Python or R, which means

the main stream in machine learning and deep learning community should be c++/python/R based

Am I addressing the Godking of Deep Learning? Is there an Asimov-style governing body determining what research can be done and how?

You have Python support. I'm sorry if you think R support is more important than C# but the numbers don't lie. C# is more popular than R by every metric. Besides, a quick Google search suggests R already has it's own RNN system, plus it already has support from Tensorflow. Go try Tensorflow instead.

bklooste

bklooste commented on Nov 8, 2016

@bklooste

As these products become more mature they will have to use common languages/platforms , im sick of converting flakey lab code to something that customers can actually use. Large c# programs are everywhere outside of linux (which is used by only a small amount of desktop users).

n17s

n17s commented on Nov 11, 2016

@n17s
Member

We have started actual work on C# bindings.
A few questions to the folks that watch this issue:

  • for Python we relied heavily on NumPy as the way to pass tensors in and out. What is the most natural way of doing this in C# ? Especially if you need some simple preprocessing operations like transposing a 640x480x3 tensor to 3x480x640 ?
  • the issue says ".net" but everyone here has not mentioned anything other than C#. Is it safe to assume that C# should be the next language to cover?
ghost

ghost commented on Nov 11, 2016

@ghost

The best would be to clean-up and merge what had been developed for BrainScript with one of the OS libraries or branch it into separate .net development.

Math.NET Numerics : http://numerics.mathdotnet.com/ (http://www.mathdotnet.com/) could be a good starting point. It also supports using native library ie. MKL etc. There had been some effort within MSFT to use/expose it as well https://msdn.microsoft.com/en-us/library/hh304363(v=vs.100).aspx

There are some smaller tensor library specific porting projects like https://libraries.io/github/alex-weaver/TensorSharp .

Not sure I understand your second question. .NET is a framework and leaves the choice of language free. What is the CNTK strategy over the long term ?

Is to provide a class library targeting all CLI compliant languages? If yes, then you need to choose the actual framework - for instance .NET CORE which is cross-platform and open source. The language is then only relevant for documentation and QA.

Alternatives:

  • provide dll/com libraries targeting C++/CLI
  • standalone C++ "unmanaged code" libraries with interfaces for both .net (System.Runtime.InteropServices) and unmanaged code.

This is TensorFlow discussion about C# API - who face similar strategy choice:
tensorflow/tensorflow#18

n17s

n17s commented on Nov 11, 2016

@n17s
Member

Thanks for the pointer to the TF issue and the pointers to the libraries.

User convenience is the main reason we are doing the bindings. The library is in C++ so if you are determined enough you can program like this, and call it from C# with unsafe code. But that would be ugly, error prone, and hardly deserving to be called "support for .net".

ghost

ghost commented on Nov 11, 2016

@ghost

You are facing some strategic choices for the platform you are building. A lot of CNTK code is redundant or/and dependent on some specific non-easily portable (platform/language) libraries. Looks like you want to re-package the added value over a couple of different directions.

If you target the .net framework (for example .NET CORE) you will have python support free with it on par with other CLI languages (https://github.com/IronLanguages). Not targeting .net means exactly what you had said - poor penetration of potential CNTK users who face hurdles of complexity of interfacing with unmanaged code from their .net environment.

My point of view is product/platform and the necessary resources. It is clear that anything is feasible and usable right now with a given effort. The core of the platform works well - distributed training using GPU/CPU etc.

I would of thought that for model training BrainScript should be enough (with parallel bindings in python). For training via .net applications you could integrate BrainScript into .net or provide a .net library that interprets BrainScript files. You dont have to re-invenent the function by function brainscript binding for model training!

The key area is for the model evaluation. Python users would not notice any difference, while people targeting commercial applications (providing a trained model and an application built on top of the model) would benefit from robust model loading and evaluation via managed code support. There is also less of a performance impact - and smaller percentage of use cases requiring HPC like latencies in evaluation.

I will have a lot more feedback over the next few weeks as we check various CNTK areas - including real-time usage of CNTK Evaluation (C unmanaged code interfacing with native win C++ DLL that uses CNTK Evaluation)

bklooste

bklooste commented on Nov 20, 2016

@bklooste

@n17s I would wrap the C++ tensor. C# has unsafe pointers for exactly this reason and you don't want large amounts of memory in C# when the lib doing the work is C++ , you especially dont want to move the memory from to C# and then copy it into C++ thats a killer often seen in network stacks. So id provide access to the C++ tensor , pin it to modify . A lot of C# network apis do that as well they hold the packet in native and allow the reading into C# only when desired. Probably consider to just write the wrapper in C++CLI as it fits better with the project however C++ CLI will not fit with core ( and core on Linux) .

Agree on brain script only for training , it makes C# a much lighter easier to keep up to date wrapper. Agree on good support here to load and save brain script files. Some methods to construct a brain script file , maybe via expression tree. ( though an extern c call in brainscript would be nice) .

n17s

n17s commented on Nov 20, 2016

@n17s
Member

Sure, the C++ stuff will be wrapped but I believe that's not sufficient. To make this discussion more concrete let's look at this wiki page. An image is loaded, transposed (width x height x channels to channels x height x width), and 128 is subtracted all in one line. This has nothing to do with the CNTK TensorView class, this is all preprocessing to put the input into the right format and numpy is super helpful here. If there's a good library like this in C# we should be leveraging it.

153 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @n17s@gamemachine@bklooste@fwaris@Sam7

      Issue actions

        .NET Support · Issue #960 · microsoft/CNTK