Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLILC – LLVM-Based Compiler for .NET CoreCLR

github.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#21

Post by jevinskie »

mjsabby wrote: post #12
jevinskie wrote: post #9

I wonder how this will affect Mono/Xamarian, given that LLILC has commited to providing an AoT compiler. It would nice to see a CLR frontend for LLVM that cooperates more closely with LLVM upstream. Mono's fork of LLVM is about a 3.4k line diff (mostly EH additions, few -/+ modifications) but they don't seem to actively try to upstream much. Edit: I gave up trying to build a Linux-x86_64 to Android-ARM cross-compiled…

LLILC is absolutely interested in upstreaming and in fact, at least one big change (prelim COFF support for MCJIT) is already upstreamed ( http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-... ) in addition to a few smaller ones. Diffing upstream with http://github.com/Microsoft/llvm will let you track what Microsoft is currently doing in its repo.

I'm elated to hear that. I'm eager to browse the repo tomorrow. Thanks for the feedback! =)

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#22

Post by mjsabby »

quarkzelem wrote: post #19

How does the GC integration work? I've heard various (bad things) about LLVM's support for integrating a GC ..

This wiki page details what LLILC will be doing to get GC Support as required by the CoreCLR:

https://github.com/dotnet/llilc/blob/master/Documentation/ll...

Andy Ayers from the LLILC team will be presenting this exact topic at the EuroLLVM developer meeting: http://llvm.org/devmtg/2015-04

I imagine the LLVM folks will put the meeting videos up on their website like they have in the past, and it would be an interesting video to watch if you're looking for GC specific details in LLILC.

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#23

Post by kasajian »

taspeotis wrote: post #3

I'm surprised it's hosted by the .NET Foundation. I feel the .NET Foundation operates somewhat independently from Microsoft, but there is a large alignment with what Microsoft wants. Using LLVM feels like a departure from some of the things they're working on now. Some blog posts I have read on the MSDN Developer Tools Blogs suggested Microsoft was already working on their own AOT compiler, this statement seems to su…

I've never been surprised at Microsoft attempting to solve the same or similar problem through different channels. They like to have competing projects and see which one evolves and wins... Perhaps that explains it.. Rather than say "No" to something might be the winner.

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#24

Post by sanxiyn »

azakai wrote: post #13
bitcrusher wrote: post #11

Earlier quoted context omitted.

Except, in both of the examples you cite, .Net has had those features since day 1 ( more than 13 years now ). I think it's pretty disingenuous to say those things are hard to measure or even estimate. Java and C# are close enough that you actually CAN measure them in a pretty useful way. Java has been behind the curve for YEARS as compared to .Net with perhaps the exception of the cross platform aspects and the more…

Not sure we're talking about the same thing. To my knowledge no other ecosystem has anything close to Graal and Truffle at this point, much less "since day 1" of .NET. The closest thing I can think of is PyPy, which like Graal+Truffle lets you write a dynamic language in a high-level way, but still get specialized JIT compilation "for free". (In PyPy you write an interpreter, in Graal+Truffle it's more declarative.)…

SPUR from Microsoft Research demonstrated slightly worse than V8 performance for JavaScript on .NET. Too bad SPUR didn't seem to go anywhere...

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#25

Post by dragonwriter »

ksec wrote: post #7

It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?

> What are the chances of Enterprise switching to .Net instead of Java?

Plenty of enterprise shops are Microsoft full-stack shops (Windows Server/.NET/SQL Server/IIS). I get the impression -- though I haven't seen systematic data -- that .NET has been making gains against JVM as an Enterprise platform.

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#26

Post by pjmlp »

ksec wrote: post #7

It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?

Not much. Unless someone rewrites all those systems where there is a JVM available.

The world of enterprise systems isn't only Mac, GNU/Linux and Windows.

Additionally the pace of .NET doesn't matter, because the enterprise is dog slow to upgrade.

We are still doing .NET 4.0, Windows Forms and targeting XP. Some of the project code was written for .NET 3.5.

On the Java side, most corporations are now slowly moving from Java 6 to Java 7 and they hardly care about any alternative JVM languages.

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#27

Post by laichzeit0 »

pjmlp wrote: post #26
ksec wrote: post #7

It seems the pace of .Net improvement is moving much faster then the JVM land. What are the chances of Enterprise switching to .Net instead of Java?

Not much. Unless someone rewrites all those systems where there is a JVM available. The world of enterprise systems isn't only Mac, GNU/Linux and Windows. Additionally the pace of .NET doesn't matter, because the enterprise is dog slow to upgrade. We are still doing .NET 4.0, Windows Forms and targeting XP. Some of the project code was written for .NET 3.5. On the Java side, most corporations are now slowly moving fr…

> Additionally the pace of .NET doesn't matter, because the enterprise is dog slow to upgrade.

In some cases they will never upgrade. I'm talking about places still running WebLogic 8 and JVM 1.4.2. Huge business critical production systems. They'll probably still run on that exact stack for the next 5 years at the very minimum. Everything new gets written in whatever the new stack is, that old stack just stays there, forever.

The strange world of mega corp enterprise IT.

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#28

Post by pjmlp »

bitcrusher wrote: post #15
azakai wrote: post #13

Earlier quoted context omitted.

Not sure we're talking about the same thing. To my knowledge no other ecosystem has anything close to Graal and Truffle at this point, much less "since day 1" of .NET. The closest thing I can think of is PyPy, which like Graal+Truffle lets you write a dynamic language in a high-level way, but still get specialized JIT compilation "for free". (In PyPy you write an interpreter, in Graal+Truffle it's more declarative.)…

As I understand it, Graal+Truffle is basically the DLR. This has been around since 2008 from Microsoft. Both IronPython and IronRuby have used this for years. The "Day 1" comment was specifically pointed at the read-between the lines for Graal, which is basically to create a real IL for Java instead of using the InvokeDynamic semantic that is currently envogue for Scala, Clojure, etc. .NET has had the multi-language…

Graal is a JIT compiler done in Java, it has nothing to do with DLR.

Graal together with SubstractVM offer AOT compilation and is also being used by AMD for the GPGPU support targeted for Java 9, latest Java 10.

Truffle is more of a AST manipulation framework for nodes that can be fed into Graal for compilation.

Then there are those meta-circular JVMs like JikesRVM which are done in Java.

Re: LLILC – LLVM-Based Compiler for .NET CoreCLR

#30

Post by Torn »

drawkbox wrote: post #16

This is somewhat similar to IL2CPP from Unity[1] with AOT is currently what is used on iOS and WebGL builds. It is still buggy and has been in development for a few years or over a year, but it does essentially the same thing, take IL and port it to C++ per platform with AOT compiling. They largely did this to go around Mono licensing from Xamarin and the export is now C++ so there can be no platform limitations or i…

I hope it gives the IL2CPP guys some incentive to go faster. I've been waiting so long for Unity to support a more modern .NET, and to get faster
Post reply on HN