search

dotnet / machinelearning

ML.NET is an open source and cross-platform machine learning framework for .NET.
https://dot.net/ml
MIT License
8.99k stars 1.88k forks source link

Lack of support for UWP apps in ML.NET #2252

Open CESARDELATORRE opened 5 years ago

CESARDELATORRE commented 5 years ago

Current version (0.9 and 0.10) don't support UWP apps properly.

See additional details in this Blog Post: https://xamlbrewer.wordpress.com/2019/01/25/machine-learning-with-ml-net-in-uwp-clustering/

Related issues: https://github.com/dotnet/machinelearning/issues/1736 https://github.com/dotnet/machinelearning/issues/1595

SUGGESTED APPROACH:

Usually, the common scenario for UWP apps (visual desktop applications) is just about scoring a model. The same common scenario for ARM based platforms like Xamarin on iOS and Android. (ARM has nothing to do with this #2252 issue, it just happens that we still don't support ARM, neither)

The suggested approach would be to split ML.NET components/NuGet packages so the scoring components are segregated from the rest of ML.NET.

Achieving support in UWP and ARM just for the "scoring part" of ML.NET might be easier and require less cost/work in testing and development than achieving support for the whole ML.NET (training/test model area).

TomFinley commented 5 years ago

Hi @CESARDELATORRE this has been a longstanding desire. As you observe, the predicting logic is trivial compared to the training logic, in terms of complexity along pretty much every conceivable dimension -- e.g., it takes thousands upon thousands of lines of code to write a good linear predictor, but about two lines of code to write the dot product necessary to predict with it. 😄 So this seems like a great idea, just a fair amount of work. We'd want to not only separate trainers from their associated model parameters, but also estimators from their associated transformers, etc., etc.

Considering that it is so much work, I have a question about whether it can be delayed a bit. One question though: would this be considered a breaking change in the API? So let's imagine you have two classes A and B in a single assembly and nuget, and you decide in a later version, "I am going to put A in nuget X and B in separate nuget Y," is that considered just fine from .NET perspective?

Just wondering if this is something we'd need to prioritize somehow as something that must happen prior to v1, and how completely. (E.g., if we could do it in stages and it is not considered a breaking change, we could perhaps do the most popular things first before moving to everything else, etc.)

markusweimer commented 5 years ago

An alternative approach to consider is to emit prediction pipelines as code. @interesaaat leads a research effort in that direction called Pretzel. It might be time to act on that research?

CESARDELATORRE commented 5 years ago

@TomFinley - Since it'll be breaking the compilation, I think it can be considered a breaking change.. Splitting the "scoring" assemblies from the training bits should be done as soon as possible, in my opinion. It will give us a lot more flexibility when incrementally updating/improving in areas like UWP, Unity and ARM support.

sharpwood commented 5 years ago

When will ML.NET officially support UWP? UWP is Microsoft's latest development framework. This project does not even support UWP? @TomFinley

XamlBrewer commented 5 years ago

The ML.NET v0.11.0 NuGet package largely supports UWP (and that is just awesome).

There's still one big issue: compiling a Release build fails. (ilc.exe code 1200).

Reproduction steps:

ianier commented 5 years ago

Hi @TomFinley, I agree with @sharpwood that UWP should be treated as a first class citizen. In my opinion this issue should be given much higher priority and addressed before RTM.

codemzs commented 5 years ago

CC: @abetaha

MattWhilden commented 4 years ago

@XamlBrewer I'm able to build with the latest set of tools for UWP. Here's my set up:

It may work on something old but I haven't chased it all the way back. I also don't have any experience with the ML tools so I can't say with any certainty if it works when you actually run it.

XamlBrewer commented 4 years ago

Yes @MattWhilden I confirm that it does compile with the upgrade to UniversalWindowsPlatform to v6.2.9. There's still a lot of runtime exceptions however.

MattWhilden commented 4 years ago

@XamlBrewer If you can provide more information I'd love to take a look for you. You can also reach me at dotnetnative@microsoft.com if the details of the project are more sensitive than you're comfortable sharing publicly.

The fastest thing for us to work with are ilcRepro files but there are lots of options.

XamlBrewer commented 4 years ago

I upgraded the sample project to latest stable UWP and ML.NET. I have the impression that all trainers are operational in UWP - AutoML works like a charm (although a LOT slower in x86 than in x64 mode).

I see two major show stoppers:

  1. MlContext.Data.LoadFromEnumerable(), MlContext.Data.CreateEnumerable() and MlContext.Data.Cache() are awarded with System.Reflection.TargetInvocationException: 'Exception has been thrown by the target of an invocation.' PlatformNotSupportedException: Dynamic code generation is not supported on this platform.

  2. Saving a model crashes with "System.ArgumentException: 'The path is empty.'" Here's the code I used to save a model: var storageFolder = ApplicationData.Current.LocalFolder; string modelPath = Path.Combine(storageFolder.Path, modelName); _mlContext.Model.Save(Model, inputSchema: null, filePath: modelPath);

All code works in Debug mode. In Release mode the exceptions are identical in x86 and x64 mode.

On calling CreatePredictionEngine() for a LbfgsMaximumEntropy transformer, I get System.Reflection.TargetInvocationException: 'Exception has been thrown by the target of an invocation.' PlatformNotSupportedException: Dynamic code generation is not supported on this platform.