Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

.NET Native Compilation Preview Released

timothy posted about 4 months ago | from the faster-faster-faster dept.

Software 217

atrader42 (687933) writes "Microsoft announced a new .NET compiler that compiles .NET code to native code using the C++ compiler backend. It produces performance like C++ while still enabling .NET features like garbage collection, generics, and reflection. Popular apps have been measured to start up to 60% faster and use 15% less memory. The preview currently only supports Windows Store applications, but is expected to apply to more .NET applications in the long term. A preview of the compiler is available for download now. (Caveat: I both work for MS and read Slashdot.)"

cancel ×

217 comments

Sorry! There are no comments related to the filter you selected.

I thought April fools was 2 days ago? (0)

Skinkie (815924) | about 4 months ago | (#46653145)

Maybe the Haskell team at Microsoft Research really didn't have anything better to do.

Re:I thought April fools was 2 days ago? (3, Interesting)

Tough Love (215404) | about 4 months ago | (#46653435)

It actually sounds like gcj.

Huh? (5, Funny)

Desler (1608317) | about 4 months ago | (#46653163)

Popular apps have been measured to start up to 60% and use 15% less memory.

So they no longer fully start up? Why is that a benefit?

Re:Huh? (-1, Offtopic)

quonsar (61695) | about 4 months ago | (#46653193)

they never did.

Re:Huh? (0)

K. S. Kyosuke (729550) | about 4 months ago | (#46653235)

Yeah, especially since if they started up to the other 40%, they'd apparently use 85% less memory. My number-fu is better than your number-fu!

Re:Huh? (2, Informative)

Soulskill (1459) | about 4 months ago | (#46653241)

The word 'faster' was omitted. I've updated to fix.

Re:Huh? (-1, Troll)

Anonymous Coward | about 4 months ago | (#46655395)

Isn't it your jobs to proofread things before posting them? Even a five-year-old could do a better job.

Wouldn't blame him (-1)

Anonymous Coward | about 4 months ago | (#46656339)

After all, he'd have to read something that an MS employee wrote.

Thanks, but.... (-1)

Anonymous Coward | about 4 months ago | (#46653309)

Cool, but nobody cares about metro apps or Windows RT. Release it for real computers and we'll talk.

Native Image Generator (0)

Anonymous Coward | about 4 months ago | (#46654069)

I believe this already exists for "real computers". It's called the Native Image Generated (http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx). It's been included with .Net since 1.1.

Re:Native Image Generator (1, Interesting)

ThePhilips (752041) | about 4 months ago | (#46654781)

That doesn't sound like a proper native compiler:

The Native Image Generator (Ngen.exe) is a tool that improves the performance of managed applications. Ngen.exe creates native images, which are files containing compiled processor-specific machine code, and installs them into the native image cache on the local computer. The runtime can use native images from the cache instead of using the just-in-time (JIT) compiler to compile the original assembly.

Yes, it does produce native code.

No, it doesn't produce an executable, ready for redistribution.

I do not disagree with the approach, but there is still the difference. If done right, it might be a blessing: code is optimized for the local CPU. If done poorly (as MS likes to do it sometimes) it might mean irreproducible bugs or performance regressions and outright no effect at all, if cache gets corrupted somehow.

Re:Thanks, but.... (0)

Anonymous Coward | about 4 months ago | (#46655417)

But muh metro fart app loads 60% faster!!

Re:Thanks, but.... (0)

Anonymous Coward | about 4 months ago | (#46655677)

Lies! The Metrosexual UI is the greatest thing ever!

Re:Thanks, but.... (0)

Anonymous Coward | about 4 months ago | (#46655967)

Why is this modded down? Nobody gives a shit about Metro apps running faster -- nobody is writing those nor wants to. Everybody is doing Windows/WPF apps and such. Hell, more command line tools get written in C# than Metro apps. I'll be very excited when this compiler works on real-life software (never?).

Re:Thanks, but.... (1)

AaronLS (1804210) | about 4 months ago | (#46656329)

I agree with the essence of the statement, but it's written in terms of childish absolutes such as "nobody" that obviously isn't true. Maybe if he had said "The majority of .NET developers aren't doing metro. When you expand support for this feature, then it'll be interesting to the rest of us." But some people live in a world that revolves around them and cry when they get left out. I hope this feature comes to the rest of the .NET platform, but I'm not going to cry about it.

Re:Thanks, but.... (0)

Anonymous Coward | about 4 months ago | (#46656381)

But no one is writing Metrosexual UI apps. That's why Microsoft is having to bundle websites as apps to inflate their app store numbers.

Open source compiler (5, Interesting)

rabtech (223758) | about 4 months ago | (#46653325)

They also open-sourced their new C# compiler:

http://roslyn.codeplex.com/ [codeplex.com]

Re:Open source compiler (2, Insightful)

ackthpt (218170) | about 4 months ago | (#46653421)

Isn't it time for yet-another-language? How about C$ ?

Re:Open source compiler (4, Funny)

Bacon Bits (926911) | about 4 months ago | (#46653517)

I'm not going back to GW-BASIC, thanks,

Re:Open source compiler (2)

datapharmer (1099455) | about 4 months ago | (#46653631)

It's already in use by the administrative share.

Re:Open source compiler (1)

NatasRevol (731260) | about 4 months ago | (#46653941)

Fine. Shift-5 then.

Re:Open source compiler (1)

Anonymous Coward | about 4 months ago | (#46655245)

I'm highly proficient in C:\>

Re:Open source compiler (1)

Anonymous Coward | about 4 months ago | (#46653829)

Anyone else think it's too little too late?
Sorry Microsoft, you had your chance. We now went the long way around you and not coming back. :|

So no more .net redistributable? (2)

Kenja (541830) | about 4 months ago | (#46653397)

This can only be a good thing as every game I install these days also installs the redistribution files for .net.

Re:So no more .net redistributable? (0)

TMYates (1946034) | about 4 months ago | (#46653703)

Not true. Native only means that there will be no IL (Intermediate Language) code. Right now .NET is more interpreted than it is compiled. This would mean it gets compiled like C or C++. You would still need the .NET redistributable for any libraries you reference just as you have done with C++ libraries or DLL libraries in traditional Windows development. Not having to compile the code before executing it (using the JIT compiler) means serious performance, but also paves the way to more native support on other devices. Especially since they released it into the open.

Re:So no more .net redistributable? (5, Informative)

PhrostyMcByte (589271) | about 4 months ago | (#46653855)

Yep! From their FAQ:

apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine.

Re:So no more .net redistributable? (2)

QuasiSteve (2042606) | about 4 months ago | (#46653955)

every game I install these days also installs the redistribution files for .net.

Do they actually install them, or are they merely included in the installer packaging and installed if and only if the files are missing or outdated?

Re:So no more .net redistributable? (-1)

wiredlogic (135348) | about 4 months ago | (#46654327)

These programs still need to access the .NET libraries which are part of the redistributable. They're just doing it through something akin to managed c++ rather than the normal CL interpreter.

Re:So no more .net redistributable? (2)

dbraden (214956) | about 4 months ago | (#46655157)

Actually, that's not the case. As already mentioned by PhrostyMcByte above, here's the quote from Microsoft's FAQ:

apps will get deployed on end-user devices as fully self-contained natively compiled code (when .NET Native enters production), and will not have a dependency on the .NET Framework on the target device/machine.

Pretty cool in my book.

Re:So no more .net redistributable? (4, Insightful)

MightyMartian (840721) | about 4 months ago | (#46655427)

Yeah, I can't wait for a half-gigabyte executables.

Re:So no more .net redistributable? (0)

egr (932620) | about 4 months ago | (#46654709)

Maybe you mean C++ Redistributables? These have nothing to do with .NET, but rather C++ standard library.

Re:So no more .net redistributable? (-1)

Anonymous Coward | about 4 months ago | (#46655061)

No, he means .NET, moron. That's why he said DOT FUCKING NET.

Re:So no more .net redistributable? (1)

Desler (1608317) | about 4 months ago | (#46656399)

Maybe you mean C++ Redistributables?

No [microsoft.com] , they didn't.

Finally, a paid shill (-1)

Anonymous Coward | about 4 months ago | (#46653399)

Finally, a "paid shill" who admits it. I just felt a strange disturbance in The Force, as if millions of forum participants cried out in anger and were suddenly silenced.

Ah... (-1, Troll)

ackthpt (218170) | about 4 months ago | (#46653407)

Now for bloat at twice, or even three times the speed!

Re:Ah... (3, Insightful)

i kan reed (749298) | about 4 months ago | (#46653547)

Yeah, sorry, GUIs won. Like 20 years ago. You can stop pretending that our multicore processors with 64 gigs of ram can't handle them.

Re:Ah... (2, Informative)

jafac (1449) | about 4 months ago | (#46653841)

When installing a security update for .NET takes 45 minutes, there is no pretending involved.

Re:Ah... (0)

Anonymous Coward | about 4 months ago | (#46655999)

You can install .Net from scratch in under 5 minutes. Try again

Re:Ah... (1)

gonnagetya (3580051) | about 4 months ago | (#46656541)

Depends on the hardware. In any case I've noticed that the .NET updates in Windows Update seem to always take the longest to complete out of all the various updates that can appear, so despite they hyperbole there is some truth to what he said.

Re:Ah... (0)

Anonymous Coward | about 4 months ago | (#46656113)

When installing a security update for .NET takes 45 minutes, there is no pretending involved.

I think it's pretty clear that it taking 45 minutes *is* pretending, that simply does not happen.

Re:Ah... (0)

Anonymous Coward | about 4 months ago | (#46656367)

I have a Core 2 Duo computer from 2007 and it takes like 5 minutes tops. PEBCAK.

Re:Ah... (1)

fyngyrz (762201) | about 4 months ago | (#46654597)

You can stop pretending that our multicore processors with 64 gigs of ram can't handle them.

...and perhaps you can stop pretending that HLL bloatware has anywhere near the performance of hand coded apps *on the same CPU*. It has nothing to do with GUI's per se, either. It's about frameworks with years and years of bloat, slow code in black boxes that can't be sped up (or often even bugfixed, as we have sadly come to learn), about ridiculous amounts of memory getting chewed up by library after library, about swapping instead of careful memory use... please don't pretend that faster CPUs have addressed the performance issues of higher (and higher) level approaches. The bottom line is still that well crafted apps that eschew OO approaches will almost always outperform for both memory use and speed, given the same environment to run in.

Re:Ah... (2)

cavreader (1903280) | about 4 months ago | (#46656419)

Memory and CPU power are there to be used so why not take advantage of it. And what the hell is a hand coded app? Or are you referring to programming against a runtime versus programming directly against the OS? And what does eschewing OO approaches mean? Are you talking about an application that encapsulates all it's functionalities without referencing any external resources or dependencies?

Re:Ah... (0)

Anonymous Coward | about 4 months ago | (#46656467)

Memory and CPU power are there to be used so why not take advantage of it.

We would like to, but the VMs are stealing away precious CPU time and RAM that could be used for better application performance.

Translator? (3, Interesting)

Anonymous Coward | about 4 months ago | (#46653419)

compiles .NET code to native code using the C++ compiler backend

Can it output the generated C++ source?

Re:Translator? (1)

Cory Nelson (3599421) | about 4 months ago | (#46653673)

It'd be just like the old days when C++ compilers would preprocess into C.

Re:Translator? (3, Informative)

Calavar (1587721) | about 4 months ago | (#46653683)

Correct me if I am mistaken, but I'm pretty sure that if they are using the backend they are skipping the lexing and parsing steps and going straight to the generation of the intermediate representation. That would mean that there is no generated C++ code to see.

Re:Translator? (1)

benjymouse (756774) | about 4 months ago | (#46654693)

Correct me if I am mistaken, but I'm pretty sure that if they are using the backend they are skipping the lexing and parsing steps and going straight to the generation of the intermediate representation. That would mean that there is no generated C++ code to see.

That is precisely what they announced. No correction needed. They use that C++ backend to emit code for specific processor architectures (and core counts) and do global optimizations.

New technology! (0, Funny)

Anonymous Coward | about 4 months ago | (#46653431)

A fully compiled binary deliverable! Revolutionary!

(for Microsoft)

Re:New technology! (2)

Bengie (1121981) | about 4 months ago | (#46653509)

Next up, compiled java that doesn't churn through memory.

Only benefits smaller devices (1)

yurik (160101) | about 4 months ago | (#46653485)

The raw speed of the code might actually diminish since the .net runtime could have optimized it better for the specific environment (CPU model, available RAM, phase of the moon, etc). On the other hand, the startup would benefit - no more need to just-in-time compile. Plus there is no need for memory to compile it. On the other hand, the runtime might use some cycles to further optimize code during execution, whereas with this approach the code won't change any further. In any case, great for instant startup, but I suspect conceptually this is not much different from the older binary pre-compiled cached versions of the assemblies.

Re:Only benefits smaller devices (2)

robmv (855035) | about 4 months ago | (#46654117)

Well, the ART preview native compiler on Android 4.4 is on device so it could compile to native on the device, but I expect Google will accelerate that step precompiling on their servers taking into account device characteristics. Microsoft could do that too if they want

Re:Only benefits smaller devices (2)

benjymouse (756774) | about 4 months ago | (#46654779)

The raw speed of the code might actually diminish since the .net runtime could have optimized it better for the specific environment (CPU model, available RAM, phase of the moon, etc).

MS announced that developers still need to pass hints to the compiler on what architecture, CPU core count, available memory etch, to compile for. You can (cross) compile to multiple architectures.

This technology is already at work when deploying apps for Windows Phone 8: Developers pass IL code to the store, native compilation is performed per device type in the cloud (CPU architecture, OS version, memory, ...) and the binary is passed to the device.

Re:Only benefits smaller devices (1)

ebno-10db (1459097) | about 4 months ago | (#46656249)

The raw speed of the code might actually diminish since the .net runtime could have optimized it better for the specific environment (CPU model, available RAM, phase of the moon, etc).

I hate to break it to you, but the original Pentium is now obsolete. Compiling for a specific CPU variant doesn't help much these days. I'm also unaware of any JIT compiler that adjusts the code for available RAM. You might have a point about the phase of the moon.

Basically you're citing the standard tropes used in defense of JIT. Theoretically it can make some difference, but when I ask for benchmarks showing code on a JIT running faster than straight-to-binary, all I hear is crickets.

Run more native Windows apps on Linux (3, Insightful)

common-lisp (2771805) | about 4 months ago | (#46653497)

From the article:

the .NET Native runtime [is] a refactored and optimized CLR

According to the article, the .NET Native runtime is a (not yet complete) implementation of .NET. This means that Wine + .NET Native = a Microsoft-built .NET runtime on Linux. This is good news because this may be a way to take those .NET technologies missing from Mono, such as WPF, and still use them on Linux.

Another reason this is good news is, we're one step closer to being able to develop Windows installers in .NET. Lately I've been using NSIS and it is the most stupid, idiotic language I've ever used. It's been described as a mixture of PHP and assembly.

Another thought: the article doesn't seem to mention it, but judging by the design, the .NET Native compiler may be able to compile any .NET DLLs and EXEs, not just C# ones.

Re:Run more native Windows apps on Linux (-1, Offtopic)

Pieroxy (222434) | about 4 months ago | (#46653707)

If you care so much about all that windows crap, why are you running Linux at all?

Re:Run more native Windows apps on Linux (4, Insightful)

common-lisp (2771805) | about 4 months ago | (#46654229)

If you care so much about all that windows crap, why are you running Linux at all?

Because Linux is much easier to develop with.

Some Windows technologies (WPF, .NET, C#) are well designed, as are many Linux technologies. Seeing the benefits of one platform isn't mutually exclusive with seeing the benefits of another platform.

However, what is mutually exclusive is a tribal mindset and the ability to see two sides of the situation.

Re:Run more native Windows apps on Linux (0)

Anonymous Coward | about 4 months ago | (#46654353)

And who cares about software that only runs on a rapidly dying platform?

Re:Run more native Windows apps on Linux (0)

Anonymous Coward | about 4 months ago | (#46654723)

The death of MS has been greatly exaggerated...

Re:Run more native Windows apps on Linux (1, Insightful)

Anonymous Coward | about 4 months ago | (#46655189)

Linux isn't dying. yes it is a long way behind MS and MS are still very much dominate, but Linux isn't going anywhere.

Re:Run more native Windows apps on Linux (2)

wonkey_monkey (2592601) | about 4 months ago | (#46654333)

Breaking news! Some people use Linux but have a need for something that's only ostensibly available for Windows!

Re:Run more native Windows apps on Linux (0)

Anonymous Coward | about 4 months ago | (#46655875)

WPF , Linq et al. are missing due to LICENSING.

Only .Net 2.0 is allowed to be implemented, that is why such nice technology API's as WPF et al. are NOT in Mono et al.

NO GO AREAS
post 2.0 .Net
VB
Office
et al.

If you start to implement these, you will get your asses dragged into every court in the land.

Read Microsoft's community promises for a list.

http://www.microsoft.com/openspecifications/en/us/programs/community-promise/default.aspx

http://www.microsoft.com/openspecifications/en/us/programs/community-promise/covered-specifications/default.aspx

http://www.microsoft.com/openspecifications/en/us/programs/community-promise/covered-specifications-special-terms/default.aspx

ONLY ECMA standards are promised, anything else, you're in a big deep minefield and you have NOWHERE NEAR the amount of money and time to fight it.

VB.NET support is right around the corner. (0)

Anonymous Coward | about 4 months ago | (#46653701)

Good thing too...

Caveat: I both work for MS and read Slashdot. (-1)

Anonymous Coward | about 4 months ago | (#46654043)

I'm sorry.

It produces performance like C++ (1)

innocent_white_lamb (151825) | about 4 months ago | (#46654249)

"It produces performance like C++".

How many times over the years have I seen this? "Widget-of-the-month is almost as fast and efficient as C."

My response is, if the performance is important then why not do it in C? C is definitely as efficient as C. If performance is not important, then why does it matter?

I don't see the need to spend time and/or money on something that's "almost as good as C" when C itself is available.

"This cardboard pizza is almost as good as a real pizza and it only costs $10 more!" Er, no thanks?

Re:It produces performance like C++ (1)

Anonymous Coward | about 4 months ago | (#46654451)

>My response is, if the performance is important then why not do it in C?

Performance is *always* important, but sometimes it's less important than development time. If I can develop/maintain a complex set of tools in C# taking 1/10 of the time than doing it in C, why not do it in C# if it runs fast enough?

So it's only a bonus if development is easy AND you get performance closer to C.

Re:It produces performance like C++ (1, Insightful)

MightyMartian (840721) | about 4 months ago | (#46654571)

Is C really that hard to develop in? After all, the chief advantages of C# isn't really C#, but the .NET libraries. C/C++ with good libraries strikes me as being a reasonably good option. If I'm just going to end up compiling it to down to machine code anyways, why bother with .NET at all? I get it if you have an existing code base you want to squeeze some more cycles out of, but if I were starting a new project tomorrow, give me one reason why a C# compiler is the way to go as opposed to C++?

Re:It produces performance like C++ (4, Insightful)

ralphbecket (225429) | about 4 months ago | (#46655603)

"After all, the chief advantages of C# isn't really C#, but the .NET libraries."

You can't be serious! C is *substantially* lower-level than C#; you should only use C as a portable assembly language. I've spent decades writing assembly, C, and higher level languages and I'd pick C# over C in an eyeblink for anything that doesn't require access to the bare metal (well, personally I'd pick a functional language, but these days I work in industry...)

Re:It produces performance like C++ (2, Insightful)

Desler (1608317) | about 4 months ago | (#46656421)

You can't be serious! C is *substantially* lower-level than C#; you should only use C as a portable assembly language.

Why? C is extremely easy to write and has vast amounts of libraries to use.

Re:It produces performance like C++ (0)

PRMan (959735) | about 4 months ago | (#46655647)

Given the number of unintended buffer overflows I've seen in C programs over the years, apparently so. BTW, I have never seen an unintended buffer overflow problem in C# or Java.

Re:It produces performance like C++ (3, Funny)

ebno-10db (1459097) | about 4 months ago | (#46656283)

I have never seen an unintended buffer overflow problem in C# or Java.

So you've seen intended ones?

Re:It produces performance like C++ (1)

AlphaBro (2809233) | about 4 months ago | (#46656273)

Have you actually taken the time to learn about C# and .NET, or are you just parroting soundbites you heard? C# is a superb language without the help of the (also superb) .NET BCL. Further, you don't have to choose between the two. C++/CLI can be used if you want to work directly with .NET classes from C++. If you want to write raw, .NET-less C/C++ that is invoked from .NET, that is also quite easy with PInvoke. Your myopic view of programming languages is detrimental; few programs are written in a single language these days.

Re:It produces performance like C++ (1)

sconeu (64226) | about 4 months ago | (#46654573)

Parent has the right of it. Performance is only part of the equation. There's what I call the X-abilities. Readability, maintainability, scalability, you-name-it-ability.

Often, raw C can fail on those.

Re:It produces performance like C++ (2)

ThePhilips (752041) | about 4 months ago | (#46654889)

Raw C can be X-able.

It's just plain PITA to do it.

Otherwise, performance of the raw C is overrated. Or better: the developers who benefit most from C performance are the ones who can't algorithms. Also, developing reusable algorithms in C is a major PITA.

Re:It produces performance like C++ (1)

MightyMartian (840721) | about 4 months ago | (#46655411)

The small amount of your post that even makes sense is absurdly wrong. For fuck's sake, *nix kernels have been implementing complex process and cycle allocation algorithms for four decades now, almost all of it written in C. That's not even talking about various tools in userland that invoke fairly complex logic.

Christ almighty, what fucking planet do some posters live on?

Re:It produces performance like C++ (1)

ThePhilips (752041) | about 4 months ago | (#46655901)

For fuck's sake, *nix kernels have been implementing complex process and cycle allocation algorithms for four decades now, almost all of it written in C.

LOL. Thanks. As a system developer specializing on Linux, how could I have missed it!? /s

Seriously though, you might also note that it often took kernels also *decades* to get where they are.

Most algorithms are very very primitive - because you shouldn't put complex/unpredictable logic into the kernel.

Lion share of memory allocation is static. There are very few truly dynamic structures. Because kernel may not run out of memory (and kernel address space is often very limited).

Data structures are primitive - lists and hashes are the pillars - because everything else either has lower memory efficiency or has performance quirks.

It literally takes years to get it right.

Otherwise, if you are such a huge fan of C, please show me an implementation of binary tree in C which can be reused to store either `int` or `double` or `void *` data types in it. And no, crapload of preprocessor macros or type casts on every source code line do not cut it.

That's not even talking about various tools in userland that invoke fairly complex logic.

You seem to be either inexperienced or undereducated. Because you have missed the elephant in the room:

Complex logic != complex implementation.

And it's not like "complexity" has any formal definition.

Having seen and written plethora of C code in my life, I know well what C is capable of. But still, for any new development it is literally impossible to recommend C over C++.

Re:It produces performance like C++ (1)

innocent_white_lamb (151825) | about 4 months ago | (#46656123)

Otherwise, if you are such a huge fan of C, please show me an implementation of binary tree in C which can be reused to store either `int` or `double` or `void *` data types in it.
 
https://developer.gnome.org/glib/2.37/glib-Balanced-Binary-Trees.html

Re:It produces performance like C++ (1)

ebno-10db (1459097) | about 4 months ago | (#46656307)

for any new development it is literally impossible to recommend C over C++

]
Your rant makes little sense - almost everyone upthread was talking about C/C++, not just C. They were contrasting C/C++ to things like C# and Java.

Re:It produces performance like C++ (1)

fyngyrz (762201) | about 4 months ago | (#46654621)

Exactly.

Re:It produces performance like C++ (1)

harvestsun (2948641) | about 4 months ago | (#46655187)

Oh I dunno, there's the whole ".NET features like garbage collection, generics, and reflection" part. You might have missed it.

Re:It produces performance like C++ (1)

cbhacking (979169) | about 4 months ago | (#46656285)

Not to mention handy language features (call it sugar if you want, it makes the coding faster and easier) like LINQ, lambdas, method overloading, and so on.

So when is MS Office going to be built with .NET? (1, Insightful)

Anonymous Coward | about 4 months ago | (#46654253)

I believe MS Office is built using Visual C++.
Microsoft were unable to use .NET to build their own applications, presumably because of poor performance.
Microsoft have failed to eat their own dog food.

If MIcrosoft .NET was successful, then WindowsRT on an ARM CPU would have not been a failure.
If .NET was implemented properly, all applications compiled with Microsoft VIsual Studio should have produced exes/dlls with both native x86 and .net (fat binaries).
Then all existing Windows Apps would run on the ARM CPU (admittedly a bit slower). .NET has clearly failed.

Re:So when is MS Office going to be built with .NE (2)

ThePhilips (752041) | about 4 months ago | (#46654943)

Microsoft were unable to use .NET to build their own applications, presumably because of poor performance.

Unlikely. MSO is very old. Very likely the source code is poorly documented and not completely understood. Porting that to anything is going to be a major and very risky undertaking.

.NET has clearly failed.

Still clearly better than VB.

Re:So when is MS Office going to be built with .NE (1)

PRMan (959735) | about 4 months ago | (#46655675)

No, what failed was coming up with RT instead of just using .Net (and by that for ARM I mean Mono) to begin with.

Re:So when is MS Office going to be built with .NE (1)

cbhacking (979169) | about 4 months ago | (#46656313)

No need to use Mono for ARM. .NET has been supported on numerous architectures, including ARM, as part of Windows CE for years. Sure, it was only a subset of the full framework, but not for any technical reason except keeping the footprint small.

WinRT (not to be confused with Windows RT; we're talking about the API set now) does often feel like a waste of effort to me, although there is something to be said for identifying/creating a sandbox-friendly set of APIs to use in creating sandboxed software...

now if only (0)

Anonymous Coward | about 4 months ago | (#46654323)

it ran on linux.

What about number-crunching performance? (2)

Theovon (109752) | about 4 months ago | (#46654487)

I skimmed over the links, but I probably just missed it. So apps take 60% less time to start, and they use 15% less memory. What about run-time performance? How much faster are they when executing?

Re:What about number-crunching performance? (2)

benjymouse (756774) | about 4 months ago | (#46654823)

I skimmed over the links, but I probably just missed it. So apps take 60% less time to start, and they use 15% less memory. What about run-time performance? How much faster are they when executing?

During runtime, a.NET already runs compiled. This saves on the JIT compiler.

However, they also announced (later session at /Build//) that the new compilers (including the JITs) will take advantage of SIMD. For some application types this can allegedly lead to serious (like in 60%) performance gains. Games were mentioned.

Re:What about number-crunching performance? (1)

PRMan (959735) | about 4 months ago | (#46655689)

This only helps the first load. After that, either one should be the same if the JIT is worth anything.

Re:What about number-crunching performance? (2)

cbhacking (979169) | about 4 months ago | (#46656333)

Well, that depends. JIT needs to be *really* fast. That limits the optimization it can do. Pre-compilation to native allows more processing time for optimizations between the CIL and the machine code than a JIT can really afford.

Re:What about number-crunching performance? (0)

Theovon (109752) | about 4 months ago | (#46656395)

That’s MY point. Plus, if the .NET JIT is anything like the JVM, only hotspots get compiled, while the rest are interpreted. (If you only run a piece of code once, it may be faster to interpret it than to compile and then run it.)

APRIL FOOLS! (0)

Cammi (1956130) | about 4 months ago | (#46654561)

This must be april fools. If they claim it is a .net compiler, but only supports 1% of .net (aka, windows store apps), then this IS APRIL FOOLS!

Re:APRIL FOOLS! (1)

Anonymous Coward | about 4 months ago | (#46655803)

That's where the "preview" part comes in.

Is JITC finally going to die? (3, Insightful)

IamTheRealMike (537420) | about 4 months ago | (#46654669)

Many years ago there was an R&D project inside a large tech company. It was exploring many of the hot research topics of the day, topics like mobile code, type based security, distributed computing and just in time compilation using "virtual machines". This project became Java.

Were all these ideas actually good? Arguably, no. Mobile code turned out to be harder to do securely than anyone had imagined, to the extent that all attempts to sandbox malicious programs of any complexity have repeatedly failed. Integrating distributed computing into the core of an OO language invariably caused problems due to the super leaky abstraction, for instance, normal languages typically have no way to impose a deadline on a method call written in the standard manner.

Just in time compilation was perhaps one of the worst ideas of all. Take a complex memory and CPU intensive program, like an optimising compiler, and run it over and over again on cheap consumer hardware? Throw away the results each time the user quits and do it all again when they next start it up? Brilliant, sounds like just the thing we all need!

But unfortunately the obvious conceptual problems with just in time compilers did not kill Java's love for it, because writing them was kind of fun and hey, Sun wasn't going to make any major changes in Java's direction after launch - that might imply it was imperfect, or that they made a mistake. And it was successful despite JITC. So when Microsoft decided to clone Java, they wanted to copy a formula that worked, and the JITC concept came along for the ride.

Now, many years later, people are starting to realise that perhaps this wasn't such a great idea after all. .NET Native sounds like a great thing, except it's also an obvious thing that should have been the way .NET worked right from the start. Android is also moving to a hybrid "compile to native at install time" model with the new ART runtime, but at least Android has the excuse that they wanted to optimise for memory and a slow interpreter seemed like the best way to do that. The .NET and Java guys have no such excuses.

Re:Is JITC finally going to die? (1)

MightyMartian (840721) | about 4 months ago | (#46655375)

That's rather a bizarre claim, considering i and p code has been around for decades, and virtual machines have been around as long. There's nothing particularly unique about Java (or .NET for that matter).

Re:Is JITC finally going to die? (0)

Anonymous Coward | about 4 months ago | (#46655767)

He was specifically talking about a JIT compiler using a virtual machine. They weren't saying that virtual machines were something new with Java.

More like JITC goes to the cloud (0)

Anonymous Coward | about 4 months ago | (#46656437)

Quote from the article:

You continue to upload MSIL app packages to the Windows Store. Our compiler in the cloud compiles the app using .NET Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed.

So it still uses JIT during the development process, only now the NGEN optimization process occurs in the cloud instead of locally.

That's terrible. (-1)

Anonymous Coward | about 4 months ago | (#46655465)

I both work for MS and read Slashdot

Is there anything positive about yourself that you'd like to tell us. I'd hate to walk away with such a negative impression.

Re:That's terrible. (0)

gargleblast (683147) | about 4 months ago | (#46655661)

I both work for MS and read Slashdot

That's quite OK. Just say three Hail Marys and a P.S. Fuck Beta.

This is highly disappointing (0)

Anonymous Coward | about 4 months ago | (#46656277)

I was hoping that Microsoft was finally starting to die as part of karma for all the bullshit they've done (and continue to do, just more quietly), but it seems this Satya Nadella fellow's new direction for the company is going to result in a new generation of Microsofties that think Microsoft's way is the best/only way and put the foot down on alternatives. C# sounds like a good language, but no-one here uses it and I'm concerned that Microsoft's influence is going to push towards areas that they have no business being in.

That plus the start menu in Windows 8 coming back means Linux will no longer seem like a necessary conversion for many people anymore, plus Office on the iPad and presumably Android in the near future (for free) will result in LibreOffice having almost no users and hence Microsoft will continue to rein surpreme due to dumbfucks who don't know anything about their history!

I have corporations sometimes - the bad ones just won't fucking DIE!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>