Windows 10 and .NET Native

http://www.anandtech.com/show/9661/windows-10-feature-focus-net-native

by WhitneyLand • 11 years ago

158 107 11 years ago

greggman• 11 years ago

How do I verify the app I downloaded was made by the developer? I suppose on phones there's no way to do that now anyway or at least I don't know how on iOS.

My point being if ms is compiling then how do I sign the executable as proof it's from me?

pcunite• 11 years ago

Good question. I assume you upload a cert? My question: what happens when I side load on my phone with a different compiler but ship it to MS who uses a different version and the app runs differently?

neurostimulant• 11 years ago

Probably MS will re-sign it with their certificate, like what Apple did in their app store.

jameshart• 11 years ago

One consequence of these 'app store compiled' models is that the compilation units you upload will have to be licensed to the app store in such a way that the derived native apps are legitimately licensed. That probably rules out, for example, even including LGPL libraries in your app, since the resulting application will statically compile that library code in with .NET components.

dchest• 11 years ago

LGPL doesn't forbid static linking, you'll just have to provide linkable object files (or source code) separately to enable re-linking. (https://www.gnu.org/copyleft/lesser.html#section4)

GermainSmith• 11 years ago

I don't see why anybody should be surprised about the swing back to Ahead-of-Time compiled native code. I'm actually surprised it has taken as long as it has.

Although interpretation and Just-in-Time compilation were not new ideas at the time, Java first brought them to a wide audience around 20 years ago with its use of the JVM.

Anyone who remembers those times, and even many years beyond then, will remember how slow JVM-based applications were compared to native apps.

Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases.

Since then we've seen similar techniques used by a variety of other platforms.

Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance.

While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world.

Ahead-of-Time C and C++ compilers have consistently compiled software that's very fast, lean, and the best performer in real-world scenarios.

For years, we've had people pointing out this very obvious reality regarding how Ahead-of-Time compilation proves to be superior to Just-in-Time compilation in realistic scenarios. Yet we've seen their claims very forcefully denied by the Just-in-Time advocates.

Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach.

With battery-powered devices more prevalent than ever, the need for high-performing and efficient binaries is greater than it has ever been. Returning to Ahead-of-Time compilation is just what we need given these circumstances. It's just a real shame it has taken so long for this important reality to be recognized.

brianwawok2• 11 years ago

I mean, it's almost a moot point. Each year the number of native apps I run goes down by a couple, and the number of webapps I use go up by a few.

Native apps I use right now?

Chrome - Already native compiled

IntelliJ - Full JIT mode, but due to the fact I start it once and run it for a month, not a huge deal.

Command line unixy stuff - Already native compiled

(On gaming computer) Games - Already native compiled

I mean desktop apps DO exist, but just not that many to use day to day... from what I have seen of the windows app store, I can find 20 colors of calculator apps, but nothing that impressive.

pjmlp10• 11 years ago

For me it goes the opposite direction.

On mobile only apps. The Web is for reading stuff.

On the desktop the same thing, except for all those forums and travel booking websites that don't offer me a choice.

Messaging, email, productive software, work related stuff all native software.

Exception being when some customers do require web projects.

mwcampbell7• 11 years ago

I gather that you don't run many apps on a mobile device. The shift toward mobile apps seems to be what's motivating the current trend toward AOT compilation.

acdha• 11 years ago

Web Assembly is going to add an interesting hybrid: the actual native compilation will happen on the client but the app developer will have the ability to put significant AOT resources into optimizing the byte-code sent over the network.

ygra• 11 years ago

Java was interpreted initially. The JIT compiler came later (around 2000, IIRC).

pjmlp10• 11 years ago

There have been AOT compilers from third party JVM vendors almost since the begining. Used mostly by companies that didn't want to expose their bytecode.

However Sun decided to bet the farm on JIT and was against having AOT compilation on the reference JDK. Meaning anyone that wanted a AOT toolchain for Java had to go shopping.

Now, it appears Oracle is of a different opinion.

"Java Goes AOT" at JVM Language Summit 2015

https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar...

Being used to memory safe languages with AOT compilation like Turbo Pascal, Modula-2, Modula-3, Oberon, Delphi, Ada among many others, I also would have prefer that Java and .NET had offered the same type of toolchain from the beginning.

Now almost 20 years later, we need to teach young generations that their default implementations were just that, implementations. As they got used to the (wrong) idea that memory safe languages imply a VM.

pilif• 11 years ago

Delphi and pascal are memory safe? That's news to me. I have created my fair share of buffer overruns and memory corruption in both of them (they were my first languages I programmed in)

Roboprog5• 11 years ago

Eiffel is probably another "other" Pascal/Modula descendent.

Java beans uber class invariants :-(

lmm• 11 years ago

Being used to memory safe languages with AOT compilation like Turbo Pascal, Modula-2, Modula-3, Oberon, Delphi, Ada among many others, I also would have prefer that Java and .NET had offered the same type of toolchain from the beginning.

Do those languages offer consistent, defined behaviour on all platforms (e.g. for integer overflow)? Particularly in the context of multithreading - do they have a crossplatform memory model? That to me was the big advantage of the JVM.

7952• 11 years ago

A lot of change in computing seems to be moving the location of a cache to be closer or further from the user in a cyclical manner. Maybe the same observation can be applied to source code?

chrisseaton• 11 years ago

Maybe after 20 years, it has finally become clear that the Just-in-Time supporters were wrong, and that Ahead-of-Time compilation is the better approach.

I think your argument is only correct for one subset of languages - C, C++, Haskell - languages like that. For languages like JavaScript, Ruby, Python, JIT compilation is proving to be massively more successful, and it's really easy to understand. As soon as you have features like eval, AOT compilation is never going to be effective.

BigChiefSmokem• 11 years ago

Agree with you but I have to call something out about JS. The thing I most hate about JavaScript is how slow JIT is and I think we have wasted tons of industry resources trying to write better engines instead of pushing for lower level access to the client metal from the web server.

bad_user2• 11 years ago

Despite many years of effort and research, and much investment, we've yet to see Just-in-Time compilation rival Ahead-of-Time compilation in terms of the performance.

I see this repeated ad nauseam, but it's false.

Other platforms are not rivaling C/C++ in terms of performance and not AOT compilation. But the reason for why C/C++ is still winning in terms of performance has little to do with it being compiled ahead of time and more to do with manual memory management and not using a garbage collector. C++ compilers are also very mature, being themselves the subject of research. But compare Java's performance to Go, or to Objective-C for that matter and the situation changes completely.

mkup• 11 years ago

You are talking about high advancements in the compiler research. But is there any statistically significant performance difference between the code compiled via latest GCC vs. OpenWatcom (which is unmaintained for a few decades)?

AshleysBrain2• 11 years ago

Whenever I read posts like this I feel like two technologies are being portrayed as combatants in an epic war over the years, with engineers taking sides and firing shots at each other.

In reality I think technologies are just tools which have their appropriate and inappropriate uses. Both AOT and JIT have their strengths and weaknesses, and engineers make their choices based on those tradeoffs. With the linked article, it sounds like the startup time tradeoff is being used as the main motivation for making a change, probably because mobile users are more sensitive to this. That doesn't mean JIT fundamentally sucks - it's worked pretty well on the web with Javascript, for example.

JustSomeNobody3• 11 years ago

You're wrong. It is a battle. Look at how quickly the swords come out when anyone brings up C# and Java or Python and Ruby or Backbone and Angular. Any discussion involving developers and the tech they use quickly devolves into all out verbal conflict. People LOVE to argue about this stuff because it gives them something to do besides actually doing anything productive.

It's all rather sickening, really.

0xFFC• 11 years ago

The things you are talking is correct, Two technology should be just technology , but in real world I don't think so , companies tend to sell their technology as some kind of magical power and revivals wants to show other companies technology is just crap .

But what you are saying is mostly true in academia or ideal world , but not in reality .

eloff• 11 years ago

This is a kind of wishy washy liberal attitude that is found all over. An attempt to say both sides of an argument have a point. Which is always true, otherwise there wouldn't be an argument. The part I take umbrage at is that it implies both sides have an equally valid argument. That is rarely true. Here JIT has been claiming superiority for twenty years. It has clearly failed. It's slower to start, slower to run, and uses more memory. That will very probably never change. It still has some advantages in some areas and some niches, but AOT has won. The war, if you really must use that term, is over. We see this in the resurgence of interest in C++ and in the move in mobile ecosystems to AOT.

pcwalton4• 11 years ago

While Just-in-Time's supporters will claim that it allows for better optimization or better portability, or they can show some contrived benchmarks where it has a slight edge, we haven't seen such techniques stand up in the real world.

Other than JavaScript, which you're executing right now to post this comment?

Web app usage is huge, and there isn't going to be any shift to native code there anytime soon. NaCl (not PNaCl) has been dead as a proposal for Web content for a long time. That's because JITs actually do allow for better portability.

Edit: OK, HN doesn't actually use JS, so mea culpa on that rhetorical flourish. Still, the point stands that you're using the Web a lot, and that's a testament to the success of JITs.

rymate1234• 11 years ago

does HN even use that much JavaScript?

pjmlp10• 11 years ago

Just because they took Usenet away from us, native guys.

A am yet to use any forum online that is as comfortable to use.

Web app usage is huge, and there isn't going to be any shift to native code there anytime soon.

I am betting on mobile to change the wave.

ben0x539• 11 years ago

Edit: OK, HN doesn't actually use JS, so mea culpa on that rhetorical flourish.

Hey now, I'm probably using JS to post this comment because apparently Firefox is made with it!

legulere• 11 years ago

The JVM was very slow in the beginning because it was just an interpreter and had no JIT compilation. Then there also was the issue with 80bit floats on x86 making float computations slow, as the results of each operation needed to be saved back to memory to truncate them to 32/64 bit.

The speed difference since those problems have been overcome has been relatively low. The biggest performance problem is garbage collection, which you can't overcome just with implementing ahead of time compilation. Another issue is the lack of SIMD support of JIT VMs.

redcalx2• 11 years ago

.NET has SIMD support as of version 4.5.2.

lovemetender• 11 years ago

> Even today, there's still a noticeable difference between JVM-based software and native software, although the exceptionally massive increase in computation power have rendered the differences easier to overlook in many cases.

Measurable I'd agree with, noticeable no, not really unless you mean startup time; otherwise the JVM is very fast once it's started, that isn't disputable.

acconsta• 11 years ago

Unmanaged native code definitely has an edge, even in I/O-heavy applications like databases.

http://www.scylladb.com/technology/cassandra-vs-scylla-bench...

Not to mention low-memory environments like mobile.

eslaught• 11 years ago

The issue is not AOT vs JIT, but one of language semantics and levels of abstraction.

You could prove this point in a trivial way by JIT compiling C with LLVM. The binary would have an increased startup cost, but would otherwise run identically to an AOT compiled C program. It might even run faster, since the LLVM JIT could run with the equivalent of the -march=native to the AOT compiler. (In an AOT environment, you can only do this if you can guarantee that the binary will only run on the machine it was compiled on, or otherwise know the exact specs of the target machine.)

A much more interesting example is Terra[1], a language with C-like semantics embedded inside Lua. The Terra-Lua combination allows you to use Lua as a sort of C++ templates replacement, giving you much better metaprogramming than traditional C/C++. This allows you to do cool things like implement a version of matrix-multiply which is specialized to the target hardware, allowing you to match or almost match the performance of ATLAS and Intel MKL. Mind you: these are not your usual C/C++ programs, they are mostly written in manually hand-tuned (or auto-tuned) assembly.

What we're really looking at here is a difference in abstraction levels. It's not that the JVM JIT is incapable of getting C-like performance. Obviously it can, in certain cases. The issue is that the Java semantics prevent the JVM from getting C-like performance in a predictable and dependable way from idiomatic Java programs. This should not really be a surprise, given how far Java is from C.

What we really need to do is take a step back and reconsider our assumptions. Our modern programming languages lock us into certain assumptions about language design and semantics that can be blinding at times. Consider that even C doesn't get optimal performance in all cases---this is why Fortran still exists. What would it take to get to programming language with nice semantics and truly optimal performance? I don't have a closed form answer, but I'm confident that the solution will require revisiting some of the assumptions baked into not just our compiler infrastructures, but also our languages.

[1] http://terralang.org/

mrec3• 11 years ago

they [desktop apps] really want to move to the new app platform anyway

1. Stop anthropomorphizing desktop apps, they don't like it.

2. Can't tell if the author means "desktop devs want to" (false IMO), "desktop devs ought to" (also false IMO) or "MS wants desktop devs to" (undeniably true).

3. It depresses me that just as MS is genuinely 'getting' open source, they're completely missing the appeal and value of an open platform. One step forward, two steps back.

EDIT:typo

bitwize• 11 years ago

I think the referent for "they" here is "Microsoft", not "desktop apps".

bad_user2• 11 years ago

I don't see how MS is getting open source. What makes people say that? Is it the 14 years it took for them to open-source .NET Core, an event that is happening at a point in time when .NET is most irrelevant?

What really pisses me off however is that it's 2015 and Windows 10 and Outlook still don't support CardDAV and CalDAV. They'll get their hand forced by market pressure of course and as usual they'll end up supporting the minimum they can to get away with, which means they'll provide special hooks for Google and probably iCloud. All of this in the context of Edge, yet another buggy and proprietary incarnation of IExplorer in a world in which Chromium and Firefox exist. And of course, we mustn't forget the patents racketeering they are doing at the expense of the open-source projects that compete with them

But oh boy did they change. Their PR department is genius though.

edgyswingset• 11 years ago

"MS wants desktop devs to" (undeniably true)

What makes you say this, the publishing of a third app model for Windows, messaging, some combination of the two, something else?

mrec3• 11 years ago

Both, plus the fact that significant new tech infrastructure projects like the Windows Runtime are (mostly) restricted to Store apps.

I'm not anti- app stores or declarative UI in general, and I think things like standardized sandboxing would be great for many desktop apps too. But a platform that places you at the whim of a single distribution path, and cripples portability to boot, isn't worth it.

stevoski• 11 years ago

I'd love to have the JVM equivalent of this for my company's main desktop product, written in Java. Due to being Java (and having an embedded JRE) the app has slow startup, due to the JVM having to be started up. The installer is 90 MB on OS X, 55 MB on Windows, much of which is the embedded JRE. So our our fortnightly updates are much bigger than they need to be.

We tried an AOT compiler called JET. It was fine, albeit expensive. But it has an extremely long build time, no great for our continuous build system. It's support Java version also lags considerably behind the current Oracle Java release.

mwcampbell7• 11 years ago

Check out Avian (http://oss.readytalk.com/avian/). You can use it with the OpenJDK class library. You can even run your application plus the class library through ProGuard, then AOT-compile the whole thing to generate a boot image for fast startup.

pjmlp10• 11 years ago

Oracle is planning to finally add it to the standard JDK around Java 10 timeframe, but it might be a premium feature similar to the mission control licensing.

https://www.youtube.com/watch?v=Xybzyv8qbOc&list=PLX8CzqL3Ar...

jacques_chester2• 11 years ago

As I understand it, a big part of the slow load time for Java apps is sucking everything on the classpath into RAM, even though most apps will use a fraction of the classes that are loaded.

Java 9's module system should make that a lot less of a problem by giving the JVM guidance on what it should load and skip.

I am not a Java expert, though, so I may have misunderstood what's going on.

fiatmoney• 11 years ago

The JVM class loader by default reads a class on first reference to it in the code it's executing. Never refer to it, never gets loaded.

Startup on the JVM is more affected by the JIT warming up, and the heap getting into a "stable" configuration.

simfoo• 11 years ago

At this time, it is not available for desktop apps, although that is certainly something that could come with a future update. It’s not surprising though, since they really want to move to the new app platform anyway.

Thanks, but no thanks. I'm not investing time and effort into a toolchain that ultimately targets only a single platform, namely Windows 10, because they don't want me to be able to just xcopy a .exe without touching their store

saosebastiao• 11 years ago

It's frustrating that the .NET Native compilation is so tied to the Rosylyn toolchain that it can't be used for other languages like F#, even though they're using the same IR.

sixbrx• 11 years ago

Yeah this seams to me like a repudiation of the whole idea of .NET, as a multi-language system. They may add support for F# later, but by that time, the damage will have been done because the message is clear: "use anything other than C# or VB at your own peril".

Currently F# is completely shut out - it can't even be used to make libraries to be included in these kinds of apps! That makes it more dangerous career-wise to use F# going forward, lest your team get wedged into a position of having to rewrite one of your libraries because of your choice of using your "pet" language. Not good for the career.

The whole point of bytecode is to make things like this language independent. Big failure of vision to let this group do such a hack, IMO.

kevingadd• 11 years ago

This is most likely just an artifact of F# producing unusual IL that's harder to handle. In my experience, it's less 'we only support C#' and more 'compilers other than C#/VB.net produce very strange IL that is hard to handle well' - which is true. Given the small # of users that rely on those weird compilers, it's hard to justify supporting them first, especially if they aren't performance-sensitive.

MichaelGG5• 11 years ago

Yep, it's incredibly disappointing. The CLR model is rich enough that MS Office can be compiled entirely to MSIL and run fine. The F# folks had to drag Microsoft kicking and screaming into shipping generics - else the CLR and C# would have probably only gotten the lame Java-esque erasure model.

Yet despite being shown up, utterly, entirely, they just sorta stumble forward. They realise there's no serious competitor in the language space - Java's remained terrible. There's no threat to C#, and it's a lot easier to maintain a compiler than a platform. The runtime hasn't seen any change since .NET 2 introduced generics (with driving work from MSR). Since then, they've tweaked perf a bit, but haven't extended the model at all.

Until there's a real threat, they continue down this easier path. Swift shows up and demonstrates tuples and matching won't kill average devs, ok C# will probably add those. And honestly they can probably get fairly far just reacting here and there.

It is sad though to see the grand idea of the CLR fall this far.

shoover• 11 years ago

UserVoice discussion here: https://wpdev.uservoice.com/forums/110705-dev-platform/sugge...

moomin• 11 years ago

You know, this is all very well, but the Windows 10 app market is pretty much non-existent. You know who really uses .NET on Windows? LOB applications, front ends to complex systems. The kind of thing you don't see in the app store.

And that market is better served with, you know, a compiler, that runs on the command line, on a machine under a developer's control.

MichaelGG5• 11 years ago

The Windows Store was traditionally just scams with blatant trademark infringement. This has severely damaged their rep. A quick search now shows a lot of it is cleared up. Unfortunately, that just leaves the shovelware junk.

Here is an interesting point: Right now, the #3 top free app is "Freeflix/Free Movies Unlimited"[1] and #4 is a "free Mp3 downloader".

The publisher for the free movies is "Wamba Dev" which results in no related hits on Google outside of Windows Store. Contact is a hotmail account, and the privacy policy is on "dopeware.com".

So Microsoft isn't even able to get real publishers in top positions on its own Store. Pretty damn sad.

Also the Metro runtime is diseased and broken. Opening the Store app right now to do these searches took about 15 seconds. On a decently high-end ThinkPad. It's embarrassingly bad. Even the Metro calc takes 2-3 seconds to open, ffs.

1: https://www.microsoft.com/en-nz/store/apps/freeflix-free-mov...

graycat6• 11 years ago

I just wrote 18,000 programming language statements in Visual Basic .NET, in files with 80,000 lines including comments, blank lines, etc., compiled much of it with a command line script with line

    programPath = dq || SystemRoot || ,
    '\Microsoft.NET\Framework\v4.0.30319\vbc.exe' || dq

and give the rest to the Microsoft Internet Information Server (IIS) to compile and run as Web pages, and it all works, but, still, I can't make any sense out of the OP at all.

E.g., my command line compiles result in a file with extension EXE. What's in that? Sure, I have the Microsoft .NET Framework 4.0 installed, and the VBC.EXE invoked as above is, of course, one of the files in the installation of that .NET Framework.

When from a command line I just run that script that runs that VBC.EXE, I get nice output showing the command line options for the program -- simple, direct, explicit, terrific.

So, how do I connect what that .NET Framework 4.0 VBC.EXE does with the discussion in the OP?

BTW: Why use Visual Basic .NET instead of C#? C# borrows too much of the old C syntax, and Visual Basic has syntax more traditional and more like that of Pascal, PL/I, Fortran, etc., and I find that more traditional syntax easier to write and read and less error prone. But, likely and apparently, the difference between C# and Visual Basic .NET is mostly just syntactic sugar anyway.

By the way, where does the famous CLR -- common language runtime -- enter this picture?

Thanks.

kyberias• 11 years ago

What?

graycat6• 11 years ago

What part of my question do you not understand?

redcalx2• 11 years ago

Every poorly performance problem I've ever encountered has been due to poor design choices, poor choice of algorithm or, most often, badly implemented algorithms.

Once past the JIT compilation delay the execution speed is not significantly different for AOT and JIT code for mature platforms such as .Net and Java.

There are issues in CPU and RAM resource limited systems such as mobiles and embedded systems. And also web servers - where small improvements in scalability can dramatically affect business viability and profitability.

MichaelGG5• 11 years ago

IIRC the .NET Native literature says the main benefits are reducing RAM by a fair amount. Which makes sense - no runtime to load type info and no JIT to run. AFAIK, they aren't claiming the compiled code is _that_ much better than what the JIT does.

Of course it's probable that reducing RAM footprint significantly might improve runtimes if it makes better use of cache.

Windows 10 and .NET Native

Related Stories