3 ms·
I have no idea what your problems are, but I code UWP in C# which is the preferred language and its all fine and dandy here. (c++ .net is not real c++ anyway)
by bostand 10y ago
I have no idea what your problems are, but I code UWP in C# which is the preferred language and its all fine and dandy here.
(c++ .net is not real c++ anyway)
- general_ai 10y agoC# maybe. But C# is not suitable for what I do (fast deep learning on video, images, and audio). Any kind of managed language is hostile to those kinds of things and just plain not designed for them. I want to drop down to SIMD intrinsics and assembly when I need perf, and C# won't let me do so. But I think even folks with much more modest needs suffer with UWP. For instance, try to load an image from your hard drive (using UWP C++), resize it with Lanczos and get access to its pixels. The API is a fucking nightmare, there's no way to resize an image that I could find (unless you want to show it in the UI, in which case all is taken care of for you, but you can't get pixels from there). On macOS/iOS, it's just a few lines of rather plain looking code.
- pikzen 10y ago.Net offers reasonable SIMD access through the System.Numerics package. Roslyn offers writing plain IL Assembly, which is heavily used throughout SharpDX, and ultimately, P/Invoke is fast and allows you to call any C++ library you might want if you really want to get down to the metal. Seems a better alternative to me that having to deal with the hilariously bad C++ UWP API
- general_ai 10y agoReally, you call this "reasonable SIMD" access: https://msdn.microsoft.com/en-us/library/system.numerics(v=vs.111).aspx https://msdn.microsoft.com/en-us/library/system.numerics(v=v...? For comparison get a load of Apple Accelerate: https://developer.apple.com/reference/accelerate https://developer.apple.com/reference/accelerate. Now that's "reasonable" SIMD access, and extremely heavily optimized on both macOS and iOS for both speed and power efficiency. Similar capabilities are just one command line incantation away in Linux. And if that's not enough, you get real, actual assembly, not some "IL assembly" where you have no control over what it will emit when converted to machine code. Here's another constraint you may have failed to consider: my code doesn't just run on Windows. I compile the same C++ code across all supported platforms with fairly minimal #ifdefs to adjust to platforms and SIMD ISA. Windows is the only platform that fights me every step of the way. Linux is great. macOS is great. iOS and Android are great. Goddamned bare metal is great (cross-compiling on Linux). UWP is awful and hostile.
- pikzen 10y agoFor 90% of the usage of SIMD instructions where people just want to parallelize iterating on lists, yes, that's reasonable enough. Apple Accelerate isn't a SIMD API, it's a higher level API that happens to use SIMD for its utilities. Apple makes great APIs, yes, I can't deny that. You seem to have forgotten P/Invoke where your performance critical C++ code can actually be called from C#. You get your assembly and everything whenever you want, for a low initial cost of calling your FFI. And you also get a pretty damn good UWP experience, as well as WPF, WinForms and a long list of UI toolkits. Let's be real for a second though, the Android NDK is an absolute joke , and calling the C++ experience on Android "great" might be pushing it a bit far.
- general_ai 10y agoThe beauty of NDK is not that it offers a ton of APIs (it does not), it's that it's not overcomplicated and lets you reasonably easily incorporate a lot of the same libs you're already using on Linux anyway, and build them pretty much exactly the same as any other Linux lib, with minimal, if any modifications using tried and true Linux toolchains. It took me much less time and effort to get my stuff going under NDK. PInvoke would do me no good whatsoever, since my UI needs are fairly limited, and my entire pipeline is basically capture, resize, run inference, and display. Running it through extra layers would only slow it down -- something I try very hard not to allow. Fundamentally, though, my issue is this: Microsoft pretends to support C++ under UWP, yet when you actually take a look at what's being offered, you see that it's a bare minimum and it's hardly used by anyone. A step off the beaten path and you're on your own since it seems no one is actually using this stuff. Or at least no one publishes anything on the internet. APIs are idiosyncratic, documentation is sparse, tools are crashy (XAML editor), and there's nothing on Stack Overflow. Epic fail.
- bostand 10y agoFrom what I read you have some very specific needs and for various reasons also have decided to use tools/languages every one here advices against. This is all fine, but your first post make it sounds like UWP in general is crap, which I don't agree with.