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

11–20 of 44 posts

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

#11

Post by bitcrusher »

azakai wrote: post #8
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?

.NET improving faster than the JVM would be a very hard thing to measure or even estimate. There are very exciting and impressive things happening in JVM land, for example Graal and Truffle.

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 permissive licensing.

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

#12

Post by mjsabby »

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.

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

#13

Post by azakai »

bitcrusher wrote: post #11
azakai wrote: post #8

Earlier quoted context omitted.

.NET improving faster than the JVM would be a very hard thing to measure or even estimate. There are very exciting and impressive things happening in JVM land, for example Graal and Truffle.

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.)

Both PyPy and Graal+Truffle achieve state of the art performance. I'm not aware of any dynamic language on .NET coming even close to that.

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

#14

Post by mikhailt »

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?

Too early to say anything. IMO, it was only a few years ago that .Net felt completely dead and developers were not sure what Microsoft was going to do. This is why .Net didn't take over the Enterprise market in my opinion.

Now, that it is going to be open-source and MS is pushing it harder than it has before, it might have a good chance being used for "new projects" but I've seen MS do this before only to fall off the wagon and stop focusing on these type of stuff.

In addition, the "enterprise" market move much slower than anybody and they care about backward compatibility. It would be several years before .NET would be considered for new projects. It is in that timeframe that Microsoft needs to seriously focus on this and explain why .NET should be used instead of Java.

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

#15

Post by bitcrusher »

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.)…

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 one VM paradigm since day one.

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

#16

Post by drawkbox »

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 it is minimal that C++ tech would be blocked by Apple for any reason for instance like they did with JIT and Flash etc.

Maybe when this has AOT it can also be useable in the same way Unity IL2CPP and Xamarin Mono are used.

[1] http://blogs.unity3d.com/2014/05/20/the-future-of-scripting-...

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

#17

Post by azakai »

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…

No, Graal+Truffle, and PyPy for that matter, are light-years ahead of the DLR. That's why IronPython etc. are nowhere near the state of the art of dynamic language performance, while both the JVM and PyPy have multiple dynamic languages on them that meet that criterion.

The fundamental issue is that dynamic languages need JITs that are very aware of their internals. It's not enough to just emit some code interspersed with PICs and to add fast dynamic dispatch. You also need to speculatively compile and deoptimize in a way that is specific to each dynamic language. Without that, IronPython and other dynamic languages on .NET are often not a little slower but 10x slower than the same languages on the JVM or PyPy.

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

#18

Post by taspeotis »

mjsabby wrote: post #4
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…

Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects. One of LLILC's major objective is give the community an MSIL frontend for LLVM. This allows a JIT or an AOT compiler to take any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will…

> Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects.

Of course not. But why spread your effort across two projects that duplicate functionality when you could focus on one?

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

#20

Post by mjsabby »

taspeotis wrote: post #18
mjsabby wrote: post #4

Earlier quoted context omitted.

Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects. One of LLILC's major objective is give the community an MSIL frontend for LLVM. This allows a JIT or an AOT compiler to take any C# program written for the .NET Core class libraries to run on any platform that CoreCLR can be ported to and that LLVM will…

> Having multiple code generators is not mutually exclusive, and this effort does not mean MSFT is ditching any existing AOT (or for that matter JIT) compiler projects. Of course not. But why spread your effort across two projects that duplicate functionality when you could focus on one?

Have a look at the FAQ: https://github.com/dotnet/llilc/wiki/LLILC-FAQ

Q: How does LLILC relate to the .NET Native work? A: .NET Native provides a broad tool-chain, targeting Windows. The LLILC AOT could be used as the compiler component of .NET Native to target other platforms.

Since LLVM can run on Windows, you could also use it as your AOT compiler for multiple platforms (including Windows) once LLILC gets there.

Post reply on HN